Look up another CVE · open CVE-2026-89986 in the interactive tracker
CVE-2026-89986
mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave()
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89986 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
mm/mempolicy.c
- What this is
- MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATIONMAINTAINERS section matched on mm/mempolicy.c · linux-mm@kvack.org · Maintained
Check it on the machine
grep -w CONFIG_NUMA /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae
- trixieYnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, s390x/s390x
- forky, sidYnot built on armhf/armmp, armhf/armmp-lpae, s390x/s390x
- bookworm · linux-6.12Ynot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_NUMA
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.9 | 6.12.110 | bcb3d0c867ee |
| 6.9 | 6.18.51 | 0ceda28f371d |
| 6.9 | 7.2.5 | 2943f1f4b7f2 |
| 6.9 | 7.3 | 540e583b66d6 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Triggering requires set_mempolicy(MPOL_WEIGHTED_INTERLEAVE) on the attacker's task and a local syscall that grows an rhashtable until GFP_ATOMIC kvmalloc falls back to vmalloc (nftables hash sets, tc flower, BPF rhashtable maps); softirq/packet paths use default_policy via in_interrupt() and cannot apply the attacker's mempolicy.
- AC:LAttack complexity, low
- The attacker fully controls setup: set_mempolicy on their own task, insert enough rhashtable elements for a >PAGE_SIZE bucket table, and apply memory pressure so GFP_ATOMIC kmalloc fails and kvmalloc uses vmalloc; CONFIG_NUMA is standard on x86_64/arm64 distro and cloud kernels, and no attacker-uncontrollable race is required.
- PR:LPrivileges required, low
- set_mempolicy() has no capability check, and the rhashtable rehash path is reachable by an unprivileged user via nftables or tc in a user+net namespace where CAP_NET_ADMIN is namespace-local; init-namespace root is not required.
- UI:NUser interaction, none
- The attacker sets their own mempolicy and drives the rhashtable inserts themselves; no victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- The illegal GFP_KERNEL allocation and any resulting RCU use-after-free of the rhashtable bucket table stay inside the host kernel's memory-management authority; this is standard in-kernel impact, not a VM, IOMMU, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- Sleeping under rcu_read_lock() in rhashtable_insert_slow() on non-PREEMPT_RCU kernels can let the grace period complete and free the old bucket table before rhashtable_rehash_attach() uses it, yielding a use-after-free read of kernel heap.
- I:HIntegrity impact, high
- The same RCU-break UAF lets rhashtable_rehash_attach() cmpxchg old_tbl->future_tbl on a freed table, which is an attacker-sprayable kernel write primitive via heap reuse rather than a clean failure.
- A:HAvailability impact, high
- GFP_KERNEL under rcu_read_lock produces a sleeping-from-invalid-context BUG/WARN (panic with panic_on_warn), can RCU-stall or deadlock if reclaim actually sleeps, and the bucket-table UAF can oops the kernel.