From: Kees Cook <keescook@chromium.org>
To: Tadeusz Struk <tadeusz.struk@linaro.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH 2/2] skbuff: Extract list pointers to silence compiler warnings
Date: Wed, 30 Mar 2022 14:46:29 -0700 [thread overview]
Message-ID: <202203301444.78CE208@keescook> (raw)
In-Reply-To: <7f3c25f5-33ac-b5f6-9c2e-17e2310a6377@linaro.org>
On Wed, Mar 30, 2022 at 07:59:57AM -0700, Tadeusz Struk wrote:
> On 3/30/22 07:46, Greg KH wrote:
> > On Tue, Mar 29, 2022 at 03:02:56PM -0700, Tadeusz Struk wrote:
> > > Please apply this to stable 5.10.y, and 5.15.y
> > > ---8<---
> > >
> > > From: Kees Cook<keescook@chromium.org>
> > >
> > > Upstream commit: 1a2fb220edca ("skbuff: Extract list pointers to silence compiler warnings")
> > >
> > > Under both -Warray-bounds and the object_size sanitizer, the compiler is
> > > upset about accessing prev/next of sk_buff when the object it thinks it
> > > is coming from is sk_buff_head. The warning is a false positive due to
> > > the compiler taking a conservative approach, opting to warn at casting
> > > time rather than access time.
> > >
> > > However, in support of enabling -Warray-bounds globally (which has
> > > found many real bugs), arrange things for sk_buff so that the compiler
> > > can unambiguously see that there is no intention to access anything
> > > except prev/next. Introduce and cast to a separate struct sk_buff_list,
> > > which contains_only_ the first two fields, silencing the warnings:
> > We don't have -Warray-bounds enabled on any stable kernel tree, so why
> > is this needed?
> >
> > Where is this showing up as a problem?
>
> The issue shows up and hinders testing stable kernels in test automations
> like syzkaller:
>
> https://syzkaller.appspot.com/text?tag=Error&x=12b3aac3700000
>
> Applying it to stable would enable more test coverage.
Hi! I think a better solution may be to backport this change instead:
69d0db01e210 ("ubsan: remove CONFIG_UBSAN_OBJECT_SIZE")
i.e. remove CONFIG_UBSAN_OBJECT_SIZE entirely, which is the cause of
these syzkaller splats.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2022-03-30 21:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 22:02 [PATCH 1/2] stddef: Introduce struct_group() helper macro Tadeusz Struk
2022-03-29 22:02 ` [PATCH 2/2] skbuff: Extract list pointers to silence compiler warnings Tadeusz Struk
2022-03-30 14:46 ` Greg KH
2022-03-30 14:59 ` Tadeusz Struk
2022-03-30 15:29 ` Greg KH
2022-03-30 15:38 ` Tadeusz Struk
2022-03-30 21:46 ` Kees Cook [this message]
2022-03-30 22:53 ` Tadeusz Struk
2022-03-30 16:37 ` Greg KH
2022-03-30 17:10 ` Tadeusz Struk
2022-03-30 16:39 ` Greg KH
2022-03-30 4:44 ` [PATCH 1/2] stddef: Introduce struct_group() helper macro Greg KH
2022-03-30 14:38 ` Tadeusz Struk
2022-03-30 14:45 ` Greg KH
2022-03-30 14:58 ` Tadeusz Struk
2022-03-30 16:37 ` Greg KH
2022-03-30 16:55 ` Tadeusz Struk
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=202203301444.78CE208@keescook \
--to=keescook@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tadeusz.struk@linaro.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 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.