<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T18:21:49.293727+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2025-23143</id>
    <title>CVE-2025-23143 — net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.</title>
    <updated>2026-10-08T18:21:49.295749+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux, Siemens SIMATIC CN 4100, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.</p>
<p>When I ran the repro [0] and waited a few seconds, I observed two
LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]</p>
<p>Reproduction Steps:</p>
<p>1) Mount CIFS
  2) Add an iptables rule to drop incoming FIN packets for CIFS
  3) Unmount CIFS
  4) Unload the CIFS module
  5) Remove the iptables rule</p>
<p>At step 3), the CIFS module calls sock_release() for the underlying
TCP socket, and it returns quickly.  However, the socket remains in
FIN_WAIT_1 because incoming FIN packets are dropped.</p>
<p>At this point, the module's refcnt is 0 while the socket is still
alive, so the following rmmod command succeeds.</p>
<p># ss -tan
  State      Recv-Q Send-Q Local Address:Port  Peer Address:Port
  FIN-WAIT-1 0      477        10.0.2.15:51062   10.0.0.137:445</p>
<p># lsmod | grep cifs
  cifs                 1159168  0</p>
<p>This highlights a discrepancy between the lifetime of the CIFS module
and the underlying TCP socket.  Even after CIFS calls sock_release()
and it returns, the TCP socket does not die immediately in order to
close the connection gracefully.</p>
<p>While this is generally fine, it causes an issue with LOCKDEP because
CIFS assigns a different lock class to the TCP socket's sk-&gt;sk_lock
using sock_lock_init_class_and_name().</p>
<p>Once an incoming packet is processed for the socket or a timer fires,
sk-&gt;sk_lock is acquired.</p>
<p>Then, LOCKDEP checks th…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-23143"/>
  </entry>
</feed>
