LiveActive security incident?Get immediate response
CVE Record

CVE-2026-23016: inet: frags: drop fraglist conntrack references

In the Linux kernel, the following vulnerability has been resolved: inet: frags: drop fraglist conntrack references Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging leaked skbs/conntrack references more obvious. syzbot reports this as triggering, and I can also reproduce this via ip_defrag.sh selftest: conntrack cleanup blocked for 60s WARNING: net/netfilter/nf_conntrack_core.c:2512 [..] conntrack clenups gets stuck because there are skbs with still hold nf_conn references via their frag_list. net.core.skb_defer_max=0 makes the hang disappear. Eric Dumazet points out that skb_release_head_state() doesn't follow the fraglist. ip_defrag.sh can only reproduce this problem since commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this problem could happen with TCP as well if pmtu discovery is off. The relevant problem path for udp is: 1. netns emits fragmented packets 2. nf_defrag_v6_hook reassembles them (in output hook) 3. reassembled skb is tracked (skb owns nf_conn reference) 4. ip6_output refragments 5. refragmented packets also own nf_conn reference (ip6_fragment calls ip6_copy_metadata()) 6. on input path, nf_defrag_v6_hook skips defragmentation: the fragments already have skb->nf_conn attached 7. skbs are reassembled via ipv6_frag_rcv() 8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up in pcpu freelist, but still has nf_conn reference. Possible solutions: 1 let defrag engine drop nf_conn entry, OR 2 export kick_defer_list_purge() and call it from the conntrack netns exit callback, OR 3 add skb_has_frag_list() check to skb_attempt_defer_free() 2 & 3 also solve ip_defrag.sh hang but share same drawback: Such reassembled skbs, queued to socket, can prevent conntrack module removal until userspace has consumed the packet. While both tcp and udp stack do call nf_reset_ct() before placing skb on socket queue, that function doesn't iterate frag_list skbs. Therefore drop nf_conn entries when they are placed in defrag queue. Keep the nf_conn entry of the first (offset 0) skb so that reassembled skb retains nf_conn entry for sake of TX path. Note that fixes tag is incorrect; it points to the commit introducing the 'ip_defrag.sh reproducible problem': no need to backport this patch to every stable kernel.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel networking bug where fragmented packet handling can leave connection-tracking references behind. The documented impact is a blocked conntrack cleanup path and potential hang during network namespace or conntrack cleanup, not confirmed remote code execution or data theft.

Executive priority

Patch through the normal kernel maintenance cycle, with higher priority for infrastructure relying on conntrack or network namespaces. There is no cited evidence of active exploitation, but cleanup hangs in core networking can create operational risk.

Technical view

The issue involves inet fragment reassembly, frag_list skb handling, and nf_conntrack references. Reassembled and refragmented packets can retain nf_conn references on frag_list skbs because cleanup does not walk the fraglist. The kernel fix drops conntrack references when skbs enter the defrag queue while preserving the first skb reference for TX behavior.

Likely exposure

Exposure is limited to affected Linux kernel versions identified in the CVE data, notably the 6.18 to 6.19 range, especially systems using netfilter conntrack with fragmented IPv6 or related UDP/TCP traffic paths. Distribution backports may change exact exposure.

Exploitation context

No KEV listing or cited source reports active exploitation. The evidence describes syzbot and kernel selftest reproduction of cleanup blockage. Treat this as a reliability and denial-of-service concern until vendor advisories provide clearer impact scoring.

Researcher notes

The CVE text states the fixes tag is not a broad backport signal. Validate against vendor-patched kernels, not only upstream version numbers. The described reproducible path is UDP over IPv6 fragmentation, but the source notes TCP may also be possible under specific conditions.

Mitigation direction

  • Apply a vendor kernel update containing the referenced stable fixes.
  • Check distribution advisories for exact affected and fixed package versions.
  • Prioritize hosts using conntrack, netfilter, network namespaces, or fragmented traffic paths.
  • Avoid treating sysctl observations as a permanent fix unless vendor guidance confirms it.

Validation and detection

  • Inventory Linux kernel versions across servers, appliances, and container hosts.
  • Check whether deployed kernels include either referenced stable commit.
  • Review conntrack, netfilter, and IPv6 fragmentation usage on affected systems.
  • Monitor for conntrack cleanup stalls or related kernel warnings.
Prepared
Confidence
medium
Sources
4

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2026-23016 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux6471658dc66c670580a7616e75f51b52917e7883, 6471658dc66c670580a7616e75f51b52917e7883unaffected
LinuxLinux6.18, 0, 6.18.6, 6.19affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.