[Bug] pci: unvalidated device-controlled MSI-X table BIR/offset in msix_table_remap() gives arbitrary physical memory write at boot #11985

• RT-Thread Version: master (v5.4.0-dev, commit 5d1fb66, 2026-10-15); affected since v5.2.0
  (introduced by 2168ed8, 2024-05-30, "[DM/Feature] Basic PCI/PCIe bus")
• Affected area: Device drivers → components/drivers/pci/ (MSI/MSI-X core, msi/msi.c)
• Architecture: ARM64 (any arch with RT_PCI_MSI; verified on aarch64)
• Board / hardware: QEMU qemu-virt64-aarch64 official default .config
  (RT_USING_PCI=y, RT_PCI_MSI=y, RT_PCI_ECAM=y, RT_NVME_PCI=y, RT_PIC_ARM_GIC_V2M=y),
  stock nvme PCIe device. Any board where a driver enables MSI-X at probe (nvme, ivshmem, virtio-pci) is affected.
• Develop Toolchain: arm-gnu-toolchain-13.2.Rel1 + scons; QEMU 9.2.3 (device-side injection via local
  QEMU nvme model patch to forge the read-only capability register)

Describe the bug

msix_table_remap() (components/drivers/pci/msi/msi.c:737) reads the device-controlled,
read-only MSI-X Table Offset register (PCIR_MSIX_TABLE, capability offset +4) and uses it without
any validation:

rt_pci_read_config_u32(pdev, pdev->msix_cap + PCIR_MSIX_TABLE, &table_offset);
bir = (rt_uint8_t)(table_offset & PCIM_MSIX_BIR_MASK);      /* 0x7 -> bir = 0..7 */

if (pdev->resource[bir].flags & PCI_BUS_REGION_F_NONE) { ... return RT_NULL; }

table_base_phys = pdev->resource[bir].base + (table_offset & ~PCIM_MSIX_BIR_MASK);
return rt_ioremap((void *)table_base_phys, entries_nr * PCIM_MSIX_ENTRY_SIZE);

Three validations required by the spec / carried by Linux are missing:

1. BIR range: PCI spec allows BIR = 0–5, but bir here is masked with 0x7 (0–7) and used directly
   as an index into pdev->resource[RT_PCI_BAR_NR_MAX = 6]. With bir = 6 the access aliases the
   adjacent member pdev->rom (include/drivers/pci.h:161-162), which is {base:0, size:0, flags:0}
   for a device without an option ROM. Since PCI_BUS_REGION_F_MEM == 0, the "invalid BAR" guard
   (flags & PCI_BUS_REGION_F_NONE) passes, and table_base_phys = 0 + (table_offset & ~7) becomes an
   absolute, fully attacker-chosen physical address (29 bits — covers all RAM on the reference board).
2. Table-within-BAR bound: even for bir = 0..5 pointing at a real BAR, table_offset (up to
   0xFFFFFFF8) is never checked against resource[bir].size.
3. Table size consistency: entries_nr comes from a separate read of PCIR_MSIX_CTRL
   (msix_capability_init), so a device returning inconsistent reads makes the final masking loop
   (0x80000000 per entry, up to 2048 entries = 32 KB) run past the remapped region.

After the bogus rt_ioremap() succeeds (it performs no physical-address validation,
components/mm/ioremap.c:92), MSI-X initialization reads and writes through the mapping:

• msix_setup_msi_descs() reads entry+0xc (kernel-memory disclosure path);
• rt_pci_msi_write_msg() writes msg.address_lo (GIC MSI doorbell, e.g. 0x08020040),
  msg.address_hi (0) and msg.data (SPI number) at entry+0/4/8;
• the final loop sprays 0x80000000 over every entry's vector_ctrl.

To reproduce (full chain, official image, zero interaction)

Reference: rtthread-ws/audit/RT_pci/exp/ (patch, scripts, GDB and console logs).

1. Build stock bsp/qemu-virt64-aarch64 (official default config) — no source change needed.
2. Control: boot QEMU (-M virt,its=on,gic-version=2) with a stock nvme device → boots to msh,
   nvme0n1 registers, list_blk works (control-stock.log). GDB shows the exact chain runs at boot:
   pci_nvme_probe → rt_pci_msix_enable → msix_capability_init → msix_table_remap
   (gdb-msix-hit.log).
3. Attack: same command, with the device's read-only MSI-X Table Offset register forged to
   0x4023f06e (= phys &rt_interrupt_enter_hook 0x4023f068 | bir 6) — done with a small local QEMU
   nvme-model patch (qemu-nvme-msix-inject.patch, emulating a device whose firmware reports
   ill-formatted MSI-X metadata; the real MSI-X table MMIO stays inside BAR0).
4. Observed (attack2-gdb.log, attack2-console.log):
   • GDB watchpoint on the remapped entry: kernel writes 0x08020040 (MSI doorbell) into physical
     0x4023f068; backtrace rt_pci_msi_write_msg ← rt_pci_msi_setup_irqs ← msix_capability_init ← rt_pci_msix_enable ← pci_nvme_probe;
   • physical memory before: all zeros, after: MSI message fields;
   • on the next interrupt the corrupted hook is called:
     exception info: esr.EC:0x21, epc:0x0000000008020040, Instruction abort from current exception level
     in an endless exception loop — control flow hijacked to the value the device planted.

Expected behaviour

bir must be range-checked (bir >= RT_PCI_BAR_NR_MAX → reject) and table_offset + entries_nr * 16 must be validated against resource[bir].size before rt_ioremap()
(also reject pdev->rom/unassigned BARs and size == 0).

Actual behaviour

The kernel maps and reads/writes an arbitrary attacker-chosen physical address during boot-time driver
probe, corrupting kernel memory (function-pointer hijack demonstrated; EPC equals the planted value),
then dead-loops in the exception handler.

Other additional context

• Attack prerequisite (explicit): a malicious or compromised PCIe device (e.g. NVMe SSD with
  malicious firmware, supply-chain-tampered peripheral, or forged device on an exposed M.2/PCIe slot)
  that reports an ill-formatted MSI-X capability. No software privilege or user interaction is needed;
  the vulnerable path runs automatically during boot on the official qemu-virt64-aarch64 default config.
• Severity: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 6.8 — the score is capped by the
  physical/peripheral vector, but the technical impact is arbitrary kernel physical-memory read/write
  at boot, i.e. full kernel compromise from a malicious device.
• CWE: CWE-787 (out-of-bounds write) / CWE-129 (improper validation of array index) /
  CWE-20 (improper input validation of device-controlled field).
• Versions: introduced by 2168ed8 (2024-05-30); first affected release v5.2.0; v5.2.0–v5.3.0
  and master (2026-11-05) verified affected; no fix or existing report found on GitHub.
• Relation to existing reports: new — not related to any NVD CVE or existing issue (the RT-Thread
  PCI framework has had no security audit coverage; [Bug] nvme: kernel heap memory leak per inactive namespace in nvme_scan_device() exhausts system heap and can brick boot #11919 concerns nvme namespace scanning, a
  different root cause).