GHSA-6G94-RWCJ-HWX9
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31In 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.
{
"affected": [],
"aliases": [
"CVE-2025-68768"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:15:56Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: flush pending skbs in fqdir_pre_exit()\n\nWe have been seeing occasional deadlocks on pernet_ops_rwsem since\nSeptember in NIPA. The stuck task was usually modprobe (often loading\na driver like ipvlan), trying to take the lock as a Writer.\nlockdep does not track readers for rwsems so the read wasn\u0027t obvious\nfrom the reports.\n\nOn closer inspection the Reader holding the lock was conntrack looping\nforever in nf_conntrack_cleanup_net_list(). Based on past experience\nwith occasional NIPA crashes I looked thru the tests which run before\nthe crash and noticed that the crash follows ip_defrag.sh. An immediate\nred flag. Scouring thru (de)fragmentation queues reveals skbs sitting\naround, holding conntrack references.\n\nThe problem is that since conntrack depends on nf_defrag_ipv6,\nnf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its\nnetns exit hooks run _after_ conntrack\u0027s netns exit hook.\n\nFlush all fragment queue SKBs during fqdir_pre_exit() to release\nconntrack references before conntrack cleanup runs. Also flush\nthe queues in timer expiry handlers when they discover fqdir-\u003edead\nis set, in case packet sneaks in while we\u0027re running the pre_exit\nflush.\n\nThe commit under Fixes is not exactly the culprit, but I think\npreviously the timer firing would eventually unblock the spinning\nconntrack.",
"id": "GHSA-6g94-rwcj-hwx9",
"modified": "2026-01-13T18:31:03Z",
"published": "2026-01-13T18:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68768"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/006a5035b495dec008805df249f92c22c89c3d2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c70df25214ac9b32b53e18e6ae3b8f073ffa6903"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.