Linux wireless drivers development
 help / color / mirror / Atom feed
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

  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