CVE-2026-46249: Linux OcteonTX2 Kernel Crash During Kexec Reboot

Technical summary

The vulnerability exists in the octeontx2-af driver's shutdown sequence. The AF driver uses the RVUM (Resource Virtualization Unit Manager) block revision register as a signal that hardware initialization is complete. When the old kernel shuts down via kexec, the AF driver does not clear this register. In the new kernel, if the PF driver probes before AF reinitializes the hardware, the PF driver reads a non-zero RVUM revision value and incorrectly concludes AF has finished initialization. The PF driver then proceeds to interact with stale or uninitialized hardware state, including residual register values and incomplete device setup, leading to invalid memory access or hardware command failures that trigger a kernel panic. The fix involves explicitly clearing the RVUM block revision register during AF shutdown to ensure the PF driver correctly waits for AF to complete its full reinitialization sequence in the new kernel.

Business impact

Production systems relying on rapid reboots via kexec—common in high-availability clusters, containerized environments, or automated deployment pipelines—face unplanned downtime when this race condition occurs. Affected deployments cannot rely on kexec for fast restarts if both AF and PF drivers are modular; they would be forced to fall back to full power-cycle reboots, increasing maintenance windows. For service providers managing Marvell OcteonTX2-based networking appliances or SmartNIC deployments, this could disrupt traffic forwarding or control-plane operations if kexec-based updates or migrations are part of operational procedures. The impact is limited by the specific hardware platform and the uncommon combination of modular drivers and kexec reboots in most deployments.

Affected systems

The vulnerability affects Linux kernel installations with octeontx2-af and octeontx2-pf drivers on Marvell OcteonTX2 SoC-based systems. Affected hardware includes Marvell Octeon TX2 processors, which are used in networking appliances, data-center SmartNICs, and some ARM-based enterprise routers and switches. The vulnerability only manifests when: (1) both AF and PF drivers are compiled as loadable kernel modules (not built into the kernel), (2) the system uses kexec for rebooting, and (3) the PF driver initialization races ahead of AF reinitialization. Systems with the drivers built directly into the kernel (monolithic) or using traditional BIOS/UEFI reboots are not affected.

Exploitability

This vulnerability cannot be exploited remotely or by unprivileged users. It requires local system access and administrative privileges to trigger kexec reboot functionality. The triggering condition is inadvertent and non-malicious—a race condition during normal system boot after a kexec reboot. There is no known public exploit code, and the CISA Known Exploited Vulnerabilities catalog does not list this CVE, indicating no active weaponization or targeted exploitation. The practical barrier to exploitation is high: an attacker would need direct system access, ability to reboot, and system configuration combining modular drivers with kexec usage. For most users, the risk is operational (system crash during maintenance) rather than security-related.

Remediation

Apply a kernel update that includes the fix to the octeontx2-af driver shutdown sequence. The patch ensures the RVUM block revision register is explicitly cleared during AF shutdown, preventing the PF driver from misinterpreting hardware readiness state. After patching, systems can safely continue using kexec reboots with modular driver configurations. Alternatively, if a patched kernel is not yet available, temporarily mitigate by: (1) compiling AF and PF drivers as built-in modules rather than loadable modules to enforce proper initialization order, or (2) avoiding kexec reboots in favor of full power-cycle reboots until the kernel patch is deployed. Verify the kernel version includes the octeontx2-af shutdown fix by checking the driver source code or vendor release notes for your Linux distribution.

Patch guidance

Monitor your Linux distribution (Red Hat, Canonical, SUSE, or upstream kernel maintainers) for a kernel release incorporating the octeontx2-af shutdown fix. The patch resolves the issue by adding explicit register clearing in the AF driver's shutdown handler. When a patched kernel becomes available, test it in a non-production environment that replicates your kexec and modular-driver configuration before rolling out to production. If you use a commercial or appliance-based system with OcteonTX2 hardware, contact your vendor for a firmware or kernel update. Verify the patch is included by reviewing the kernel changelog or commit history for the octeontx2-af driver.

Detection guidance

Monitor system logs for kernel panics or oops messages occurring immediately after kexec reboots on OcteonTX2-based systems. Look for stack traces referencing octeontx2-pf or octeontx2-af drivers, particularly those showing invalid memory access in AF initialization or hardware command submission routines. If your deployment uses kexec reboots regularly, cross-reference crash timestamps with reboot events to identify if panics consistently follow kexec operations. In containerized or infrastructure-as-code environments, implement automated health checks post-reboot to catch unexpected crashes quickly. Enable kernel debugging and serial console logging if possible to capture full oops output for analysis.

Why prioritize this

Although scored MEDIUM (CVSS 5.5) due to local-access requirement and denial-of-service impact, prioritization should reflect your operational context. If your organization uses Marvell OcteonTX2 hardware and relies on kexec for fast reboots (common in cloud-native or high-availability settings), elevate priority to patch quickly, as this directly affects reliability. If you do not use this hardware platform or do not use kexec, deprioritize accordingly. The vulnerability is not an active threat on CISA's KEV catalog and does not pose confidentiality or integrity risks, reducing urgency compared to remote code execution flaws. However, any unplanned production crash is operationally disruptive, warranting timely patching where applicable.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects: Attack Vector Local (requires direct system access), Attack Complexity Low (race condition can occur reliably during kexec reboots), Privileges Required (administrative access needed to trigger kexec), User Interaction None, Scope Unchanged, Confidentiality None, Integrity None, Availability High (kernel panic). The score appropriately weights the high availability impact against the low-probability triggering conditions (specific hardware, modular driver config, kexec usage). This is not a high-severity vulnerability because it does not allow privilege escalation, data breach, or remote compromise; it is a reliability issue specific to a narrowly-used hardware platform and reboot mechanism.

Frequently asked questions