CVE-2025-68245

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netpoll: fix incorrect refcount handling causing incorrect cleanup<br /> <br /> commit efa95b01da18 ("netpoll: fix use after free") incorrectly<br /> ignored the refcount and prematurely set dev-&gt;npinfo to NULL during<br /> netpoll cleanup, leading to improper behavior and memory leaks.<br /> <br /> Scenario causing lack of proper cleanup:<br /> <br /> 1) A netpoll is associated with a NIC (e.g., eth0) and netdev-&gt;npinfo is<br /> allocated, and refcnt = 1<br /> - Keep in mind that npinfo is shared among all netpoll instances. In<br /> this case, there is just one.<br /> <br /> 2) Another netpoll is also associated with the same NIC and<br /> npinfo-&gt;refcnt += 1.<br /> - Now dev-&gt;npinfo-&gt;refcnt = 2;<br /> - There is just one npinfo associated to the netdev.<br /> <br /> 3) When the first netpolls goes to clean up:<br /> - The first cleanup succeeds and clears np-&gt;dev-&gt;npinfo, ignoring<br /> refcnt.<br /> - It basically calls `RCU_INIT_POINTER(np-&gt;dev-&gt;npinfo, NULL);`<br /> - Set dev-&gt;npinfo = NULL, without proper cleanup<br /> - No -&gt;ndo_netpoll_cleanup() is either called<br /> <br /> 4) Now the second target tries to clean up<br /> - The second cleanup fails because np-&gt;dev-&gt;npinfo is already NULL.<br /> * In this case, ops-&gt;ndo_netpoll_cleanup() was never called, and<br /> the skb pool is not cleaned as well (for the second netpoll<br /> instance)<br /> - This leaks npinfo and skbpool skbs, which is clearly reported by<br /> kmemleak.<br /> <br /> Revert commit efa95b01da18 ("netpoll: fix use after free") and adds<br /> clarifying comments emphasizing that npinfo cleanup should only happen<br /> once the refcount reaches zero, ensuring stable and correct netpoll<br /> behavior.