Linux kernel nvme: discard fallback page is never zeroed, leaking kernel memory to the controller

Impact

nvme_setup_discard() always maps a full 4096-byte DSM payload regardless of how many ranges the command declares, because some devices read past the declared range count. Normally the buffer comes from kzalloc() so the unused tail is zero. When that atomic allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page() and nothing ever zeroes - so up to 4080 bytes of whatever that page last held are handed to the storage controller. Under KMSAN the leaked tail was full of vmemmap struct page pointers, which is exactly the kind of data that defeats KASLR. Reaching it requires the GFP_ATOMIC allocation to fail, i.e. real memory pressure, so it is not remotely triggerable on demand; the exposure is toward the storage target, which over NVMe/TCP may be a different trust domain than the host.

Who can reach it

Not directly attacker-triggered. Requires memory pressure on the host to fail a GFP_ATOMIC allocation during a discard; the recipient of the leaked bytes is the NVMe controller or NVMe/TCP target. An attacker who can both apply memory pressure on a shared node and observe the target side could collect the leak.

What to do

Update to a stable kernel that zeroes the fallback page (four stable commits linked) and reboot the node. Low urgency on its own - bundle it with the other nvme fixes in this batch into a single rolling reboot rather than scheduling a window for it alone. No fixed release number is given.

References

Related entries

• Linux CephFS client: leaked inode reference on aborted writeback panics the node at umountCVE-2026-89646 · Linux kernel CephFS client (ceph_submit_write writeback abort at umount)Unscored
• Linux CephFS client: cap reclaim work busy-loops, burning CPU and contending dentry_list_lockCVE-2026-89647 · Linux kernel CephFS client (ceph_cap_reclaim_work / ceph_trim_dentries busy loop)Unscored
• Linux CephFS client: unbounded delegated-inode intervals let a hostile MDS burn client CPU and memoryCVE-2026-89648 · Linux kernel CephFS client (ceph_parse_deleg_inos delegated inode count)Unscored
• Linux CephFS client: unchecked final xattr value length leaks kernel heap via getxattr(2)CVE-2026-89649 · Linux kernel CephFS client (__build_xattrs xattr value length)Unscored
• Linux CephFS client: out-of-bounds read decoding MDS map info v2/v3 export targetsCVE-2026-89650 · Linux kernel CephFS client (ceph_mdsmap_decode num_export_targets)Unscored
• Linux CephFS client: unbounded copy of MDSCapAuth path and fs_name crashes client at mountCVE-2026-89651 · Linux kernel CephFS client (handle_session MDSCapAuth path/fs_name decode)Unscored