<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T21:55:36.388619+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2025-22077</id>
    <title>CVE-2025-22077 — Revert "smb: client: fix TCP timers deadlock after rmmod"</title>
    <updated>2026-10-01T21:55:36.460790+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>Revert "smb: client: fix TCP timers deadlock after rmmod"</p>
<p>This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.</p>
<p>Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after
rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is
mentioned as CVE-2024-54680, but is actually did not fix anything;
The issue can be reproduced on top of it. [0]</p>
<p>Also, it reverted the change by commit ef7134c7fc48 ("smb: client:
Fix use-after-free of network namespace.") and introduced a real
issue by reviving the kernel TCP socket.</p>
<p>When a reconnect happens for a CIFS connection, the socket state
transitions to FIN_WAIT_1.  Then, inet_csk_clear_xmit_timers_sync()
in tcp_close() stops all timers for the socket.</p>
<p>If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1
forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.</p>
<p>Usually, FIN can be retransmitted by the peer, but if the peer aborts
the connection, the issue comes into reality.</p>
<p>I warned about this privately by pointing out the exact report [1],
but the bogus fix was finally merged.</p>
<p>So, we should not stop the timers to finally kill the connection on
our side in that case, meaning we must not use a kernel socket for
TCP whose sk-&gt;sk_net_refcnt is 0.</p>
<p>The kernel socket does not have a reference to its netns to make it
possible to tear down netns without cleaning up every resource in it.</p>
<p>For example, tunnel devices us…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-22077"/>
  </entry>
</feed>
