[GIT PULL] x86/urgent for 7.4-rc4

[GIT PULL] x86/urgent for 7.4-rc4

[Dave Hansen]

Hi Linus,

Please pull some x86/urgent changes for 7.4-rc4.

The MADV_FREE one is notable for silently losing user data and having
been around for a couple of years. The main explanation I'd have for
its longevity is that it requires a few different things to align at
the same time: MADV_FREE, THP and heavy reclaim.

There's also a good set of x86/mm fixes from Lorenzo and company.
They look somewhat theoretical at first but they have actually been
hampering folks' ability mm work in the area.
The following changes since commit d2929113b15bfc06793b852aeba3d2db6d79fcc9:

  x86/MCE/AMD: Fix inverted interrupt enablement during storm handling (2026-09-08 09:16:32 +0200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_7.3-rc4

for you to fetch changes up to 27600805e62f800bacf990354632eae4e487d34c:

  x86/amd_node: Fix PCI device reference counting in amd_smn_init() (2026-09-10 18:05:43 -0700)

----------------------------------------------------------------
 * Fix user-space data loss with MADV_FREE and THP
 * Fix set_memory oopses
 * Fix addition of large constants in mul_u64_add_u64_div_u64()
 * Fix FineIBT hash offset in cfi_get_func_hash()
 * Fix PCI device reference counting in amd_smn_init()

----------------------------------------------------------------
David Laight (1):
      x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64()

Lorenzo Stoakes (ARM) (3):
      x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF
      x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF
      x86/mm/pat: Allocate split page tables as kernel page tables

Pedro Falcato (1):
      x86/alternatives: Exclude text poking against change_page_attr()

Soheil Hassas Yeganeh (1):
      x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash()

Vernon Yang (1):
      x86/mm: Fix user-space data loss with MADV_FREE and THP

Yazen Ghannam (1):
      x86/amd_node: Fix PCI device reference counting in amd_smn_init()

 arch/x86/include/asm/div64.h   |   2 +-
 arch/x86/include/asm/pgtable.h |   2 +-
 arch/x86/kernel/alternative.c  | 111 +++++++++++++++++++++++++++--------------
 arch/x86/kernel/amd_node.c     |   6 +--
 arch/x86/mm/pat/set_memory.c   |  53 +++++++++++++++-----
 include/linux/mmap_lock.h      |   2 +
 6 files changed, 121 insertions(+), 55 deletions(-)

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Linus Torvalds]

On Sun, 13 Sept 2026 at 15:54, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
> The MADV_FREE one is notable for silently losing user data and having
> been around for a couple of years.

That explanation rewards horribly badly.

MADV_FREE itself is fine. It's *supposed* to drop dirty bits and lose
user data. That is the whole -m and only - point of MADV_FREE in the
first place.

The bug seems to be elsewhere in non-MADV_FREE code that then just is
confused about things. But both your pull request and that commit
message seem to try to blame MADV_FREE. What's up?

                Linus

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Linus Torvalds]

On Sun, 13 Sept 2026 at 16:10, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That explanation rewards horribly badly.

*reads*. Apparently my MUA has started its auto-correct journey again
and I need to turn it off again.

That's my story, and I'm sticking to it. No way am I just incompetent
with a keyboard and can't spel wroth a dman.

            Linus

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Dave Hansen]

On 9/13/26 16:10, Linus Torvalds wrote:
> On Sun, 13 Sept 2026 at 15:54, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>> The MADV_FREE one is notable for silently losing user data and having
>> been around for a couple of years.
> That explanation rewards horribly badly.
> 
> MADV_FREE itself is fine. It's *supposed* to drop dirty bits and lose
> user data. That is the whole -m and only - point of MADV_FREE in the
> first place.
> 
> The bug seems to be elsewhere in non-MADV_FREE code that then just is
> confused about things. But both your pull request and that commit
> message seem to try to blame MADV_FREE. What's up?

Yeah, the explanation isn't great. Sorry about that.

My read on it is that problem shows up a bit *after* the actual
MADV_FREE. The manpage goes over this scenario:

	After a successful MADV_FREE operation, any stale data
	(i.e.,  dirty, unwritten pages) will be lost when the kernel
	frees the pages. However, subsequent writes to pages in the
	range will succeed and then kernel cannot free those dirtied
	pages, so that the caller can always see just written data.

So the problem isn't with the data which was around at MADV_FREE time,
it's with the "subsequent writes" that the kernel frees.  I _think_ the
main way the kernel tells if a "subsequent write" occurs is _PAGE_DIRTY.

So the scenario is something like this:

 1. First set of data goes into the page
 2. MADV_FREE performed, clears _PAGE_DIRTY. Page eligible for reclaim.
 3. Second set of data is written, sets _PAGE_DIRTY. Page *in*eligible
    for reclaim.
 4. PMD is mprotect()'d which flows through pmd_modify(). _PAGE_DIRTY
    is lost. Page now wrongly eligible for reclaim again.
 5. Reclaim goes after the page, discards second set of data.

