cve/published/2024/CVE-2024-38589.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-38589: netrom: fix possible dead-lock in nr_rt_ioctl()

 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: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697

 stack backtrace:
 CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
 Call Trace:
  <TASK>
   __dump_stack lib/dump_stack.c:88 [inline]
   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
   check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187
   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

 The Linux kernel CVE team has assigned CVE-2024-38589 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 4.19.316 with commit b9d663fbf74290cb68fbc66ae4367bd56837ad1d
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.4.278 with commit 1fbfb483c1a290dce3f41f52d45cc46dd88b7691
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.10.219 with commit b117e5b4f27c2c9076561b6be450a9619f0b79de
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.15.161 with commit 421c50fa81836775bf0fd6ce0e57a6eb27af24d5
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.1.93 with commit 3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.6.33 with commit f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.8.12 with commit 5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.9.3 with commit 5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
 	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.10 with commit e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2024-38589
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	net/netrom/nr_route.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d
 	https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691
 	https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de
 	https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5
 	https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
 	https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
 	https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
 	https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
 	https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-38589: netrom: fix possible dead-lock in nr_rt_ioctl()

	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: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697

	stack backtrace:
	CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0
	Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
	Call Trace:
	<TASK>
	__dump_stack lib/dump_stack.c:88 [inline]
	dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
	check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187
	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

	The Linux kernel CVE team has assigned CVE-2024-38589 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 4.19.316 with commit b9d663fbf74290cb68fbc66ae4367bd56837ad1d
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.4.278 with commit 1fbfb483c1a290dce3f41f52d45cc46dd88b7691
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.10.219 with commit b117e5b4f27c2c9076561b6be450a9619f0b79de
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.15.161 with commit 421c50fa81836775bf0fd6ce0e57a6eb27af24d5
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.1.93 with commit 3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.6.33 with commit f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.8.12 with commit 5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.9.3 with commit 5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.10 with commit e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-38589
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	net/netrom/nr_route.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d
	https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691
	https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de
	https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5
	https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
	https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
	https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
	https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
	https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6