CVE-2026-46249

What it actually does

This is a local denial-of-service flaw in the Linux kernel's Marvell OcteonTX2 RVU administrative function and physical function driver initialization path. During a kexec reboot, hardware is not fully power-cycled, so stale AF state can survive from the previous kernel. If the AF and PF drivers are loaded as modules, the PF driver can probe before the AF driver has reinitialized the hardware. Because the PF driver incorrectly treats a leftover RVUM block revision value as proof that AF initialization is complete, it may access stale or inconsistent hardware state and crash the kernel. The issue affects availability only; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels on OcteonTX2/RVU-based hardware can crash during or after kexec-based reboot workflows, causing service interruption, failed maintenance automation, delayed patching, and potential loss of network-dependent workloads. The CVSS availability impact is high, but exploitation requires local access and specific hardware/driver conditions. EPSS is very low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, organizations that rely on kexec for fast reboots, crash recovery, or fleet automation should treat affected hosts as operationally fragile until patched.

How an attack unfolds

An attacker or misbehaving local process first needs the ability to influence reboot or driver-loading behavior on a host using the affected OcteonTX2 AF/PF kernel drivers. The attacker triggers or waits for a kexec reboot, where the platform hardware remains powered and AF state from the old kernel may persist. On the new kernel, if the PF driver probes before the AF driver has reset and reinitialized the RVU hardware, the PF driver may read a stale RVUM revision value and incorrectly conclude the AF is ready. The PF driver then accesses invalid hardware state, resulting in a kernel crash and denial of service. In practice, this is most likely to be triggered through local administrative or semi-administrative workflows such as kexec reboot orchestration, module load ordering, or automated recovery operations rather than by a remote network request.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the octeontx2-af shutdown path, which clears the RVUM block revision during AF shutdown so the PF driver cannot mis-detect AF readiness after kexec. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, appliance vendor, or hardware platform vendor once available. As temporary mitigations, avoid kexec reboots on affected OcteonTX2/RVU systems, prefer full power-cycle reboots for maintenance, ensure AF initializes before PF where operationally possible, and avoid unnecessary unloading/reloading of the OcteonTX2 AF/PF modules. Restrict local privileges that can initiate kexec, load kernel modules, or control reboot workflows.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for clearing the RVUM block revision during octeontx2 AF shutdown. Validate exposure by checking whether the system uses Marvell OcteonTX2/RVU hardware and loads octeontx2 AF/PF drivers as modules. Review package changelogs or kernel source for the octeontx2-af fix related to PF driver crash during kexec booting. After patching, perform a controlled kexec reboot test on representative non-production hardware and verify that the PF driver no longer crashes when probing after reboot. Confirm there are no new kernel panics, oops reports, kdump captures, or pstore entries associated with octeontx2 driver initialization.

Typical attack path

1. Gain local access to a Linux system using affected OcteonTX2/RVU kernel drivers.
2. Identify that AF and PF drivers are built or loaded as modules and that kexec reboot workflows are available.
3. Trigger or induce a kexec reboot so hardware state is preserved rather than fully power-cycled.
4. Cause or rely on PF driver probing before AF has reinitialized the RVU hardware.
5. The PF driver misinterprets stale RVUM block revision state as AF readiness.
6. Kernel driver access to stale hardware state causes a crash, producing a local denial of service.

How to detect it

To assess whether this was already triggered, review persistent kernel logs, systemd journal, /var/log/kern.log, /var/log/messages, kdump vmcores, pstore records, netconsole output, and out-of-band management event logs for crashes occurring immediately after kexec reboot or during OcteonTX2 driver probing. Look for a sequence where a kexec reboot starts, the new kernel loads octeontx2 AF/PF modules, and a kernel panic, oops, watchdog reset, or unexpected reboot follows. Correlate timestamps with administrative reboot automation, crash-recovery tooling, module load events, and hardware management logs. Because the flaw is a crash condition rather than code execution, there may be no attacker-created file or network artifact; evidence is most likely in kernel crash telemetry and repeated kexec-related boot failures on affected hardware.

• octeontx2-af
• octeontx2_pf
• octeontx2-pf
• octeontx2_af
• RVUM
• RVU
• kexec
• kexec_core
• Starting new kernel
• Kernel panic
• Oops:
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• /sys/module/octeontx2_af
• /sys/module/octeontx2_pf
• /lib/modules/*/drivers/net/ethernet/marvell/octeontx2/af/octeontx2_af.ko
• /lib/modules/*/drivers/net/ethernet/marvell/octeontx2/nic/rvu_nicpf.ko
• /sys/fs/pstore
• /var/crash
• vmcore

What your security team should do

• Inventory Linux systems using Marvell OcteonTX2/RVU hardware and octeontx2 AF/PF kernel drivers.
• Prioritize patching systems that use kexec-based reboot, crash recovery, or automated maintenance workflows.
• Apply the distribution or vendor kernel update containing the octeontx2-af RVUM shutdown-state fix when available.
• Until patched, disable or avoid kexec reboots on affected systems and use full power-cycle reboots for maintenance windows.
• Restrict local permissions for kexec, kernel module loading, and reboot orchestration to trusted administrators and automation only.
• Add monitoring for kernel panics or oops events involving octeontx2-af, octeontx2-pf, RVU, RVUM, or kexec boot sequences.
• Collect kdump, pstore, netconsole, and persistent journal data from affected hosts before rebooting after a crash.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in KEV, balance urgency against exposure: prioritize specialized affected hardware over general Linux fleets.