From: Kees Cook <kees@kernel.org>
To: Jeff Johnson <quic_jjohnson@quicinc.com>
Cc: Koen Vandeputte <koen.vandeputte@citymesh.com>,
Johannes Berg <johannes@sipsolutions.net>,
ath10k@lists.infradead.org,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: ieee80211.h virtual_map splat
Date: Fri, 21 Jun 2024 12:46:20 -0700 [thread overview]
Message-ID: <202406211241.3E23349@keescook> (raw)
In-Reply-To: <d834ff59-f331-4eb4-91c6-e76eb48780d8@quicinc.com>
On Fri, Jun 21, 2024 at 07:25:08AM -0700, Jeff Johnson wrote:
> On 6/21/2024 3:31 AM, Koen Vandeputte wrote:
> > On Fri, Jun 21, 2024 at 11:30 AM Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >>
> >>
> >>> will this one get backported also?
> >>
> >> Why? It's not even a bug.
> >>
> >> johannes
> >
> > Because without this patch, it produces a splat on kernel 6.6 (which
> > is an LTS) at least ? :-)
>
> @Kees, have you been backporting all your flexible array changes?
I haven't done anything explicit for them. This is especially true for
netdev where maintainers have asked that contributors not include "Cc:
stable" tags, as they want to evaluate for themselves whether patches
should go to stable or not.
> Or are you suggesting folks disable FORTIFY_SOURCE (is that the controlling
> config?)
I do not want people turning off FORTIFY_SOURCE. By design, this is
a warning only -- the memcpy() still works like it did before. The
goal was to catch any of these stragglers going forward, not to break
existing code. I expect that in a few more years it can be flipped to
warn-and-block for these kinds of detected memcpy()s, but for now there
should not be any behavioral changes seen besides the WARN appearing.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2024-06-21 19:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 8:04 ieee80211.h virtual_map splat Koen Vandeputte
2024-06-21 8:21 ` Johannes Berg
2024-06-21 8:47 ` Koen Vandeputte
2024-06-21 9:30 ` Johannes Berg
2024-06-21 10:31 ` Koen Vandeputte
2024-06-21 14:25 ` Jeff Johnson
2024-06-21 19:46 ` Kees Cook [this message]
2024-06-25 3:44 ` Jeff Johnson
2024-06-25 6:56 ` Kalle Valo
2024-06-25 15:02 ` Jakub Kicinski
2024-06-25 15:25 ` Kalle Valo
2024-06-26 18:11 ` Kees Cook
2024-06-26 18:31 ` Jeff Johnson
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=202406211241.3E23349@keescook \
--to=kees@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=koen.vandeputte@citymesh.com \
--cc=linux-wireless@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox