cve/published/2022/CVE-2022-49441.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-2022-49441: tty: fix deadlock caused by calling printk() under tty_port->lock

 Description
 ===========

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

 tty: fix deadlock caused by calling printk() under tty_port->lock

 pty_write() invokes kmalloc() which may invoke a normal printk() to print
 failure message.  This can cause a deadlock in the scenario reported by
 syz-bot below:

        CPU0              CPU1                    CPU2
        ----              ----                    ----
                          lock(console_owner);
                                                  lock(&port_lock_key);
   lock(&port->lock);
                          lock(&port_lock_key);
                                                  lock(&port->lock);
   lock(console_owner);

 As commit dbdda842fe96 ("printk: Add console owner and waiter logic to
 load balance console writes") said, such deadlock can be prevented by
 using printk_deferred() in kmalloc() (which is invoked in the section
 guarded by the port->lock).  But there are too many printk() on the
 kmalloc() path, and kmalloc() can be called from anywhere, so changing
 printk() to printk_deferred() is too complicated and inelegant.

 Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
 that printk() will not be called, and this deadlock problem can be
 avoided.

 Syzbot reported the following lockdep error:

 ======================================================
 WARNING: possible circular locking dependency detected
 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
 ------------------------------------------------------
 syz-executor.4/29420 is trying to acquire lock:
 ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
 ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023

 but task is already holding lock:
 ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #2 (&port->lock){-.-.}-{2:2}:
        __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
        _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
        tty_port_tty_get drivers/tty/tty_port.c:288 [inline]          		<-- lock(&port->lock);
        tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
        serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
        serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
        serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] 	<-- lock(&port_lock_key);
        serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
        serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
        __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
        [...]

 -> #1 (&port_lock_key){-.-.}-{2:2}:
        __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
        _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
        serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
 										<-- lock(&port_lock_key);
        call_console_drivers kernel/printk/printk.c:1819 [inline]
        console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
        vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024			<-- lock(console_owner);
        vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
        printk+0xba/0xed kernel/printk/printk.c:2084
        register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
        univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
        console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
        start_kernel+0x5e9/0x879 init/main.c:713
        secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241

 -> #0 (console_owner){....}-{0:0}:
        [...]
        lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
        console_trylock_spinning kernel/printk/printk.c:1773 [inline]		<-- lock(console_owner);
        vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
        vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
        printk+0xba/0xed kernel/printk/printk.c:2084
        fail_dump lib/fault-inject.c:45 [inline]
        should_fail+0x67b/0x7c0 lib/fault-inject.c:144
        __should_failslab+0x152/0x1c0 mm/failslab.c:33
        should_failslab+0x5/0x10 mm/slab_common.c:1224
        slab_pre_alloc_hook mm/slab.h:468 [inline]
        slab_alloc_node mm/slub.c:2723 [inline]
        slab_alloc mm/slub.c:2807 [inline]
        __kmalloc+0x72/0x300 mm/slub.c:3871
        kmalloc include/linux/slab.h:582 [inline]
        tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
        __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
        tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
        tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
        pty_write+0x126/0x1f0 drivers/tty/pty.c:122				<-- lock(&port->lock);
        n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
        do_tty_write drivers/tty/tty_io.c:961 [inline]
        tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
        __vfs_write+0x76/0x100 fs/read_write.c:494
        [...]

 other info that might help us debug this:

 Chain exists of:
   console_owner --> &port_lock_key --> &port->lock

 The Linux kernel CVE team has assigned CVE-2022-49441 to this issue.


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

 	Issue introduced in 4.9.117 with commit d83904cb2eb2c4d937eaf15032214b0578f25099 and fixed in 4.9.318 with commit 4af21b12a60ed2d3642284f4f85b42d7dc6ac246
 	Issue introduced in 4.14.60 with commit deb1feaad03a78b545c949e54582ae57b3c56982 and fixed in 4.14.283 with commit 4c253caf9264d2aa47ee806a87986dd8eb91a5d9
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 4.19.247 with commit 04ee31678c128a6cc7bb057ea189a8624ba5a314
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.4.198 with commit 3219ac364ac3d8d30771612a6010f1e0b7fa0a28
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.10.121 with commit 9834b13e8b962caa28fbcf1f422dd82413da4ede
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.15.46 with commit 18ca0d55e8639b911df8aae1b47598b13f9acded
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.17.14 with commit b3c974501d0c32258ae0e04e5cc3fb92383b40f6
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.18.3 with commit 0bcf44903ef4df742dcada86ccaedd25374ffb50
 	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.19 with commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3
 	Issue introduced in 3.18.118 with commit 6d9cd12792270773fab9e5a129daff328d61ef9e
 	Issue introduced in 4.4.146 with commit 6dbfa9b5ae65063cd61dc7fa11332e00bb794d8b
 	Issue introduced in 4.17.12 with commit 60c4e8db32815474bfaeabe888ebb14e698caea1

 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-2022-49441
 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:
 	drivers/tty/tty_buffer.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/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
 	https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
 	https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314
 	https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
 	https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
 	https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
 	https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
 	https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
 	https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3
	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-2022-49441: tty: fix deadlock caused by calling printk() under tty_port->lock

	Description
	===========

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

	tty: fix deadlock caused by calling printk() under tty_port->lock

	pty_write() invokes kmalloc() which may invoke a normal printk() to print
	failure message. This can cause a deadlock in the scenario reported by
	syz-bot below:

	CPU0 CPU1 CPU2
	---- ---- ----
	lock(console_owner);
	lock(&port_lock_key);
	lock(&port->lock);
	lock(&port_lock_key);
	lock(&port->lock);
	lock(console_owner);

	As commit dbdda842fe96 ("printk: Add console owner and waiter logic to
	load balance console writes") said, such deadlock can be prevented by
	using printk_deferred() in kmalloc() (which is invoked in the section
	guarded by the port->lock). But there are too many printk() on the
	kmalloc() path, and kmalloc() can be called from anywhere, so changing
	printk() to printk_deferred() is too complicated and inelegant.

	Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
	that printk() will not be called, and this deadlock problem can be
	avoided.

	Syzbot reported the following lockdep error:

	======================================================
	WARNING: possible circular locking dependency detected
	5.4.143-00237-g08ccc19a-dirty #10 Not tainted
	------------------------------------------------------
	syz-executor.4/29420 is trying to acquire lock:
	ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
	ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023

	but task is already holding lock:
	ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120

	which lock already depends on the new lock.

	the existing dependency chain (in reverse order) is:

	-> #2 (&port->lock){-.-.}-{2:2}:
	__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
	_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
	tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
	tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
	serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
	serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
	serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
	serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
	serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
	__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
	[...]

	-> #1 (&port_lock_key){-.-.}-{2:2}:
	__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
	_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
	serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
	<-- lock(&port_lock_key);
	call_console_drivers kernel/printk/printk.c:1819 [inline]
	console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
	vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
	vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
	printk+0xba/0xed kernel/printk/printk.c:2084
	register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
	univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
	console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
	start_kernel+0x5e9/0x879 init/main.c:713
	secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241

	-> #0 (console_owner){....}-{0:0}:
	[...]
	lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
	console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
	vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
	vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
	printk+0xba/0xed kernel/printk/printk.c:2084
	fail_dump lib/fault-inject.c:45 [inline]
	should_fail+0x67b/0x7c0 lib/fault-inject.c:144
	__should_failslab+0x152/0x1c0 mm/failslab.c:33
	should_failslab+0x5/0x10 mm/slab_common.c:1224
	slab_pre_alloc_hook mm/slab.h:468 [inline]
	slab_alloc_node mm/slub.c:2723 [inline]
	slab_alloc mm/slub.c:2807 [inline]
	__kmalloc+0x72/0x300 mm/slub.c:3871
	kmalloc include/linux/slab.h:582 [inline]
	tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
	__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
	tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
	tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
	pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
	n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
	do_tty_write drivers/tty/tty_io.c:961 [inline]
	tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
	__vfs_write+0x76/0x100 fs/read_write.c:494
	[...]

	other info that might help us debug this:

	Chain exists of:
	console_owner --> &port_lock_key --> &port->lock

	The Linux kernel CVE team has assigned CVE-2022-49441 to this issue.


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

	Issue introduced in 4.9.117 with commit d83904cb2eb2c4d937eaf15032214b0578f25099 and fixed in 4.9.318 with commit 4af21b12a60ed2d3642284f4f85b42d7dc6ac246
	Issue introduced in 4.14.60 with commit deb1feaad03a78b545c949e54582ae57b3c56982 and fixed in 4.14.283 with commit 4c253caf9264d2aa47ee806a87986dd8eb91a5d9
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 4.19.247 with commit 04ee31678c128a6cc7bb057ea189a8624ba5a314
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.4.198 with commit 3219ac364ac3d8d30771612a6010f1e0b7fa0a28
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.10.121 with commit 9834b13e8b962caa28fbcf1f422dd82413da4ede
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.15.46 with commit 18ca0d55e8639b911df8aae1b47598b13f9acded
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.17.14 with commit b3c974501d0c32258ae0e04e5cc3fb92383b40f6
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.18.3 with commit 0bcf44903ef4df742dcada86ccaedd25374ffb50
	Issue introduced in 4.18 with commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff and fixed in 5.19 with commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3
	Issue introduced in 3.18.118 with commit 6d9cd12792270773fab9e5a129daff328d61ef9e
	Issue introduced in 4.4.146 with commit 6dbfa9b5ae65063cd61dc7fa11332e00bb794d8b
	Issue introduced in 4.17.12 with commit 60c4e8db32815474bfaeabe888ebb14e698caea1

	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-2022-49441
	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:
	drivers/tty/tty_buffer.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/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
	https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
	https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314
	https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
	https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
	https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
	https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
	https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
	https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3