Linux kernel (drivers/pci/pcie): The ASPM link state keeps a raw pointer to function 0 of a multi-function device.

CVSS 6.7CVE-2023-53446Kernel, userspace & hypervisorcurated

Impact

The ASPM link state keeps a raw pointer to function 0 of a multi-function device. Remove that function and the pointer dangles; any later ASPM policy change dereferences freed memory, which KASAN catches as a slab use-after-free in the link-state walk. This matters on GPU nodes because the cards themselves are multi-function - a GPU with its companion audio function is the standard layout - so the removal that arms the bug is an ordinary device-management action.

Who can reach it

Needs write access to PCI sysfs on the host: remove a function via /sys/bus/pci/devices/<dev>/remove, then write the ASPM policy knob (or let anything else walk the link state). That is root, or a privileged container with /sys mounted writable - not a plain tenant container and not a guest. Worth tracking anyway because driver-rebind and device-reclaim automation performs exactly this remove step on multi-function cards, so the dangling pointer can be left armed by routine operations and tripped later by an unrelated power-management change.

What to do

Boot a kernel that disables ASPM and frees the pcie_link_state when any child function is removed. Interim: do not expose writable PCI sysfs (remove, and the pcie_aspm policy module parameter) inside containers, and avoid per-function removal on multi-function cards - remove the whole device instead.

References

https://git.kernel.org/stable/c/666e7f9d60cee23077ea3e6331f6f8a19f7ea03f https://git.kernel.org/stable/c/7badf4d6f49a358a01ab072bbff88d3ee886c33b https://nvd.nist.gov/vuln/detail/CVE-2023-53446

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.