All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: rppt@kernel.org, peterz@infradead.org, akpm@linux-foundation.org,
	david@kernel.org, mingo@redhat.com, acme@kernel.org,
	namhyung@kernel.org, linux-mm@kvack.org,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev, stable@vger.kernel.org,
	4ncienth@gmail.com, alexander.motin@truenas.com,
	caleb.stjohn@truenas.com, ameer.hamza@truenas.com
Subject: Re: [REGRESSION] secretmem: SIGBUS on memfd_secret() pages while perf record runs
Date: Sat, 3 Oct 2026 10:30:10 -0400	[thread overview]
Message-ID: <asERcvLuNJatsBL7@laps> (raw)
In-Reply-To: <asDF77csaLDIuHTB@gremlin>

On Sat, Oct 03, 2026 at 10:18:34AM +0100, Lorenzo Stoakes (ARM) wrote:
>On Fri, Oct 02, 2026 at 09:30:23PM -0400, Sasha Levin wrote:
>> > Since commit 97d34aa65c29 ("mm/secretmem: properly account locked
>> > pages"), in v7.3-rc2 and the 6.18.52 and 7.2.5 backports, touching a
>> > memfd_secret() page for the first time fails with SIGBUS while the
>> > same user is running perf record, and read() into such a page fails
>>
>> Thanks for the report. I've dropped 97d34aa65c29 from the 6.12 queue,
>> and also removed the copies that were staged for 6.6 and 6.1.
>>
>> 7.2.y and 6.18.y already shipped it, so those need an upstream fix,
>> which stable will pick up once it lands.
>
>Sasha,
>
>Could we perhaps take a breath and pause?

I pulled this out quickly because I didn't want this issue to go into the kernels that were released this morning.

In general, our policy around this type of reports is that if the issue is in a
released LTS kernel, we will wait for a fix upstream, and if the issue is still
in our queues, we will simply drop the patch from the queue.

>This patch fixes a really quite serious vulnerability that allows an
>unprivileged process to allocate arbitrary, unreclaimable (i.e. OOMK cannot
>save you) memory.
>
>Allow me to assess the validity of this report _before_ dropping things
>from queues perhaps? :)

No disagreement that this would have been better - in this case it was timing
as the releases were about to happen the following day, so the safest choice
was to drop it while we figure it out.

>It was sent late on Friday in a week that I was ill and it's Saturday
>pre-LPC, so that's hardly a timeframe that I could reasonably have replied.

Keep in mind that our release cycles are fairly short, so this shouldn't be too
big of a deal?

We will generally go for the safe option of dropping a commit that introduces a
regression as it's fairly easy to queue it back up very soon after a
diagnosis/fix shows up.

-- 
Thanks,
Sasha


  reply	other threads:[~2026-10-03 14:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 17:56 [REGRESSION] secretmem: SIGBUS on memfd_secret() pages while perf record runs Ameer Hamza
2026-10-03  1:30 ` Sasha Levin
2026-10-03  9:18   ` Lorenzo Stoakes (ARM)
2026-10-03 14:30     ` Sasha Levin [this message]
2026-10-03 16:23       ` Lorenzo Stoakes (ARM)
2026-10-03 22:34         ` Sasha Levin
2026-10-03 14:14 ` David Hildenbrand (Arm)
2026-10-03 17:05   ` Ameer Hamza
2026-10-05 10:38     ` David Hildenbrand (Arm)
2026-10-03 15:56 ` Lorenzo Stoakes (ARM)
2026-10-03 16:31   ` Lorenzo Stoakes (ARM)
2026-10-03 18:02   ` Ameer Hamza
2026-10-04 16:29 ` Sasha Levin
2026-10-09 11:56   ` Lorenzo Stoakes (ARM)

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=asERcvLuNJatsBL7@laps \
    --to=sashal@kernel.org \
    --cc=4ncienth@gmail.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.motin@truenas.com \
    --cc=ameer.hamza@truenas.com \
    --cc=caleb.stjohn@truenas.com \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=regressions@lists.linux.dev \
    --cc=rppt@kernel.org \
    --cc=stable@vger.kernel.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.