From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Brahmajit <brahmajit.xyz@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: linux-wireless@vger.kernel.org, johannes.berg@intel.com,
ilan.peer@intel.com, miriam.rachel.korenblit@intel.com
Subject: Re: Possible Null pointer dereferences in net/mac80211/parse.c
Date: Mon, 10 Mar 2025 10:09:25 -0700 [thread overview]
Message-ID: <0b9d4a5d-326c-4281-b9fe-c8e1b1e4a026@oss.qualcomm.com> (raw)
In-Reply-To: <qriquzbudggauxqm5oz55zvkh3uhpk5icx6icnacyzzijdtivr@m37pbcwiqblb>
On 3/10/2025 7:16 AM, Brahmajit wrote:
> Coverity Scan reports that there might be a possible NULL pointer
> dereferences in net/mac80211/parse.c: 1061 in
> ieee802_11_parse_elems_full(). I understand that these reports are not
> always correct.
>
> I'm not sure whether the syntax
> struct ieee80211_elems_parse_params sub = {};
> is correct or falls under C11 standard[0].
{} initializers are extensions supported by both gcc and clang/LLVM which
AFAIK are the only two compilers currently used by Linux.
>
> initializer:
> assignment-expression
> { initializer-list }
> { initializer-list , }
> initializer-list:
> designation(opt) initializer
> initializer-list , designation(opt) initializer
>
> I'm aware that C23 allows empty initialization[1].
>
> braced-initializer:
> { }
> { initializer-list }
> { initializer-list , }
>
> Considering [0], if we do something like
>
> --- a/net/mac80211/parse.c
> +++ b/net/mac80211/parse.c
> @@ -997,7 +997,7 @@ ieee80211_mle_defrag_epcs(struct ieee80211_elems_parse *elems_parse)
> struct ieee802_11_elems *
> ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)
> {
> - struct ieee80211_elems_parse_params sub = {};
> + struct ieee80211_elems_parse_params sub = { 0 };
using one of the supported compilers, these are identical for this struct.
note that {} is usually preferable to {0} since {} works even when the first
member is not a scalar.
and the coverity report indicates the issue is that sub.start can be NULL,
which will initially be true with either of these initializers.
so the question is can sub.start really be NULL at the point where it is
passed to cfg80211_find_elem(), or does every path initialize it?
that is the question you should try to answer
> struct ieee80211_elems_parse *elems_parse;
> const struct element *non_inherit = NULL;
> struct ieee802_11_elems *elems;
>
> Would it be incorrect? Would appreciate some feedback.
>
> [0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> [1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
prev parent reply other threads:[~2025-03-10 17:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 14:16 Brahmajit
2025-03-10 17:09 ` Jeff Johnson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b9d4a5d-326c-4281-b9fe-c8e1b1e4a026@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=brahmajit.xyz@gmail.com \
--cc=ilan.peer@intel.com \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®