From: Kees Cook <keescook@chromium.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Florian Westphal <fw@strlen.de>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
syzbot <syzkaller@googlegroups.com>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org,
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3] netlink: Bounds-check struct nlmsgerr creation
Date: Fri, 2 Sep 2022 16:08:01 -0700 [thread overview]
Message-ID: <202209021555.9EE2FBD3A@keescook> (raw)
In-Reply-To: <20220901071336.1418572-1-keescook@chromium.org>
On Thu, Sep 01, 2022 at 12:13:36AM -0700, Kees Cook wrote:
> For 32-bit systems, it might be possible to wrap lnmsgerr content
> lengths beyond SIZE_MAX. Explicitly test for all overflows, and mark the
> memcpy() as being unable to internally diagnose overflows.
>
> This also excludes netlink from the coming runtime bounds check on
> memcpy(), since it's an unusual case of open-coded sizing and
> allocation. Avoid this future run-time warning:
>
> memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16)
To get rid of the above warning...
> [...]
> - memcpy(&errmsg->msg, nlh, nlh->nlmsg_len);
> + unsafe_memcpy(&errmsg->msg, nlh, nlh->nlmsg_len,
> + /* "payload" was explicitly bounds-checked, based on
> + * the size of nlh->nlmsg_len.
> + */);
above is the "fix", since the compiler has no way to know how to bounds
check the arguments. But, to write that comment, I added all these
things:
> [...]
> - if (extack->cookie_len)
> - tlvlen += nla_total_size(extack->cookie_len);
> + if (extack->_msg &&
> + check_add_overflow(*tlvlen, nla_total_size(strlen(extack->_msg) + 1), tlvlen))
> + return false;
If that's not desirable, then I guess the question I want to ask is
"what can I put in the unsafe_memcpy() comment above that proves these
values have been sanity checked? In other words, how do we know that
tlvlen hasn't overflowed? (I don't know what other sanity checking may
have already happened, so I'm looking directly at the size calculations
here.)
I assume this isn't more desirable:
- if (extack->cookie_len)
- tlvlen += nla_total_size(extack->cookie_len);
+ if (extack->cookie_len) {
+ size_t len = nla_total_size(extack->cookie_len);
+
+ if (WARN_ON_ONCE(len > SIZE_MAX - tlvlen))
+ return 0;
+ tlvlen += len;
+ }
Or maybe wrap it nicely with a local macro and return 0 instead of
trying to pass an error up a layer?
+#define TLVADD(amount) do { \
+ if (WARN_ON_ONCE(check_add_overflow(tlvlen, amount, &tlvlen))) \
+ return 0; \
+} while (0)
...
if (extack->cookie_len)
- tlvlen += nla_total_size(extack->cookie_len);
+ TLVADD(nla_total_size(extack->cookie_len));
--
Kees Cook
next prev parent reply other threads:[~2022-09-02 23:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 7:13 [PATCH v3] netlink: Bounds-check struct nlmsgerr creation Kees Cook
2022-09-01 21:34 ` Jakub Kicinski
2022-09-02 23:08 ` Kees Cook [this message]
2022-09-03 2:53 ` 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=202209021555.9EE2FBD3A@keescook \
--to=keescook@chromium.org \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=syzkaller@googlegroups.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;
as well as URLs for NNTP newsgroup(s).