From: Jakub Kicinski <kuba@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: kernel test robot <lkp@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
Jeff Johnson <quic_jjohnson@quicinc.com>,
Michael Walle <mwalle@kernel.org>,
Max Schulze <max.schulze@online.de>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] netlink: Return unsigned value for nla_len()
Date: Fri, 1 Dec 2023 10:45:05 -0800 [thread overview]
Message-ID: <20231201104505.44ec5c89@kernel.org> (raw)
In-Reply-To: <202312010953.BEDC06111@keescook>
On Fri, 1 Dec 2023 10:17:02 -0800 Kees Cook wrote:
> > > -static inline int nla_len(const struct nlattr *nla)
> > > +static inline u16 nla_len(const struct nlattr *nla)
> > > {
> > > - return nla->nla_len - NLA_HDRLEN;
> > > + return nla->nla_len > NLA_HDRLEN ? nla->nla_len - NLA_HDRLEN : 0;
> > > }
> >
> > Note the the NLA_HDRLEN is the length of struct nlattr.
> > I mean of the @nla object that gets passed in as argument here.
> > So accepting that nla->nla_len may be < NLA_HDRLEN means
> > that we are okay with dereferencing a truncated object...
> >
> > We can consider making the return unsinged without the condition maybe?
>
> Yes, if we did it without the check, it'd do "less" damage on
> wrap-around. (i.e. off by U16_MAX instead off by INT_MAX).
>
> But I'd like to understand: what's the harm in adding the clamp? The
> changes to the assembly are tiny:
> https://godbolt.org/z/Ecvbzn1a1
Hm, I wonder if my explanation was unclear or you disagree..
This is the structure:
struct nlattr {
__u16 nla_len; // attr len, incl. this header
__u16 nla_type;
};
and (removing no-op wrappers):
#define NLA_HDRLEN sizeof(struct nlattr)
So going back to the code:
return nla->nla_len > NLA_HDRLEN ? nla->nla_len - NLA_HDRLEN...
We are reading nla->nla_len, which is the first 2 bytes of the structure.
And then we check if the structure is... there?
If we don't trust that struct nlattr which gets passed here is at least
NLA_HDRLEN (4B) then why do we think it's safe to read nla_len (the
first 2B of it)?
That's why I was pointing at nla_ok(). nla_ok() takes the size of the
buffer / message as an arg, so that it can also check if looking at
nla_len itself is not going to be an OOB access. 99% of netlink buffers
we parse come from user space. So it's not like someone could have
mis-initialized the nla_len in the kernel and being graceful is helpful.
The extra conditional is just a minor thing. The major thing is that
unless I'm missing something the check makes me go 🤨️
next prev parent reply other threads:[~2023-12-01 18:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 20:01 [PATCH] netlink: Return unsigned value for nla_len() Kees Cook
2023-11-30 20:11 ` Gustavo A. R. Silva
2023-12-01 1:25 ` Jakub Kicinski
2023-12-01 7:45 ` Johannes Berg
2023-12-01 18:17 ` Kees Cook
2023-12-01 18:45 ` Jakub Kicinski [this message]
2023-12-02 4:39 ` Kees Cook
2023-12-02 5:16 ` Jakub Kicinski
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=20231201104505.44ec5c89@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=johannes@sipsolutions.net \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lkp@intel.com \
--cc=max.schulze@online.de \
--cc=mwalle@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_jjohnson@quicinc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.