CVE-2026-43296

What it actually does

This is a denial-of-service vulnerability in the Linux kernel's octeontx2-af network driver affecting Marvell/Cavium OcteonTX2 NIX hardware behavior. The issue is tied to hardware errata in the NIX send queue manager and packet scheduling engine: sticky send queue mode can stall when multiple send queues share the same scheduler queue and transmit concurrently; transitions between sticky and non-sticky transmission paths can deadlock the packet scheduling engine; and certain clock-gating conditions can cause transmit credit loss. When triggered under network transmit load, affected systems may experience network datapath stalls or loss of forward progress, causing degraded or unavailable network service. The kernel fix works around the errata by changing NIX_AF_SQM_DBG_CTL_STATUS register behavior: disabling SQM sticky operation, disabling the sticky-to-non-sticky transition path, and keeping the control-flow clock enabled to prevent credit drops.

Why it matters to the business

Successful exploitation can cause network service disruption on systems using affected OcteonTX2 networking hardware and vulnerable Linux kernel versions. For organizations that rely on these systems as firewalls, routers, packet processors, edge appliances, telecom infrastructure, storage nodes, or high-throughput Linux servers, the main consequence is availability loss: dropped connectivity, stalled packet forwarding, degraded throughput, service timeouts, failover events, or the need for manual recovery. The CVSS availability impact is high, but current public exploit maturity is listed as none, EPSS is low, and the issue is not in CISA KEV, so remediation should be prioritized based on hardware exposure and operational criticality rather than evidence of broad active exploitation.

How an attack unfolds

An attacker who can send traffic through or to a vulnerable system may attempt to create transmit patterns that cause multiple send queues to share a scheduler queue and transmit concurrently on affected OcteonTX2 NIX hardware. Under the vulnerable kernel driver configuration, this can exercise the sticky send queue manager behavior and sticky-to-non-sticky transition paths associated with known hardware errata. If the race or hardware state is reached, the send queue manager or packet scheduling engine can stall or lose transmit credits, resulting in halted or degraded network transmission. The attacker does not need authentication if the vulnerable network path is exposed, but practical exploitability depends on the presence of affected OcteonTX2 hardware, the vulnerable driver path being in use, traffic shaping/queue configuration, workload timing, and the ability to generate sufficient network conditions to trigger the stall.

How to fix it

Upgrade to a Linux kernel version that includes the octeontx2-af workaround for this issue. No exact fixed package versions were provided in the input, so use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, or hardware platform vendor. Prioritize systems using Marvell/Cavium OcteonTX2 NIX networking hardware and the octeontx2-af driver, especially devices in packet-forwarding, edge, telecom, storage, or high-availability roles. Where immediate patching is not possible, consider mitigations such as reducing exposure to untrusted high-volume traffic, rate-limiting suspicious traffic sources, reducing queue-sharing stress where configurable, failing traffic over to unaffected hardware, or scheduling proactive interface/device resets during maintenance windows. Because this is a kernel/hardware-driver issue, compensating controls may reduce trigger likelihood but should not be treated as a complete fix.

How to confirm the fix worked

Confirm that affected systems are running a kernel build containing the octeontx2-af change that modifies NIX_AF_SQM_DBG_CTL_STATUS to disable SQM sticky operation, disable the sticky-to-non-sticky transition path, and keep the control-flow clock enabled. Validate exposure by checking whether the host uses OcteonTX2 hardware and whether octeontx2-af-related drivers are loaded or present in kernel logs. After patching, perform controlled network stress or forwarding tests representative of production traffic and verify that interfaces continue transmitting without stalls, credit-loss symptoms, driver resets, or kernel warnings. Review vendor advisories and distribution changelogs for references to CVE-2026-43296, octeontx2-af, SQM sticky, PSE deadlock, NIX_AF_SQM_DBG_CTL_STATUS, or SQM/PSE stalls.

Typical attack path

1. Identify or infer a target running Linux on affected OcteonTX2 networking hardware using the octeontx2-af driver.
2. Send sustained or carefully patterned network traffic to or through the target so that transmit queues are exercised concurrently.
3. Cause multiple send queues to share scheduler resources and trigger sticky or sticky-to-non-sticky transmission behavior in the NIX datapath.
4. Trigger an SQM/PSE stall or transmit credit loss condition on the affected hardware.
5. Observe network degradation, packet forwarding failure, service timeouts, or device unavailability until the condition clears, the interface is reset, or the system is rebooted/patched.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs, system journals, network device logs, and monitoring telemetry for unexplained transmit stalls, packet forwarding interruptions, interface resets, watchdog warnings, or OcteonTX2/NIX/SQM/PSE-related errors during periods of elevated or unusual network traffic. Useful log sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg archives, network appliance event logs, interface counters, packet drop metrics, SNMP/telemetry data, and high-availability failover logs. Correlate any outage window with inbound or transit traffic spikes, repeated flows from the same sources, abnormal packet rates, or stress on multiple transmit queues. There are no known public exploit artifacts, malware indicators, or actor-specific indicators from the provided data; detection is therefore behavioral and operational rather than signature-based.

• octeontx2-af
• NIX_AF_SQM_DBG_CTL_STATUS
• SQM
• PSE
• sticky
• stall
• deadlock
• credit drop
• tx timeout
• NETDEV WATCHDOG
• transmit queue timed out
• dev_watchdog
• octeontx2
• otx2

What your security team should do

• Inventory Linux systems and appliances that use Marvell/Cavium OcteonTX2 networking hardware or load octeontx2-af-related kernel drivers.
• Prioritize patching internet-facing, edge, packet-forwarding, telecom, storage, and high-availability systems where a network stall would cause operational impact.
• Obtain fixed kernel packages from the applicable Linux distribution or appliance vendor and schedule reboot/maintenance windows as required for kernel replacement.
• Until patched, monitor for unusual traffic spikes followed by interface hangs, packet drops, forwarding failures, watchdog events, or octeontx2-af/NIX/SQM/PSE kernel log messages.
• Add operational runbooks for rapid failover, interface reset, or node reboot if affected systems experience unexplained network transmit stalls.
• Track vendor advisories for exact fixed versions and backports, since no fixed versions were provided in the source input.
• Because EPSS is currently low and there is no KEV listing, balance urgency against operational risk, but do not defer remediation on critical network infrastructure using the affected hardware.