CVE-2025-38311

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: get rid of the crit lock<br /> <br /> Get rid of the crit lock.<br /> That frees us from the error prone logic of try_locks.<br /> <br /> Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were<br /> protected by it already - replace crit lock by netdev lock when it was not<br /> the case.<br /> <br /> Lockdep reports that we should cancel the work under crit_lock [splat1],<br /> and that was the scheme we have mostly followed since [1] by Slawomir.<br /> But when that is done we still got into deadlocks [splat2]. So instead<br /> we should look at the bigger problem, namely "weird locking/scheduling"<br /> of the iavf. The first step to fix that is to remove the crit lock.<br /> I will followup with a -next series that simplifies scheduling/tasks.<br /> <br /> Cancel the work without netdev lock (weird unlock+lock scheme),<br /> to fix the [splat2] (which would be totally ugly if we would kept<br /> the crit lock).<br /> <br /> Extend protected part of iavf_watchdog_task() to include scheduling<br /> more work.<br /> <br /> Note that the removed comment in iavf_reset_task() was misplaced,<br /> it belonged to inside of the removed if condition, so it&amp;#39;s gone now.<br /> <br /> [splat1] - w/o this patch - The deadlock during VF removal:<br /> WARNING: possible circular locking dependency detected<br /> sh/3825 is trying to acquire lock:<br /> ((work_completion)(&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470<br /> but task is already holding lock:<br /> (&amp;adapter-&gt;crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [splat2] - when cancelling work under crit lock, w/o this series,<br /> see [2] for the band aid attempt<br /> WARNING: possible circular locking dependency detected<br /> sh/3550 is trying to acquire lock:<br /> ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90<br /> but task is already holding lock:<br /> (&amp;dev-&gt;lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation")<br /> [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a