CVE-2026-43157

What it actually does

This is a Linux kernel availability flaw in the octeontx2-af CGX driver. During CGX LMAC initialization, the driver allocates RX and TX flow-control bitmaps, but older vulnerable code does not free those bitmaps during teardown. Repeated driver unbind/rebind cycles can therefore leak kernel memory. Over time, the leaked allocations can accumulate and contribute to memory pressure, kernel instability, or denial of service. The issue is local, requires the ability to trigger driver teardown/reinitialization, and does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with the octeontx2-af CGX networking driver may become unstable or unavailable if the vulnerable driver is repeatedly cycled. The practical risk is highest for specialized Linux deployments using Marvell OcteonTX2/CGX networking hardware or platforms that expose driver management to local users or automation. Public exploitation likelihood appears low based on the low EPSS score, no known KEV listing, no ransomware association, and no public exploit maturity, but unplanned downtime of network appliances, edge systems, or embedded Linux platforms could still have operational impact.

How an attack unfolds

An attacker first needs local access to a system running a vulnerable Linux kernel with the octeontx2-af CGX driver present and associated hardware or code paths available. The attacker then repeatedly triggers driver teardown and initialization, such as by unbinding and rebinding the relevant device driver where permissions allow it. Each cycle causes the RX/TX flow-control bitmaps allocated during initialization to remain unfreed during teardown. Repetition causes small kernel memory leaks to accumulate. If sustained long enough, this can increase memory pressure and potentially degrade system stability or availability, resulting in a local denial of service. There is no indication that this flaw enables code execution, privilege escalation, data theft, or remote compromise by itself.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or hardware vendor that includes the octeontx2-af CGX bitmap teardown fix. If no packaged fixed version is listed by the distribution, track the vendor advisory or stable kernel release containing the fix for freeing rx_fc_pfvf_bmap and tx_fc_pfvf_bmap in cgx_lmac_exit(). Where immediate patching is not possible, restrict local shell access, restrict sudo/CAP_SYS_ADMIN privileges, prevent untrusted users from writing to sysfs driver bind/unbind interfaces, and avoid operational automation that repeatedly reloads or rebinds the octeontx2-af driver. On systems that do not use OcteonTX2/CGX hardware, disable or avoid loading the affected driver where feasible.

How to confirm the fix worked

Confirm the running kernel package or appliance firmware includes the upstream or vendor fix for octeontx2-af CGX bitmap cleanup. Verify that vulnerable code paths are no longer present by reviewing the vendor changelog or kernel source for freeing of rx_fc_pfvf_bmap and tx_fc_pfvf_bmap in the CGX LMAC teardown path. On test systems, enable kmemleak or kernel memory leak diagnostics and repeatedly unbind/rebind the octeontx2-af driver; a fixed system should not report persistent unreferenced allocations associated with rvu_alloc_bitmap or cgx_probe after teardown and cleanup. Also confirm that unprivileged users cannot write to driver bind/unbind sysfs paths and that only trusted administrators can reload kernel drivers.

Typical attack path

1. Obtain local access to a vulnerable Linux system where the octeontx2-af CGX driver is loaded or can be exercised.
2. Identify CGX/octeontx2-related PCI devices or driver bindings exposed through sysfs or administrative tooling.
3. Repeatedly trigger driver unbind and rebind operations, or otherwise force CGX LMAC teardown and reinitialization.
4. Cause rx_fc_pfvf_bmap and tx_fc_pfvf_bmap allocations to leak on each teardown cycle.
5. Continue cycling the driver until kernel memory pressure increases enough to affect network functionality, system stability, or availability.

How to detect it

To determine whether this issue may have already been exercised, review kernel logs and audit records for repeated driver unbind/rebind activity involving octeontx2-af, CGX, or related PCI devices. Useful sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, auditd logs for writes to /sys/bus/pci/drivers/*/unbind and /sys/bus/pci/drivers/*/bind, shell history for administrative accounts, sudo logs, and configuration-management job logs. If kmemleak is enabled, look for unreferenced allocations with backtraces containing rvu_alloc_bitmap and cgx_probe. Also investigate unexplained memory pressure, OOM events, network interface resets, or service disruption correlated with repeated PCI driver cycling. There are no known public threat actors or ransomware campaigns associated with this vulnerability, so detection should focus on local misuse, faulty automation, and post-fact kernel memory leak artifacts rather than known malware signatures.

• rvu_alloc_bitmap
• cgx_probe
• cgx_lmac_init
• cgx_lmac_exit
• rx_fc_pfvf_bmap
• tx_fc_pfvf_bmap
• octeontx2-af
• unreferenced object (size 16)
• /sys/bus/pci/drivers/octeontx2-af/unbind
• /sys/bus/pci/drivers/octeontx2-af/bind
• kmemleak: unreferenced object
• echo * > /sys/bus/pci/drivers/octeontx2-af/unbind
• echo * > /sys/bus/pci/drivers/octeontx2-af/bind

What your security team should do

• Prioritize patching Linux systems, appliances, and embedded platforms that use Marvell OcteonTX2/CGX networking hardware or load the octeontx2-af driver.
• Inventory systems for the octeontx2-af module, CGX devices, or related PCI driver bindings to determine actual exposure.
• Restrict local administrative capabilities that allow driver unbind/rebind, module reload, or writes to sysfs driver control paths.
• Monitor for repeated octeontx2-af, CGX, or PCI driver bind/unbind activity, especially outside maintenance windows.
• Use kernel memory leak diagnostics on high-risk platforms if unexplained memory pressure or instability is observed.
• Treat this primarily as a local availability risk; do not over-prioritize internet-facing remediation unless affected systems also expose local management paths to untrusted users.