CVE-2024-38589

Disclosure Date: June 19, 2024 •

CVE-2024-38589

MITRE ATT&CK

Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

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

netrom: fix possible dead-lock in nr_rt_ioctl()

syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]

Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)

[1]
WARNING: possible circular locking dependency detected

6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted

syz-executor350/5129 is trying to acquire lock:
ffff8880186e2070 (&nr_node->node_lock){+…}–{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffff8880186e2070 (&nr_node->node_lock){+…}–{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
ffff8880186e2070 (&nr_node->node_lock){+…}–{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
ffff8880186e2070 (&nr_node->node_lock){+…}–{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697

but task is already holding lock:
ffffffff8f7053b8 (nr_node_list_lock){+…}–{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+…}–{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+…}–{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

–> #1 (nr_node_list_lock){+…}–{2:2}:

    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
    __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
    _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
    spin_lock_bh include/linux/spinlock.h:356 [inline]
    nr_remove_node net/netrom/nr_route.c:299 [inline]
    nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
    nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
    sock_do_ioctl+0x158/0x460 net/socket.c:1222
    sock_ioctl+0x629/0x8e0 net/socket.c:1341
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:904 [inline]
    __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

–> #0 (&nr_node->node_lock){+…}–{2:2}:

    check_prev_add kernel/locking/lockdep.c:3134 [inline]
    check_prevs_add kernel/locking/lockdep.c:3253 [inline]
    validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
    __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
    __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
    _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
    spin_lock_bh include/linux/spinlock.h:356 [inline]
    nr_node_lock include/net/netrom.h:152 [inline]
    nr_dec_obs net/netrom/nr_route.c:464 [inline]
    nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
    sock_do_ioctl+0x158/0x460 net/socket.c:1222
    sock_ioctl+0x629/0x8e0 net/socket.c:1341
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:904 [inline]
    __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(nr_node_list_lock);

                           lock(&nr_node->node_lock);
                           lock(nr_node_list_lock);

lock(&nr_node->node_lock);

*** DEADLOCK ***

1 lock held by syz-executor350/5129:
#0: ffffffff8f7053b8 (nr_node_list_lock){+…}–{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#0: ffffffff8f7053b8 (nr_node_list_lock){+…}–{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
#0: ffffffff8f70
—-truncated—-