CVE-2025-68768

2026-01-13 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Lifecycle Timeline

2
Analysis Generated
Mar 12, 2026 - 21:54 vuln.today
CVE Published
Jan 13, 2026 - 16:15 nvd
N/A

Description

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.

Analysis

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.

Technical Context

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_conntrac

Affected Products

Component: timer expiry.

Remediation

Monitor vendor advisories for a patch.

Priority Score

0
Low Medium High Critical
KEV: 0
EPSS: +0.0
CVSS: +0
POC: 0

Share

CVE-2025-68768 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy