CVE-2026-64224: octeontx2-pf: fix double free in rvu_rep_rsrc_init()
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: fix double free in rvureprsrcinit()
rvureprsrcinit() allocates queue memory before calling otx2inithwresources(). When hardware resource setup fails, otx2inithwresources() already unwinds the partially initialized SQ, CQ, and aura state before returning an error. The representor error path then calls otx2freehwresources() again and can free the same resources a second time.
Fix this by splitting the cleanup labels so that a failure from otx2inithwresources() only releases queue memory. Keep the otx2freehwresources() call for failures that happen after hardware resource initialization completed successfully.
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 representor hardware.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in v6.13-rc1 - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in v7.1-rc3
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using the Linux kernel with OcteonTX2 representor hardware are the relevant exposure group. The affected path is in representor resource initialization, and reproducing it requires OcteonTX2 representor hardware.
What conditions are required to trigger the double free?
Queue memory must be allocated and hardware resource setup in otx2_init_hw_resources() must then fail. That function already unwinds partially initialized SQ, CQ, and aura resources, after which the representor error path can attempt to free those resources again.
How can I determine whether my kernel may still contain the issue?
Manual inspection confirmed the bug was still present in v7.1-rc3. The supplied stable-kernel references identify fixes, but the provided information does not specify all affected or fixed release versions.
What is the mitigation if an updated kernel cannot be deployed immediately?
The provided information identifies the vulnerable path as requiring OcteonTX2 representor hardware and a hardware-resource initialization failure. No configuration workaround or runtime mitigation is provided.