[Bug] nvme: kernel heap memory leak per inactive namespace in nvme_scan_device() exhausts system heap and can brick boot #11919

Title: [Bug] nvme: kernel heap memory leak per inactive namespace in nvme_scan_device() exhausts system heap and can brick boot

RT-Thread Version
v5.2.0, v5.2.1, v5.2.2, v5.3.0 and current master (introduced by commit 945114f, 2024-11-24, "[DM/FEATURE] Support NVME (#9591)")

Affected area
Device drivers (components/drivers/nvme/nvme.c)

Hardware-BSP vendor
QEMU (qemu-virt64-aarch64 BSP, default .config already enables RT_USING_NVME + RT_NVME_PCI); any board with an NVMe controller

Architecture
ARM64 (also affects any arch using this driver)

Board and hardware details
QEMU virt machine (-M virt) with a stock nvme PCI device (QEMU 9.2.3, unmodified). No special hardware is needed: any NVMe controller whose Identify Controller nn (Number of Namespaces) field is larger than its count of active namespaces triggers the leak. Note QEMU itself always reports nn = 256 while exposing 1 namespace, which is legal per the NVMe spec, so the leak reproduces with a fully compliant device response.

Develop Toolchain
GCC (aarch64 toolchain), scons, QEMU 9.2.3

Describe the bug

nvme_scan_device() (components/drivers/nvme/nvme.c) iterates nsid = 1 .. nn using the device-controlled nn field from the Identify Controller response, and allocates a 4480-byte struct rt_nvme_device (rt_calloc) before issuing the per-namespace Identify command:

for (rt_uint32_t nsid = 1; nsid <= number_of_ns; ++nsid)
{
    struct rt_nvme_device *ndev = rt_calloc(1, sizeof(*ndev));   /* 4480 B */
    ...
    if ((err = nvme_identify(nvme, nsid, 0, id)))
    {
        goto _free_res;      /* leak: ndev not freed */
    }
    if (!id->nsze)
    {
        continue;            /* leak: ndev not freed */   <-- main path
    }
    ...

Every namespace that reports nsze == 0 (inactive/allocated-but-not-active namespaces — a perfectly legal response; e.g. QEMU returns an all-zero structure for every non-attached nsid), and every failed identify, leaks 4480 bytes (4536 bytes with the memheap header) of the kernel system heap. The leaked memory is never recovered; the reference is simply dropped.

Measured impact, full-chain on the official qemu-virt64-aarch64 BSP with the default config (free via the free msh command):

So with the stock, unmodified QEMU NVMe device (a legal nn = 256 response), every boot loses ~1.8 % of a 64 MiB kernel heap. Repeated controller re-registration (hot-plug / surprise removal + rescan) accumulates the leak linearly.

With a larger device-controlled nn (malformed or malicious controller firmware, e.g. nn = 0xFFFFFF), the loop keeps allocating until the kernel heap is fully exhausted, which happens deterministically before main() can start the shell — the system never reaches the msh prompt (boot bricked):

=== OOM POINT === nsid=14758 avail=600 maxused=67108264      (64 MiB heap)
#0  nvme_scan_device (nvme=0xffff000000263b78, number_of_ns=16384) at components/drivers/nvme/nvme.c:1079
#1  rt_nvme_controller_register (nvme=0xffff000000263b78) at components/drivers/nvme/nvme.c:1216
#2  pci_nvme_probe (pdev=0xffff000000263838) at components/drivers/nvme/nvme-pci.c:95
#3  pci_probe (dev=0xffff00000000038) at components/drivers/pci/pci.c:1050

(serial console output stops permanently after hello rt-thread; no msh /> prompt is ever printed)

To reproduce

1. Build the official qemu-virt64-aarch64 BSP (default .config, RT_USING_NVME is already on).
2. Create a raw disk image, boot with a stock QEMU nvme device (QEMU reports nn=256 for 1 active namespace — no device model modification needed):

   dd if=/dev/zero of=/tmp/nvme.img bs=1M count=16
   qemu-system-aarch64 -M virt,gic-version=2 -cpu max -m 128M \
       -kernel rtthread.bin -serial <console> \
       -drive file=/tmp/nvme.img,if=none,id=nvme0 \
       -device nvme,drive=nvme0
   

3. Run free in msh and compare with a boot without the nvme device: ~1.1 MiB of the kernel heap is gone after a single boot; list_blk shows the disk otherwise working normally.
4. GDB confirmation (gdb-multiarch): break at the if (!id->nsze) continue; branch (nvme.c:1091) — it is hit once per inactive nsid (2..256 with stock QEMU), and system_heap->available_size drops by exactly 4536 bytes on each hit.

Expected behaviour
ndev must be allocated only after the namespace is known to be active (nsze != 0 and identify succeeded), or freed on the nsze == 0 / identify-error paths; nn should also not be trusted as a loop bound without an upper limit (e.g. cap by mnan or a sane maximum, and/or use the Active Namespace ID list, CNS 02h).

Actual behaviour
4480 bytes leaked per inactive namespace per controller registration; kernel heap exhaustion and an unbootable system with a large device-reported nn.

Other additional context

• CWE-401 (Missing Release of Memory after Effective Lifetime).
• CVSS 3.1: AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 4.9 (Medium).
• Attack prerequisites (explicit): the attacker must attach a malformed/malicious NVMe controller (AV:P) for the heap-exhaustion/brick outcome; the per-boot 1.1 MiB leak however requires no attacker at all — any compliant drive reporting nn larger than its active namespace count triggers it (QEMU's stock nvme device is one example, tested here).
• Same device-controlled-metadata parser family as previously reported mtd-cfi ([Bug] mtd-cfi erase-region parser has an off-by-one out-of-bounds write when sect_count reaches CFI_FLASH_SECT_MAX #11272) and usbhost ([Bug] legacy usbdevice core trusts host-controlled wLength for Microsoft OS Compatible ID descriptor responses, causing heap out-of-bounds read and information disclosure #11287/[Bug] legacy USB host trusts device-controlled bNumInterfaces and can trigger out-of-bounds access in fixed interface array #11288) issues, which were accepted.
• No existing CVE/issue covers this (searched NVD, this repo's issues/PRs/branches; nvme-related items are [DM/FEATURE] Support NVME #9591 feature, [DM/NVME] Fixup the QUEUE alloc errorno check #10672 errno fix, [dm][nvme] replace the CPU physical address to DMA address #11650 DMA-address fix).
• Verified present in master (blob 260e1fb04) as of 2026-10-23; introduced in 945114f (first release containing it: v5.2.0).