NVD

CVE-2025-22077 Detail

Awaiting Analysis

This CVE record has been marked for NVD enrichment efforts.

Description

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.

Metrics

NVD enrichment efforts reference publicly available information to associate vector strings. CVSS information contributed by other sources is also displayed.

CVSS 4.0 Severity and Vector Strings:

NIST: NVD

N/A

NVD assessment not yet provided.

CVSS 3.x Severity and Vector Strings:

NIST: NVD

Base Score: N/A

NVD assessment not yet provided.

CVSS 2.0 Severity and Vector Strings:

National Institute of Standards and Technology

NIST: NVD

Base Score: N/A

NVD assessment not yet provided.

References to Advisories, Solutions, and Tools

By selecting these links, you will be leaving NIST webspace. We have provided these links to other web sites because they may have information that would be of interest to you. No inferences should be drawn on account of other sites being referenced, or not, from this page. There may be other web sites that are more appropriate for your purpose. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites. Please address comments about this page to [email protected].

URL	Source(s)	Tag(s)
https://git.kernel.org/stable/c/4b6f6bf1bde8d6045c389fda8d21c304dfe49384	kernel.org
https://git.kernel.org/stable/c/8dbf060480236877703bff0106fc984576184d11	kernel.org
https://git.kernel.org/stable/c/95d2b9f693ff2a1180a23d7d59acc0c4e72f4c41	kernel.org
https://git.kernel.org/stable/c/f761eeefd531e6550cd3a5c047835b4892acb00d	kernel.org

Weakness Enumeration

CWE-ID	CWE Name	Source

Change History

3 change records found show changes

CVE Modified by kernel.org 4/22/2025 2:15:44 AM

Action	Type	Old Value	New Value
Changed	Description	Record truncated, showing 2048 of 3998 characters. View Entire Change Record In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix netns refcount imbalance causing leaks and use-after-free Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") attempted to fix a netns use-after-free issue by manually adjusting reference counts via sk->sk_net_refcnt and sock_inuse_add(). However, a later commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") pointed out that the approach of manually setting sk->sk_net_refcnt in the first commit was technically incorrect, as sk->sk_net_refcnt should only be set for user sockets. It led to issues like TCP timers not being cleared properly on close. The second commit moved to a model of just holding an extra netns reference for server->ssocket using get_net(), and dropping it when the server is torn down. But there remain some gaps in the get_net()/put_net() balancing added by these commits. The incomplete reference handling in these fixes results in two issues: 1. Netns refcount leaks[1] The problem process is as follows: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net. / ip_connect generic_ip_connect / Try port 445 / get_net() ->connect() / Failed / put_net() generic_ip_connect / Try port 139 / get_net() / Missing matching put_net() for this get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release();	Record truncated, showing 2048 of 2760 characters. View Entire Change Record 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
Added	Reference		https://git.kernel.org/stable/c/95d2b9f693ff2a1180a23d7d59acc0c4e72f4c41
Removed	Reference	https://git.kernel.org/stable/c/476617a4ca0123f0df677d547a82a110c27c8c74
Removed	Reference	https://git.kernel.org/stable/c/4e7f1644f2ac6d01dc584f6301c3b1d5aac4eaef
Removed	Reference	https://git.kernel.org/stable/c/7d8dfc27d90d41627c0d6ada97ed0ab57b3dae25
Removed	Reference	https://git.kernel.org/stable/c/961755d0055e0e96d1849cc0425da966c8a64e53
Removed	Reference	https://git.kernel.org/stable/c/c6b6b8dcef4adf8ee4e439bb97e74106096c71b8

New CVE Received from kernel.org 4/16/2025 11:16:01 AM

Action	Type	New Value
Added	Description	Record truncated, showing 2048 of 3998 characters. View Entire Change Record In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix netns refcount imbalance causing leaks and use-after-free Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") attempted to fix a netns use-after-free issue by manually adjusting reference counts via sk->sk_net_refcnt and sock_inuse_add(). However, a later commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") pointed out that the approach of manually setting sk->sk_net_refcnt in the first commit was technically incorrect, as sk->sk_net_refcnt should only be set for user sockets. It led to issues like TCP timers not being cleared properly on close. The second commit moved to a model of just holding an extra netns reference for server->ssocket using get_net(), and dropping it when the server is torn down. But there remain some gaps in the get_net()/put_net() balancing added by these commits. The incomplete reference handling in these fixes results in two issues: 1. Netns refcount leaks[1] The problem process is as follows: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net. / ip_connect generic_ip_connect / Try port 445 / get_net() ->connect() / Failed / put_net() generic_ip_connect / Try port 139 / get_net() / Missing matching put_net() for this get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release();
Added	Reference	https://git.kernel.org/stable/c/476617a4ca0123f0df677d547a82a110c27c8c74
Added	Reference	https://git.kernel.org/stable/c/4e7f1644f2ac6d01dc584f6301c3b1d5aac4eaef
Added	Reference	https://git.kernel.org/stable/c/7d8dfc27d90d41627c0d6ada97ed0ab57b3dae25
Added	Reference	https://git.kernel.org/stable/c/961755d0055e0e96d1849cc0425da966c8a64e53
Added	Reference	https://git.kernel.org/stable/c/c6b6b8dcef4adf8ee4e439bb97e74106096c71b8

Quick Info

CVE Dictionary Entry:
CVE-2025-22077
NVD Published Date:
04/16/2025
NVD Last Modified:
04/25/2025
Source:
kernel.org

You are viewing this page in an unauthorized frame window.

Information Technology Laboratory

National Vulnerability Database

National Vulnerability Database

CVE-2025-22077 Detail

Description

Metrics

References to Advisories, Solutions, and Tools

Weakness Enumeration

Change History

CVE Modified by kernel.org 4/25/2025 7:15:45 AM

CVE Modified by kernel.org 4/22/2025 2:15:44 AM

New CVE Received from kernel.org 4/16/2025 11:16:01 AM

Quick Info