CVE-2025-22077

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "smb: client: fix TCP timers deadlock after rmmod"<br /> <br /> This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.<br /> <br /> Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after<br /> rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is<br /> mentioned as CVE-2024-54680, but is actually did not fix anything;<br /> The issue can be reproduced on top of it. [0]<br /> <br /> Also, it reverted the change by commit ef7134c7fc48 ("smb: client:<br /> Fix use-after-free of network namespace.") and introduced a real<br /> issue by reviving the kernel TCP socket.<br /> <br /> When a reconnect happens for a CIFS connection, the socket state<br /> transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()<br /> in tcp_close() stops all timers for the socket.<br /> <br /> If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1<br /> forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.<br /> <br /> Usually, FIN can be retransmitted by the peer, but if the peer aborts<br /> the connection, the issue comes into reality.<br /> <br /> I warned about this privately by pointing out the exact report [1],<br /> but the bogus fix was finally merged.<br /> <br /> So, we should not stop the timers to finally kill the connection on<br /> our side in that case, meaning we must not use a kernel socket for<br /> TCP whose sk-&gt;sk_net_refcnt is 0.<br /> <br /> The kernel socket does not have a reference to its netns to make it<br /> possible to tear down netns without cleaning up every resource in it.<br /> <br /> For example, tunnel devices use a UDP socket internally, but we can<br /> destroy netns without removing such devices and let it complete<br /> during exit. Otherwise, netns would be leaked when the last application<br /> died.<br /> <br /> However, this is problematic for TCP sockets because TCP has timers to<br /> close the connection gracefully even after the socket is close()d. The<br /> lifetime of the socket and its netns is different from the lifetime of<br /> the underlying connection.<br /> <br /> If the socket user does not maintain the netns lifetime, the timer could<br /> be fired after the socket is close()d and its netns is freed up, resulting<br /> in use-after-free.<br /> <br /> Actually, we have seen so many similar issues and converted such sockets<br /> to have a reference to netns.<br /> <br /> That&amp;#39;s why I converted the CIFS client socket to have a reference to<br /> netns (sk-&gt;sk_net_refcnt == 1), which is somehow mentioned as out-of-scope<br /> of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right<br /> fix**.<br /> <br /> Regarding the LOCKDEP issue, we can prevent the module unload by<br /> bumping the module refcount when switching the LOCKDDEP key in<br /> sock_lock_init_class_and_name(). [2]<br /> <br /> For a while, let&amp;#39;s revert the bogus fix.<br /> <br /> Note that now we can use sk_net_refcnt_upgrade() for the socket<br /> conversion, but I&amp;#39;ll do so later separately to make backport easy.