CVE-2026-89483: nvme: zero the discard fallback page
In the Linux kernel, the following vulnerability has been resolved:
nvme: zero the discard fallback page
nvmesetupdiscard() always maps sizeof(struct nvmedsmrange) NVMEDSMMAXRANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes.
Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discardpage, which nvmeinitctrl() obtains with allocpage(GFPKERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFPATOMIC | GFPNOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range:
[ 11.991601] BUG: KMSAN: uninit-value in dmamapphys+0x14c8/0x1900 [ 11.991969] dmamapphys+0x14c8/0x1900 [ 11.992220] dmamappageattrs+0xcf/0x130 [ 11.992485] e1000xmitframe+0x4099/0x6d10 [ 11.992768] devhardstartxmit+0x22f/0xa80 [ 11.993068] schdirectxmit+0x35c/0xcb0 [ 11.993315] devqueuexmit+0x1ee5/0x5eb0 [ 11.993608] ipfinishoutput2+0x1903/0x1c30 [ 11.993881] ipfinishoutput+0x288/0x870 [ 11.994125] ipoutput+0x15e/0x400 [ 11.994365] ipqueuexmit+0x1e85/0x1fb0 [ 11.994639] ipqueuexmit+0x60/0x80 [ 11.994899] tcptransmitskb+0x4e71/0x5fa0 [ 11.995210] tcpwritexmit+0x3a36/0x9160 [ 11.995533] tcppushpendingframes+0xc5/0x3c0 [ 11.995854] tcppush+0x7dc/0x840 [ 11.996076] tcpsendmsglocked+0x766c/0x8400 [ 11.996371] tcpsendmsg+0x4b/0x90 [ 11.996572] inetsendmsg+0x134/0x2a0 [ 11.996823] socksendmsg+0x265/0x360 [ 11.997076] socksendmsg+0x100/0x1e0 [ 11.997293] nvmetcptrysend+0x196f/0x6370 [ 11.997605] nvmetcpqueuerq+0x1d54/0x20b0 [ 11.997882] blkmqdispatchrqlist+0x5ee/0x2e50 [ 11.998175] blkmqscheddispatchrequests+0x16dc/0x24a0 [ 11.998539] blkmqscheddispatchrequests+0x11b/0x2c0 [ 11.998865] blkmqrunworkfn+0x13b/0x280 [ 11.999146] processscheduledworks+0x966/0x1ad0 [ 11.999465] workerthread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] retfromfork+0x29f/0x7c0 [ 12.000191] retfromforkasm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] allocfrozenpagesnoprof+0x8bf/0xd30 [ 12.001096] allocpagesmpol+0x1d0/0x5f0 [ 12.001326] allocpagesnoprof+0x102/0x290 [ 12.001627] nvmeinitctrl+0x5a3/0x9f0 [ 12.001891] nvmetcpcreatectrl+0xd75/0x19b0 [ 12.002170] nvmfdevwrite+0x4c68/0x4fd0 [ 12.002426] vfswrite+0x587/0x1a10 [ 12.002636] x64syswrite+0x207/0x4f0 [ 12.002874] x64syscall+0x2ff0/0x3ea0 [ 12.003123] dosyscall64+0x147/0x3b0 [ 12.003400] entrySYSCALL64afterhwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blkmqrunworkfn [ 12.006073] =====================================================
Allocate the page with GFPZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the NVMe discard fallback path (the controller’s discard page), ensure the page is allocated with __GFP_ZERO so the mapped DSM payload buffer is zero-initialized even when the discard/fallback allocation fails.
Linux kernel nvme discard fallback page Allocate discard fallback page with __GFP_ZERO = __GFP_ZERO
Event History
Frequently Asked Questions
Can this be exploited remotely?
No. The issue requires a local memory-pressure condition that causes an atomic allocation to fail; the provided data states it is not remotely triggerable.
What must happen for stale memory to reach an NVMe controller?
A discard operation must use the per-controller fallback page after kzalloc(GFP_ATOMIC | __GFP_NOWARN) fails. For a single-range discard, only the first 16 bytes are initialized while the controller may receive the remaining uninitialized portion of the 4096-byte DSM payload.
How can this condition be identified during testing?
The issue can be reproduced under KMSAN by forcing the allocation failure. KMSAN reports an uninitialized-value condition in DMA, and the leaked tail may contain vmemmap struct page pointers.