CVE-2022-48984 is a vulnerability identified in the Linux kernel specifically affecting the slcan (serial line CAN) driver, which is used to interface CAN (Controller Area Network) devices over serial lines. The issue arises from improper handling of workqueue tasks related to the transmission work (tx_work) in the slcan driver. The vulnerability manifests as a kernel NULL pointer dereference leading to a crash (kernel oops) when the slcan driver’s tx_work is freed while still being scheduled. This occurs because the slcan_netdev_close() function calls flush_work() on tx_work to ensure the workqueue task is completed before freeing, but the slcan_close() function does not. If the network device is never set UP but the tty device receives data and triggers a write wakeup, the workqueue task is scheduled but not flushed, resulting in a use-after-free condition and subsequent kernel crash. The root cause is a race condition between the netdev and tty sides of the driver, where the flushing of the workqueue is inconsistently applied. The proposed fix is to add flush_work() in slcan_close() to guarantee the workqueue task is flushed in all scenarios, preventing the use-after-free and kernel panic. The vulnerability was observed in Linux kernel version 6.0.8-1-default on openSUSE Tumbleweed but is likely relevant to other distributions using similar kernel versions and slcan driver implementations. The issue is a stability and availability risk rather than a direct privilege escalation or confidentiality breach. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability also hints at a similar pattern in the can327 driver, suggesting a broader potential impact within CAN-related kernel drivers.

For European organizations, the primary impact of CVE-2022-48984 is on system stability and availability where Linux systems utilize CAN interfaces via the slcan driver. This is particularly relevant for industries relying on embedded Linux systems interfacing with CAN buses, such as automotive manufacturing, industrial automation, transportation infrastructure, and IoT deployments. A kernel crash caused by this vulnerability could lead to denial of service conditions, disrupting critical operations and potentially causing downtime in production environments. While the vulnerability does not directly expose confidentiality or integrity risks, the resulting system instability could indirectly affect operational continuity and safety-critical systems. Organizations running Linux kernels with affected slcan driver versions in embedded devices or networked systems should be aware of this risk. The lack of known exploits reduces immediate threat urgency, but the vulnerability’s presence in kernel code means it could be triggered by local processes or device interactions, making it a concern for systems with CAN device usage. European entities with automotive supply chains or industrial control systems that rely on Linux-based CAN interfaces are particularly at risk of operational disruption if unpatched.

To mitigate CVE-2022-48984, organizations should: 1) Apply the official Linux kernel patches that add flush_work() calls in slcan_close() to ensure proper synchronization of workqueue tasks and prevent use-after-free conditions. 2) Update Linux kernel versions to the latest stable releases that incorporate this fix, especially on systems using CAN interfaces over serial lines. 3) Conduct thorough testing of CAN-related kernel modules (slcan and can327) in controlled environments before deploying updates to production to avoid regressions. 4) Monitor system logs for kernel oops or crashes related to CAN device operations as an early indicator of exploitation attempts or triggering conditions. 5) For embedded and industrial Linux systems, implement robust update mechanisms to deploy kernel patches promptly. 6) Limit access to CAN devices and associated interfaces to trusted users and processes to reduce the risk of accidental or malicious triggering of the vulnerability. 7) Consider isolating or sandboxing CAN interface handling where feasible to contain potential crashes and minimize impact on overall system availability.