LiveActive security incident?Get immediate response
CVE Record

CVE-2025-68768: inet: frags: flush pending skbs in fqdir_pre_exit()

In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can leave network cleanup stuck because fragmented packet buffers retain connection-tracking references. The observed result is a deadlock during module or namespace cleanup, which can affect system stability and operations rather than expose data directly.

Executive priority

Treat as a stability and availability risk for Linux infrastructure, especially containerized or network-heavy systems. Prioritize through kernel patch management rather than emergency incident response unless local symptoms appear.

Technical view

The flaw is in inet fragment handling. Pending SKBs in fragment queues can hold conntrack references while netns exit ordering lets conntrack cleanup loop indefinitely. The fix flushes fragment queue SKBs in fqdir_pre_exit() and timer expiry when fqdir->dead is set.

Likely exposure

Systems running affected Linux kernel builds with IPv4/IPv6 fragmentation and conntrack/defrag paths are the relevant exposure. The bundle lists Linux kernel versions beginning at 5.3 and references stable commits, but distro package mapping must be confirmed by vendor advisories.

Exploitation context

No active exploitation is supported by the supplied sources. The CVE is not marked KEV, and the description is based on observed deadlocks in NIPA testing after ip_defrag.sh rather than reported in-the-wild abuse.

Researcher notes

The evidence supports a kernel deadlock caused by fragment queues retaining conntrack references during netns teardown. Severity, CVSS, CWE, and exploitability are not provided, so avoid asserting remote triggerability or privilege impact without further upstream or vendor analysis.

Mitigation direction

  • Update to a vendor kernel containing the referenced stable fixes.
  • Prioritize hosts using conntrack, namespaces, containers, or network modules.
  • Check distribution advisories for backported package names and fixed versions.
  • Plan reboot or live-patching according to normal kernel maintenance policy.

Validation and detection

  • Inventory running kernel versions across Linux hosts.
  • Confirm vendor changelogs include this CVE or the referenced commits.
  • Verify conntrack and defrag modules are present where relevant.
  • After update, monitor for stuck tasks involving pernet_ops_rwsem or conntrack cleanup.
Prepared
Confidence
medium
Sources
6

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-2025-68768 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
5Source 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
LinuxLinuxd5dd88794a13c2f24cce31abad7a0a6c5e0ed2db, d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db, d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db, d5dd88794a13c2f24cce31abad7a0a6c5e0ed2dbunaffected
LinuxLinux5.3, 0, 6.6.143, 6.12.93, 6.18.3, 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.