CVE-2026-90079 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init()
rvu_mbox_init() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ng_rvu object, leaking the first allocation when the pointer was overwritten on the second call.
Sharing one ng_rvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutex_init() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mbox_lock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvu_remove().
Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pci_enable_sriov() error paths.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified within the octeontx2-af driver involves a critical resource management flaw in the initialization sequence of AF-PF and AF-VF mailboxes, specifically affecting systems utilizing CN20K hardware with SR-IOV capabilities. The root cause lies in the improper handling of memory allocation for the ng_rvu object during repeated calls to rvu_mbox_init(). Originally, this function was invoked separately for AF-PF mailboxes during device probe and again for AF-VF mailboxes when SR-IOV is enabled. Each invocation allocated a new instance of the ng_rvu structure via standard kernel memory allocation functions. However, because the pointer storing this object was overwritten on the second call without freeing the previously allocated memory from the first call, a direct memory leak occurred. This initial flaw represents a classic case of resource leakage due to improper lifecycle management, where dynamic allocations are not correctly paired with corresponding deallocations under all execution paths.
The decision to refactor the codebase to share a single ng_rvu instance across both initialization paths was intended to consolidate state but inadvertently introduced more severe concurrency and cleanup defects. By sharing this structure, the error handling logic became flawed because it attempted to free all cn20k mailbox DMA resources and kfree() the shared ng_rvu object even when only one of the two init types failed. This aggressive teardown approach meant that if AF-VF initialization failed after AF-PF had already succeeded, the system would incorrectly release memory still in active use by the functional AF-PF mailbox handlers. Consequently, this leads to a state where live kernel memory is freed while remaining accessible, creating conditions ripe for use-after-free vulnerabilities and potential data corruption or system instability.
Furthermore, the refactored implementation introduced race condition risks related to mutex initialization. The code re-ran mutex_init() on the AF-VF path even though handlers associated with the AF-PF mailbox might still hold the rvu->mbox_lock at that moment. Re-initializing a locked mutex in Linux kernel programming is undefined behavior and can lead to deadlocks or corruption of internal lock state, compromising the integrity of synchronization mechanisms protecting shared resources. This flaw highlights a failure in understanding the atomicity requirements of initialization sequences when multiple subsystems share underlying data structures. The lack of proper separation between successful and failed initialization paths meant that partial failures did not result in clean rollbacks, leaving the driver in an inconsistent state with dangling pointers or unreleased DMA mappings.
The operational impact of these vulnerabilities is significant for systems relying on SR-IOV virtualization features provided by this hardware. Memory leaks contribute to gradual resource exhaustion over time, potentially leading to out-of-memory conditions that can crash the host system or degrade performance for all VMs running on it. More critically, the use-after-free scenarios and mutex re-initialization bugs create opportunities for local privilege escalation or denial of service attacks. An attacker with access to trigger SR-IOV configuration changes could exploit these race conditions and memory corruption issues to execute arbitrary code or crash the kernel. These flaws undermine the reliability and security posture of virtualized environments, as they allow a compromised guest VM or malicious user space process to impact the stability of the entire host infrastructure through driver-level exploitation vectors.
From an industry standards perspective, this vulnerability maps directly to CWE-401 Missing Release of Memory after Effective Lifetime, describing the failure to free allocated memory before losing all references to it. The concurrency issues related to mutex re-initialization and shared state management align with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding race conditions during initialization. In terms of attack vectors, these flaws facilitate exploitation techniques categorized under MITRE ATT&CK T1059 Command and Scripting Interpreter or more broadly within Privilege Escalation pathways where kernel memory corruption is leveraged to gain higher privileges. The improper cleanup in error paths also reflects CWE-755 Improper Handling of Exceptional Conditions, as the driver fails to correctly unwind state upon partial failure during device initialization.
Mitigation strategies must focus on correcting the lifecycle management and synchronization logic within the octeontx2-af driver. Developers should ensure that memory allocated for ng_rvu is managed using devm_kzalloc or similar managed resource functions to guarantee automatic cleanup if probe fails, thereby eliminating the initial leak. It is crucial to separate the initialization of AF-PF and AF-VF mailboxes so that failure in one path does not trigger teardown of resources belonging to the other successful path. Mutexes must be initialized exactly once before any concurrent access occurs, ensuring no re-initialization happens while locks are held by other threads or interrupt handlers. Error paths for both probe and SR-IOV enablement must explicitly release only the DMA mappings associated with the specific failing component, preserving resources allocated by successfully completed initialization steps. Regular static analysis and dynamic testing focusing on error handling paths in driver code can help prevent similar resource management defects in future updates.