Look up another CVE · open CVE-2026-72329 in the interactive tracker
CVE-2026-72329
net/liquidio: drop cached VF pci_dev LUT
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72329 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/cavium/liquidio/lio_main.c
drivers/net/ethernet/cavium/liquidio/octeon_device.h
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
- What this is
- CAVIUM LIQUIDIO NETWORK DRIVERMAINTAINERS section matched on drivers/net/ethernet/cavium/liquidio/ · netdev@vger.kernel.org · Orphan
- Kernel module
- liquidio
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_LIQUIDIO|CONFIG_NET_VENDOR_CAVIUM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w liquidioPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_LIQUIDIO, CONFIG_NET_VENDOR_CAVIUM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.19%, higher than 8.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.10 | 6.18.57 | 08ff33dce6f9 |
| 4.10 | 7.1.5 | 81acef3a247f |
| 4.10 | 7.2 | 5c0e3ba4f500 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in the Cavium LiquidIO CN23XX PF driver handling OCTEON_VF_FLR_REQUEST over the PCIe SR-IOV hardware mailbox, not via network packets; exploitation requires code running against an assigned VF (e.g., a cloud VM with SR-IOV passthrough).
- AC:LAttack complexity, low
- VF pci_dev pointers in dpiring_to_vfpcidev_lut[] are stale immediately after SR-IOV enable because pci_get_device() drops references during iteration; an attacker controlling VF driver teardown can reliably send OCTEON_VF_FLR_REQUEST and repeat FLR attempts to influence heap reuse.
- PR:NPrivileges required, none
- In the highest-impact deployment (multi-tenant cloud with VF passthrough), a tenant needs no host administrator privileges—only control of the assigned VF from within their VM—to trigger PF mailbox processing and pcie_flr() on the dangling pci_dev.
- UI:NUser interaction, none
- No victim interaction is required; triggering VF driver removal or module unload during octeon_destroy_resources() automatically sends the FLR mailbox request to the PF without any user action on the host.
- S:CScope, changed
- The vulnerable PF driver executes in the host kernel but is triggered from an isolated VF guest/tenant via the SR-IOV mailbox, crossing the VM/tenant security boundary into host kernel context.
- C:HConfidentiality impact, high
- This is a use-after-free of struct pci_dev; pcie_flr() and pci_dev_reset_iommu_prepare() dereference freed pci_dev fields, enabling arbitrary kernel memory disclosure if the attacker reclaims the object via heap spraying.
- I:HIntegrity impact, high
- UAF of pci_dev causes pcie_flr() to issue PCI Express FLR config writes and IOMMU blocking on attacker-influenced memory, providing memory corruption primitives that can be leveraged for arbitrary kernel write or code execution.
- A:HAvailability impact, high
- Dereferencing a stale pci_dev in pcie_flr() can oops or panic the host kernel, and issuing FLR/IOMMU operations against the wrong PCI function can disrupt host networking and device availability.