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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel crash bug in the slcan driver, which bridges serial lines to CAN networking. Under specific teardown timing, queued transmit work can run after related data is freed, causing a kernel NULL pointer crash. Business impact is primarily availability on systems using affected kernels and slcan.
Executive priority
Treat as a targeted availability risk. Prioritize patching systems that use CAN-over-serial, embedded gateways, lab rigs, or industrial hosts. For ordinary servers without slcan usage, urgency is lower but should remain in normal kernel maintenance.
Technical view
The vulnerable path is in Linux CAN slcan. slcan_netdev_close() flushed tx_work, but slcan_close() did not. If the netdev was never brought up, tty-side activity could schedule tx_work and close without flushing it, leaving work queued against freed state. The fix adds flush_work() in slcan_close().
Likely exposure
Exposure is likely limited to Linux systems running affected 6.0-era kernels where slcan is present or usable. Higher relevance applies to CAN, serial, embedded, automotive, industrial, or test environments. The source bundle does not identify remote network exposure or broad default exploitation.
Exploitation context
The source describes a reproducible crash observed through LTP pty03 testing, not active exploitation. CISA KEV is false in the bundle. The available evidence supports a denial-of-service style kernel crash risk, with incomplete public evidence for privilege escalation or remote attack.
Researcher notes
Evidence is strong for the root cause and fix because the kernel commit narrative identifies the missing flush_work() path. Evidence is incomplete for exploitability beyond crash conditions. Avoid assuming remote reachability; validate local tty/slcan accessibility and vendor backport status.
Mitigation direction
Update to a vendor kernel containing the referenced stable slcan fix.
Check distribution advisories for exact fixed package versions and backports.
Limit untrusted local access to relevant tty, CAN, or slcan interfaces until patched.
If slcan is unused, follow vendor guidance to disable or remove exposure.
Validation and detection
Inventory Linux kernel versions and identify affected 6.0-era builds.
Check whether slcan support is built, loaded, or operationally required.
Confirm vendor patches include the referenced stable commits.
Review kernel logs for NULL pointer crashes involving slcan or workqueue paths.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48984 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.