PT-2026-98606 · Linux · Linux
CVE-2026-97942
·
Published
2026-09-25
·
Updated
2026-09-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
x86/alternatives: Exclude text poking against change page attr()
From time to time, the following BUG can be observed
in the x86 alternatives patching code [0]:
kernel BUG at arch/x86/kernel/alternative.c:2576! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 355 Comm: (udev-worker) Not tainted 7.1.3-1-default #1 PREEMPT(full) openSUSE Tumbleweed 8c1795b03ec64f997e57a8ad38b1161e3b98da64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 RIP: 0010: text poke+0x2aa/0x450 Call Trace: smp text poke batch finish+0x2a7/0x320 static call transform+0xb7/0x220 arch static call transform+0x5b/0xb0 static call init+0xe9/0x270 static call module notify+0x11f/0x150 notifier call chain+0x61/0xe0 blocking notifier call chain robust+0x63/0xc0 load module+0x1c92/0x20c0 init module from file+0xd8/0x140 idempotent init module+0x100/0x2f0 x64 sys finit module+0x71/0xe0 do syscall 64+0xe1/0x610 entry SYSCALL 64 after hwframe+0x76/0x7e
which matches the following BUG ON() in alternative.c:
/*
* If something went wrong, crash and burn since recovery paths are not
* implemented.
*/
BUG ON(!pages[0] || (cross page boundary && !pages[1]));This can happen if vmalloc to page() fails, for any reason. Such can happen
if text poking races with CPA, which can possibly result in the collapsing
of page tables (or breaking of PMD hugepages). It is not a problem for most
users of vmalloc to page() (they solely own the vmalloc'd range) but, when
CONFIG ARCH HAS EXECMEM ROX=y, various modules own a single execmem vmalloc
range, and can call set memory *() in parallel on it. This can happen to
race against text poke and cause havoc in vmalloc to page().
Fix it by excluding against CPA using the init mm mmap read lock.
[ dhansen: Fix up SoB ordering. The actual code flow here was:
Pedro=>Lorenzo=>Mike=>Me which is reflected in the SoB chain
now. I believe Mike simply picked up Lorenzo's update to
Pedro's post from the Link ]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux