Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]smb: client: fix potential deadlock when reconnecting channels[EOL][EOL]Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order[EOL]and prevent the following deadlock from happening[EOL][EOL]======================================================[EOL]WARNING: possible circular locking dependency detected[EOL]6.16.0-rc3-build2+ #1301 Tainted: G S      W[EOL]------------------------------------------------------[EOL]cifsd/6055 is trying to acquire lock:[EOL]ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200[EOL][EOL]but task is already holding lock:[EOL]ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200[EOL][EOL]which lock already depends on the new lock.[EOL][EOL]the existing dependency chain (in reverse order) is:[EOL][EOL]-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}:[EOL]       validate_chain+0x1cf/0x270[EOL]       __lock_acquire+0x60e/0x780[EOL]       lock_acquire.part.0+0xb4/0x1f0[EOL]       _raw_spin_lock+0x2f/0x40[EOL]       cifs_setup_session+0x81/0x4b0[EOL]       cifs_get_smb_ses+0x771/0x900[EOL]       cifs_mount_get_session+0x7e/0x170[EOL]       cifs_mount+0x92/0x2d0[EOL]       cifs_smb3_do_mount+0x161/0x460[EOL]       smb3_get_tree+0x55/0x90[EOL]       vfs_get_tree+0x46/0x180[EOL]       do_new_mount+0x1b0/0x2e0[EOL]       path_mount+0x6ee/0x740[EOL]       do_mount+0x98/0xe0[EOL]       __do_sys_mount+0x148/0x180[EOL]       do_syscall_64+0xa4/0x260[EOL]       entry_SYSCALL_64_after_hwframe+0x76/0x7e[EOL][EOL]-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}:[EOL]       validate_chain+0x1cf/0x270[EOL]       __lock_acquire+0x60e/0x780[EOL]       lock_acquire.part.0+0xb4/0x1f0[EOL]       _raw_spin_lock+0x2f/0x40[EOL]       cifs_match_super+0x101/0x320[EOL]       sget+0xab/0x270[EOL]       cifs_smb3_do_mount+0x1e0/0x460[EOL]       smb3_get_tree+0x55/0x90[EOL]       vfs_get_tree+0x46/0x180[EOL]       do_new_mount+0x1b0/0x2e0[EOL]       path_mount+0x6ee/0x740[EOL]       do_mount+0x98/0xe0[EOL]       __do_sys_mount+0x148/0x180[EOL]       do_syscall_64+0xa4/0x260[EOL]       entry_SYSCALL_64_after_hwframe+0x76/0x7e[EOL][EOL]-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}:[EOL]       check_noncircular+0x95/0xc0[EOL]       check_prev_add+0x115/0x2f0[EOL]       validate_chain+0x1cf/0x270[EOL]       __lock_acquire+0x60e/0x780[EOL]       lock_acquire.part.0+0xb4/0x1f0[EOL]       _raw_spin_lock+0x2f/0x40[EOL]       cifs_signal_cifsd_for_reconnect+0x134/0x200[EOL]       __cifs_reconnect+0x8f/0x500[EOL]       cifs_handle_standard+0x112/0x280[EOL]       cifs_demultiplex_thread+0x64d/0xbc0[EOL]       kthread+0x2f7/0x310[EOL]       ret_from_fork+0x2a/0x230[EOL]       ret_from_fork_asm+0x1a/0x30[EOL][EOL]other info that might help us debug this:[EOL][EOL]Chain exists of:[EOL]  &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock[EOL][EOL] Possible unsafe locking scenario:[EOL][EOL]       CPU0                    CPU1[EOL]       ----                    ----[EOL]  lock(&ret_buf->chan_lock);[EOL]                               lock(&ret_buf->ses_lock);[EOL]                               lock(&ret_buf->chan_lock);[EOL]  lock(&tcp_ses->srv_lock);[EOL][EOL] *** DEADLOCK ***[EOL][EOL]3 locks held by cifsd/6055:[EOL] #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200[EOL] #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200[EOL] #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

CREATE(Triage):(User=admin) [CVE-2025-38244 (https://nvd.nist.gov/vuln/detail/CVE-2025-38244)