CVE-2026-98615 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: Set AW_FLUSH_MODE alongside AW_FLUSH when flushing the mailbox
When tearing down the FW mailbox Rx ring, fbnic_mbx_reset_desc_ring() writes AW_CFG with FLUSH set and everything else, BME included, cleared. Clearing BME halts the device's writes to the host but leaves the staged requests parked in the PUL write pipeline rather than draining them, so on the write path FLUSH alone never terminates the outstanding requests and the flush the firmware waits on never completes.
Add the FLUSH_MODE definition and set both bits so the staged writes drain out of the pipeline on their own. BME stays cleared, so nothing lands on the host; it is restored later in fbnic_mbx_init_desc_ring() when the ring is rebuilt, once the outstanding writes are gone.
The read path is unaffected. AR_CFG has no equivalent mode bit and AR_FLUSH terminates the outstanding reads by itself, so it is left as is.
Both writes remain plain stores rather than read-modify-writes. That is deliberate: the matching write in fbnic_mbx_init_desc_ring() restores BME and the TLP attributes, and clears both flush bits as a side effect.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified within the Linux kernel's eth_fbnic driver stems from an incomplete hardware register configuration during the teardown of the firmware mailbox receive ring. Specifically, the function fbnic_mbx_reset_desc_ring() is responsible for resetting the descriptor ring to prepare it for reuse or shutdown. In its original implementation, this routine writes to the AW_CFG (Address Window Configuration) register with only the FLUSH bit set while clearing all other bits, including BME (Bus Master Enable). This specific sequence of operations introduces a critical synchronization flaw in how the hardware handles pending write transactions destined for the host memory.
The core technical flaw lies in the behavior of the PUL write pipeline within the fbnic device architecture. When BME is cleared while FLUSH remains set, the device halts new writes to the host but fails to drain requests that are already staged or parked within the internal write pipeline. Consequently, the FLUSH command alone is insufficient to terminate these outstanding requests because they remain trapped in the pipeline logic rather than being properly flushed out. This results in a deadlock scenario where the firmware waits indefinitely for a flush completion signal that will never arrive, as the hardware cannot complete the drain operation without the proper mode configuration.
This operational impact manifests as a system hang or timeout during driver initialization or reset sequences involving the mailbox interface. Since the read path is unaffected due to AR_CFG lacking an equivalent mode bit and AR_FLUSH functioning correctly on its own, the issue is isolated strictly to write operations managed by AW_CFG. The lack of proper pipeline draining means that subsequent attempts to interact with the firmware via the mailbox may fail or cause the kernel to hang while waiting for a response that will never be processed due to the stalled hardware state.
The resolution involves modifying fbnic_mbx_reset_desc_ring() to set both the FLUSH and FLUSH_MODE bits in the AW_CFG register write operation. By enabling FLUSH_MODE alongside FLUSH, the device is instructed to allow staged writes to drain out of the pipeline automatically without requiring additional host intervention or risking a deadlock. Crucially, BME remains cleared during this phase to prevent any new data from landing on the host while old requests are being drained. The BME bit is subsequently restored in fbnic_mbx_init_desc_ring() once the ring has been rebuilt and it is safe for normal operation to resume, ensuring that TLP attributes and bus master capabilities are correctly re-established only after the pipeline is clear.
From a vulnerability classification perspective, this issue aligns with CWE-829, which covers Inclusion of Functionality from Untrusted Control Sources, as improper handling of hardware control signals leads to denial of service through resource exhaustion or deadlock. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding the race condition between driver state changes and hardware pipeline processing. The ATT&CK framework categorizes this type of failure under T1499, Endpoint Denial of Service, as it results in the unavailability of a critical system component due to improper configuration management rather than malicious exploitation.
Mitigation strategies for organizations running affected kernel versions involve applying the upstream Linux kernel patch that corrects the AW_CFG register write sequence. System administrators should ensure their systems are updated with the latest stable kernel release containing this fix. For environments where immediate patching is not feasible, monitoring logs for mailbox timeout errors or driver reset loops can serve as an indicator of potential exposure to this deadlock condition until the software update is deployed.