CVE-2025-22077 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
Revert "smb: client: fix TCP timers deadlock after rmmod"
This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.
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]
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.
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.
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.
Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.
I warned about this privately by pointing out the exact report [1],
but the bogus fix was finally merged.
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->sk_net_refcnt is 0.
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.
For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.
However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.
If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.
Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.
That's why I converted the CIFS client socket to have a reference to netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right fix**.
Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in sock_lock_init_class_and_name(). [2]
For a while, let's revert the bogus fix.
Note that now we can use sk_net_refcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-22077 represents a critical regression within the Linux kernel's SMB client implementation that arose from an erroneous fix attempt. This issue stems from the reversion of commit e9f2517a3e18a54a3943c098d2226b245d488801, which was originally intended to address a null pointer dereference in LOCKDEP associated with CVE-2024-54680. However, the fix proved ineffective and introduced a more serious problem by reinstating a kernel TCP socket without proper network namespace reference management. This regression demonstrates a fundamental flaw in the kernel's handling of socket lifetimes and network namespace cleanup, particularly within the CIFS/SMB subsystem where TCP connections are managed.
The technical root cause involves the improper handling of TCP socket timers during connection teardown, specifically when a reconnect occurs for a CIFS connection. When a socket transitions to FIN_WAIT_1 state, the inet_csk_clear_xmit_timers_sync() function in tcp_close() stops all timers for the socket, which should normally allow graceful connection termination. However, if an incoming FIN packet is lost, the socket can remain in FIN_WAIT_1 indefinitely, leading to potential socket leaks up to the net.ipv4.tcp_max_orphans limit. This behavior creates a denial of service scenario where the kernel cannot properly clean up stale connections, particularly when the peer aborts the connection rather than gracefully closing it. The problem is exacerbated by the fact that the kernel socket does not maintain a reference to its network namespace, which creates a race condition between socket cleanup and namespace destruction, potentially resulting in use-after-free conditions.
The operational impact of this vulnerability extends beyond simple connection leaks, as it fundamentally undermines the stability and reliability of SMB client operations within the Linux kernel. Network administrators and system operators may experience unexpected connection failures, resource exhaustion, and potential system instability when dealing with CIFS connections that encounter network disruptions or peer aborts. This issue particularly affects environments heavily reliant on SMB/CIFS protocols for file sharing and network access, where connection persistence and proper cleanup are critical for maintaining service availability. The vulnerability also highlights the importance of careful consideration when applying patches, as the attempted fix for one issue inadvertently created a more severe problem that affects kernel stability and resource management. From a cybersecurity perspective, this vulnerability aligns with CWE-410: Insufficient Resource Management and CWE-470: Use of Externally-Controlled Input to Determine the Resource Name, as it involves improper handling of socket resources and network namespace cleanup. The ATT&CK framework would categorize this under T1499.004: Endpoint Denial of Service, as it can lead to sustained service disruption through resource exhaustion and connection management failures.
The mitigation strategy involves reverting the problematic commit and implementing proper network namespace reference management for TCP sockets within the CIFS client. The solution requires maintaining proper sk_net_refcnt references to prevent premature namespace cleanup while sockets are still active, ensuring that TCP timers can execute properly even after socket close operations. The fix also necessitates preventing module unloading during critical LOCKDEP operations by bumping module refcounts when switching LOCKDEP keys, thereby addressing the original null pointer dereference issue without introducing the new socket management problems. This approach aligns with best practices for kernel module development and resource management, ensuring that socket lifetimes are properly synchronized with network namespace lifetimes to prevent use-after-free conditions and maintain system stability. The recommended solution also emphasizes the importance of thorough testing and validation of kernel patches, particularly those involving core networking components and resource management mechanisms.