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

• Tenant handoff on bare metal: Reimaging the host disk clears nothing in the BMC, UEFI/SPI flash, NIC/DPU firmware, GPUNCVD-0000-013-tenant-handoff-on-bare-metal · Tenant handoff on bare metalUnscored
• ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platformsNCVD-2018-002-ecc-ddr3-server-memory-on-intel · ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platforms; the technique generalises to…Unscored
• ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platformsNCVD-2018-004-ecc-ddr3-server-memory-on-intel · ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platforms; the technique generalises to…Unscored
• PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolationNCVD-2019-001-pcie-address-translation-service · PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolation - affects any DMA-capable…Unscored
• PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolationNCVD-2019-005-pcie-address-translation-service · PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolation - affects any DMA-capable…Unscored
• AMD Zen 1 / Zen+ / Zen 2 - L1D cache way predictor: AMD's L1D way predictor hashes virtual addresses to predict whichNCVD-2020-001-amd-zen-1-zen-zen-2-l1d-cache-wa · AMD Zen 1 / Zen+ / Zen 2 - L1D cache way predictorUnscored