At least that was my read on it.

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Linus Torvalds]

On Sun, 13 Sept 2026 at 17:18, Dave Hansen <dave.hansen@intel.com> wrote:
>
> So the problem isn't with the data which was around at MADV_FREE time,
> it's with the "subsequent writes" that the kernel frees.  I _think_ the
> main way the kernel tells if a "subsequent write" occurs is _PAGE_DIRTY.

Yeah, so it looks to me like the *fix* is correct, and it's just that
blaming MADV_FREE is the wrong thing.

And if I read things right, this only happens for HUGETLB because the
normal page table code doesn't use pmd_modify(), so all the common
single-page cases get this right.

So it's really just pmd_modify() that is buggy, and the patch isn't
MADV_FREE, but probably something like

  mprotect_fixup ->
    change_protection ->
      change_protection_range ->
        change_p4d_range ->
          change_pud_range ->
            change_pmd_range ->
              change_pte_range ->
                change_huge_pmd ->
                  pmd_modify()

and the "Fixes:" line there in that commit looks correct too.

I still don't understand why that  whole

  & ~_PAGE_DIRTY

was added to that commit back in 2023 in the first place? The very
same commit did all the same changes to pte_modify() *EXCEPT* for that
dirty bit thing.

So the more I look at this, the more confused I am about why this happened.

The good news is that I think the fix is clearly correct. The thing I
reacted to was the misleading wording of the explanation.

This does not seem to be a bug in MADV_FREE at all, and isn't even
really related to MADV_FREE. I think MADV_FREE just happened to be a
way to trigger it.

And *maybe* MADV_FREE is the _only_ way to trigger it, but I'm not
even convinced about that part. It literally feels like mprotect() of
hugepages is really just buggy. It feels like that HUGEPAGE code
basically expected that "PAGE_RW" is always exactly the same as
"PAGE_DIRTY".

I dunno. Maybe I'm still missing something. But I did the pull, and I
just removed the comment blaming MADV_FREE, and I just rewrote it to
"THP not silently losing user data".

It still mentions MADV_FREE in the text that talks about having to
have a few things align. THAT part I can believe in: clearly something
has to align just right for this to actually be a user-visible issue,
explaining why it wasn't an obvious bug.

I'd love for somebody to hit me with a clue hammer on how this all
happened, but I guess that's not required for the fix.

            Linus

Re: [GIT PULL] x86/urgent for 7.4-rc4

[pr-tracker-bot]

The pull request you sent on Sun, 13 Sep 2026 15:53:56 -0700:

> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_7.3-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/704340f1cd0dcef829eb62f5b48ae95a2ce17bdf

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Dave Hansen]

On 9/13/26 18:04, Linus Torvalds wrote:
> On Sun, 13 Sept 2026 at 17:18, Dave Hansen <dave.hansen@intel.com> wrote:
...
> This does not seem to be a bug in MADV_FREE at all, and isn't even
> really related to MADV_FREE. I think MADV_FREE just happened to be a
> way to trigger it.

Ahh, I see your point. Agreed. It's really about mprotect() on a PMD
versus the dirty bit.

> I'd love for somebody to hit me with a clue hammer on how this all
> happened, but I guess that's not required for the fix.

Rick dug back in some old versions of the shadow stack patches to look
for the origin:

> https://lore.kernel.org/lkml/c15c2b17e110782d966751dbf3c487a6db837a87.camel@intel.com/

It does seem to just be cruft from old versions that snuck through as
opposed to something intentional.

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Orson Peters]

> Yeah, so it looks to me like the *fix* is correct, and it's just that
> blaming MADV_FREE is the wrong thing.

One thing I'd like to point out is that from userspace THP + MADV_FREE
is all you need to hit the bug, if you are on a multi-NUMA-node
machine.

My minimal reproducer did explicitly call mprotect() to make the
reproduction deterministic. But on a multi-NUMA-node machine
pmd_modify can get called entirely transparently in the background
with memory pressure.

So from the perspective of the user it really is just MADV_FREE
misbehaving (write-after-free getting lost) when THP is being used.
I'm not sure if that should actually be reflected in the commit
message, but wanted to point it out anyway.

Re: [GIT PULL] x86/urgent for 7.4-rc4

[Linus Torvalds]

On Mon, 14 Sept 2026 at 03:12, Orson Peters <orsonpeters@gmail.com> wrote:
>
> My minimal reproducer did explicitly call mprotect() to make the
> reproduction deterministic. But on a multi-NUMA-node machine
> pmd_modify can get called entirely transparently in the background
> with memory pressure.

I guess any of the paths that end up calling pmd_modify() will trigger
it, and mprotect() is just the most explicit one.

At the other end of this argument, I tried to find something else that
does what MADV_FREE does. I think the trigger is simply that "clear
dirty bit, but leave it writable".

And a shared mapping writeout will do exactly that - but I don't think
anybody does writeback at the hugepage level.

So it may be that MADV_FREE is indeed the only case that actually can
trigger the bug that otherwise looks pretty much like a generic thp
issue.

                 Linus