CVE-2022-48984
Severity CVSS v4.0:
Pending analysis
Type:
CWE-476
NULL Pointer Dereference
Publication date:
21/10/2024
Last modified:
25/10/2024
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
can: slcan: fix freed work crash<br />
<br />
The LTP test pty03 is causing a crash in slcan:<br />
BUG: kernel NULL pointer dereference, address: 0000000000000008<br />
#PF: supervisor read access in kernel mode<br />
#PF: error_code(0x0000) - not-present page<br />
PGD 0 P4D 0<br />
Oops: 0000 [#1] PREEMPT SMP NOPTI<br />
CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab<br />
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014<br />
Workqueue: 0x0 (events)<br />
RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)<br />
Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e<br />
RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046<br />
RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968<br />
RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0<br />
RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734<br />
R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000<br />
R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0<br />
FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0<br />
Call Trace:<br />
<br />
worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436)<br />
kthread (/home/rich/kernel/linux/kernel/kthread.c:376)<br />
ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)<br />
<br />
Apparently, the slcan&#39;s tx_work is freed while being scheduled. While<br />
slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),<br />
slcan_close() (tty side) does not. So when the netdev is never set UP,<br />
but the tty is stuffed with bytes and forced to wakeup write, the work<br />
is scheduled, but never flushed.<br />
<br />
So add an additional flush_work() to slcan_close() to be sure the work<br />
is flushed under all circumstances.<br />
<br />
The Fixes commit below moved flush_work() from slcan_close() to<br />
slcan_netdev_close(). What was the rationale behind it? Maybe we can<br />
drop the one in slcan_netdev_close()?<br />
<br />
I see the same pattern in can327. So it perhaps needs the very same fix.
Impact
Base Score 3.x
5.50
Severity 3.x
MEDIUM
Vulnerable products and versions
CPE | From | Up to |
---|---|---|
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.0 (including) | 6.0.13 (excluding) |
cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc6:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc7:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.1:rc8:*:*:*:*:*:* |
To consult the complete list of CPE names with products and versions, see this page