CVE-2025-68768

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