CVE-2026-80654 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
soc: xilinx: Shutdown and free rx mailbox channel
A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The identified vulnerability resides within the Xilinx System on Chip subsystem of the Linux kernel, specifically affecting the mailbox communication mechanism used for inter-processor messaging. The core issue stems from a logic error in the device removal callback function where an incorrect conditional check prevents the proper shutdown and deallocation of the receive mailbox channel. During the driver probe phase, the system correctly requests the receive mailbox channel using mbox_request_channel_byname to establish a communication path with remote processors or firmware components. However, when the device is subsequently removed from the system, either through hot-unplug events or module unloading, the cleanup routine fails to properly terminate this active connection due to flawed null-check logic.
This logical flaw results in a critical use-after-free vulnerability combined with resource leakage. Because the receive channel is not explicitly shut down before being released, it remains capable of receiving incoming messages even after the driver has detached and potentially freed associated memory structures. If an external entity or remote processor sends data to this orphaned channel during the window between detachment and final cleanup, the kernel may attempt to process these messages using stale pointers or deallocated buffers. This scenario creates a classic use-after-free condition where the system accesses memory that is no longer validly owned by the driver, potentially leading to arbitrary code execution, privilege escalation, or immediate kernel panic depending on how the malformed data interacts with internal structures.
Furthermore, the failure to properly free the channel resources constitutes a resource leak vulnerability. Over time, if this device removal and re-insertion cycle occurs repeatedly without proper cleanup, it can exhaust available mailbox channels in the system. This denial of service condition prevents other devices or drivers from establishing necessary communication links, effectively degrading system functionality. The combination of memory safety violations and resource exhaustion highlights a significant deficiency in the driver's lifecycle management code, particularly regarding error handling paths that rely on specific state variables to determine cleanup actions.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper synchronization of resource lifecycles. It also relates to CWE-772, Missing Release of Resource after Effective Lifetime, given the failure to release the mailbox channel resources during device removal. In terms of attack vectors and techniques, this flaw could be leveraged in an ATT&CK context under T1059, Command and Scripting Interpreter, if exploited for code execution, or more broadly as part of privilege escalation attempts where kernel memory corruption is used to gain higher system privileges. The vulnerability primarily affects local attackers who have the ability to trigger device removal events or manipulate hardware states that invoke the remove callback while external communication channels remain active.
To mitigate this risk, it is imperative to correct the conditional logic within the driver's remove function to ensure that the receive mailbox channel is explicitly shut down before any memory deallocation occurs. This involves verifying that rx_chan is not NULL and then invoking the appropriate shutdown API provided by the mailbox framework to gracefully terminate message reception. Additionally, developers must ensure that all allocated resources associated with the mailbox are properly released using standard kernel cleanup routines after the channel has been safely disabled. Regular code audits focusing on device lifecycle management in out-of-tree drivers can help identify similar patterns where resource teardown sequences do not strictly follow the initialization order or fail to account for asynchronous message delivery scenarios.