# CVE-2026-97569: bnxt_en: Prevent queue stop with deferred completions

> A flaw in the bnxt_en driver allows remote attackers to cause a network queue hang and denial of service by sending specific packet bursts to systems with small ring buffers.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 25 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** DEBIAN-CVE-2026-97569, GHSA-8qg4-f3vx-ghvf, UBUNTU-CVE-2026-97569

## What is CVE-2026-97569?

CVE-2026-97569 is a denial of service vulnerability in Linux, published on 25 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Prevent queue stop with deferred completions

When the driver receives a burst of packets, it can mark a BD with the
NO_CMPL bit to defer completions. The expectation is that the last
packet in the ring will have this bit unset and the completion generated
by that packet will cleanup that packet and the ones preceding it. This
helps to reduce the number of completions fired.

The suppressed completions are controlled by the driver and the number
of packets with suppressed completions scales with the size of the ring.
SW USO packets, on the other hand, have an upper bound on the maximum
number of BDs which can be consumed which does not scale with the ring
size.

So, for small rings it is possible that: a burst of packets is handed to
the driver, the driver defers completions for all of the packets because
the number of free descriptors stays above the threshold in the driver.
Then, a USO packet arrives, but the number of BDs available is not
enough and the USO code exits early.

In this case, you end up in a state where the ring is full of packets
with their completions suppressed, which can cause the queue to stop and
never be restarted.

Assuming default CONFIG_MAX_SKB_FRAGS, this is only possible for small
rings (<= 457 descriptors, below the driver default value) when
a burst of packets fills the ring, followed by a large USO packet that
can't fit. For larger rings, the delta between the completion
suppression threshold and the BDs required for SW USO is large enough
that completions will fire and this case is unreachable.

This issue was pointed out by Sashiko and while it seems fairly unlikely
given that the queue size must be small to trigger this, it is indeed
possible.

Fix this by tracking the last BD which deferred completions and
centralizing the logic for deciding when to ring the doorbell. The NO_CMPL
bit is now cleared in bnxt_txr_db_kick(), so every doorbell site is
covered, including the SW USO early exit. This guarantees the ring always
ends in a BD which generates a completion to clean it and wake the queue.

## Which versions are affected by CVE-2026-97569?


## How do I fix CVE-2026-97569?

Apply the vendor's patch.

## Is CVE-2026-97569 being exploited?

There is no known exploitation of CVE-2026-97569 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-97569 and fix it if it is affected.

What it is: CVE-2026-97569 is a denial of service vulnerability in Linux, published on 25 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-97569 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-97569/ (Markdown: https://insights.sbomify.com/CVE-2026-97569/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-97569
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-97569
- OSV: https://osv.dev/vulnerability/CVE-2026-97569

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-97569/
Summaries are generated and may contain mistakes; the official description above is the record.