From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Kubecek <mkubecek@suse.cz>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] netlink: check for null extack in cookie helpers
Date: Fri, 20 Mar 2020 22:22:45 +0100 [thread overview]
Message-ID: <b4b1d7b252820591ebb00e3851d44dc6c3f2d1b9.camel@sipsolutions.net> (raw)
In-Reply-To: <20200320211343.4BD38E0FD3@unicorn.suse.cz>
Hi Michal,
> Unlike NL_SET_ERR_* macros, nl_set_extack_cookie_u64() and
> nl_set_extack_cookie_u32() helpers do not check extack argument for null
> and neither do their callers, as syzbot recently discovered for
> ethnl_parse_header().
What exactly did it discover?
> Instead of fixing the callers and leaving the trap in place, add check of
> null extack to both helpers to make them consistent with NL_SET_ERR_*
> macros.
>
> Fixes: 2363d73a2f3e ("ethtool: reject unrecognized request flags")
> Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API")
I'm not really convinced, at least not for the second patch.
After all, this is an important part of the functionality, and the whole
thing is pretty useless if no extack/cookie is returned since then you
don't have a handle to the in-progress operation.
That was the intention originally too, until now the cookie also got
used for auxiliary error information...
Now, I don't think we need to *crash* when something went wrong here,
but then I'd argue there should at least be a WARN_ON(). But then that
means syzbot will just trigger the WARN_ON which also makes it unhappy,
so you still would have to check in the caller?
johannes
next prev parent reply other threads:[~2020-03-20 21:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 21:13 Michal Kubecek
2020-03-20 21:22 ` Johannes Berg [this message]
2020-03-20 22:27 ` Michal Kubecek
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=b4b1d7b252820591ebb00e3851d44dc6c3f2d1b9.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
/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®