CVE-2025-23143 — net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.

Affected: 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

In the Linux kernel, the following vulnerability has been resolved:

net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.

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]

Reproduction Steps:

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

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.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# 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

# lsmod | grep cifs cifs 1159168 0

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.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name().

Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired.

Then, LOCKDEP checks th…

Most recent entries from all

CVE-2025-23143 — net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.