Look up another CVE · open CVE-2026-64222 in the interactive tracker
CVE-2026-64222
octeontx2-pf: avoid double free of pool->stack on AQ init failure
Published 2026-07-24 (3 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-64222 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 | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path. Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3. Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.
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/marvell/octeontx2/nic/cn20k.c
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
- What this is
- MARVELL OCTEONTX2 PHYSICAL FUNCTION DRIVERMAINTAINERS section matched on drivers/net/ethernet/marvell/octeontx2/nic/ · netdev@vger.kernel.org · Maintained
- Kernel module
- rvu_nicpf
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_MARVELL|CONFIG_OCTEONTX2_PF' /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 rvu_nicpfPrints 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 does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- n
- not enabled on any flavour - this release does not build the code
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_NET_VENDOR_MARVELL, CONFIG_OCTEONTX2_PF
- 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-07-24 (3 months ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.8% 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 |
|---|---|---|
| 5.6 | 5.10.259 | e6e9bc0bf963 |
| 5.6 | 5.15.210 | b92e7ea408b6 |
| 5.6 | 6.1.176 | 94192b057933 |
| 5.6 | 6.6.143 | 4c29603498b0 |
| 5.6 | 6.12.93 | 0488a0bb344f |
| 5.6 | 6.18.35 | 0d9b9d7dbef9 |
| 5.6 | 7.0.11 | c4b8c5d51632 |
| 5.6 | 7.1 | 9b244c242bec |
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 vulnerable initialization is reached through local netdevice operations such as RTM_SETLINK or ethtool reconfiguration, ultimately invoking ndo_open; received network packets do not directly reach it.
- AC:HAttack complexity, high
- The attacker can fill the fixed mailbox by configuring many queues, but exploitation additionally requires an AF/NPA synchronization error or timeout. Legitimate mailbox users are serialized, so this failure is not reliably attacker-controlled.
- PR:LPrivileges required, low
- CAP_NET_ADMIN is required in the device's owning network namespace. OcteonTX2 VFs can reasonably be delegated to a user-owned network namespace, where namespace-level administration suffices without initial-namespace root.
- UI:NUser interaction, none
- The attacker can initiate the interface-open or reconfiguration operation directly, without action by another user.
- S:UScope, unchanged
- The double free corrupts the kernel managing the affected PF or VF but does not inherently cross a VM, IOMMU, or separate security-authority boundary.
- C:HConfidentiality impact, high
- The repeated release of coherent DMA pages can create overlapping allocations, while the stale qmem object can also be reclaimed and its DMA metadata influenced. This memory corruption can plausibly expose arbitrary kernel memory.
- I:HIntegrity impact, high
- Double-freeing DMA-backed pages can corrupt the page allocator and produce overlapping ownership, enabling arbitrary kernel-memory modification or control-flow hijacking.
- A:HAvailability impact, high
- The double DMA/page release can immediately cause allocator warnings, an oops, or a kernel panic, and corrupted allocator state can crash the system later.