CVE-2022-48984
Linux CAN slcan Freed Work Crash Vulnerability
Description
In the Linux kernel, the following vulnerability has been resolved: can: slcan: fix freed work crash The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) 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 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed. So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances. The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()? I see the same pattern in can327. So it perhaps needs the very same fix.
INFO
Published Date :
Oct. 21, 2024, 8:15 p.m.
Last Modified :
Oct. 25, 2024, 3:53 p.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
3.6
Exploitability Score :
1.8
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2022-48984.
| URL | Resource |
|---|---|
| https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | Patch |
| https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | Patch |
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2022-48984 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2022-48984 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Oct. 25, 2024
Action Type Old Value New Value Added CVSS V3.1 NIST AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Changed Reference Type https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 No Types Assigned https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 Patch Changed Reference Type https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb No Types Assigned https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb Patch Added CWE NIST CWE-476 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.0 up to (excluding) 6.0.13 *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:*:*:*:*:*:* -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Oct. 21, 2024
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: can: slcan: fix freed work crash The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) 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 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed. So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances. The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()? I see the same pattern in can327. So it perhaps needs the very same fix. Added Reference kernel.org https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2022-48984 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2022-48984
weaknesses.