CVE-2025-37993VulnerabilityPublished 29 May 2025

CVE-2025-37993: Linux · Vulnerability

Affects LinuxSource CVE Database V5

Not known to be exploited.

Data as of 25 Oct 2026, 19:02 UTC

Severity

Medium

Rated Medium by the CNA (Linux) · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 8% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

Disclosed: evidence found.
CVE published 29 May 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

AI-suggested

To mitigate CVE-2025-37993, organizations should: 1) Apply the official Linux kernel patches that initialize the tx_handling_spinlock in the m_can_class_allocate_dev() function as soon as they become available. 2) For embedded or automotive Linux systems, coordinate with hardware and software vendors to ensure updated kernel versions are deployed in devices using the m_can driver. 3) Conduct thorough testing of CAN-related functionality after patching to confirm stability and absence of spinlock errors. 4) Implement monitoring for kernel logs on CAN-enabled devices to detect any spinlock-related warnings or crashes indicative of unpatched systems. 5) Restrict local access to systems running vulnerable kernels to trusted personnel only, as exploitation requires local code execution or interaction with CAN utilities. 6) For critical infrastructure, consider network segmentation and strict access controls around embedded Linux devices to limit attack surface. 7) Maintain an inventory of devices using the m_can driver to prioritize patching and risk assessment.

Description

In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg.when trying to send CAN frames with cansend from can-utils: | BUG: spinlock bad magic on CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [<ffffffff800133e0>] dump_backtrace+0x1c/0x24 | [<ffffffff800022f2>] show_stack+0x28/0x34 | [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68 | [<ffffffff8000de70>] dump_stack+0x14/0x1c | [<ffffffff80003134>] spin_dump+0x62/0x6e | [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142 | [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c | [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a | [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee | [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292 | [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8 | [<ffffffff8073b8fa>] can_send+0xc6/0x242 | [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c | [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee | [<ffffffff801d06ea>] vfs_write+0x184/0x3a6 | [<ffffffff801d0a88>] ksys_write+0xa0/0xc0 | [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c | [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212 | [<ffffffff807a830a>] handle_exception+0x146/0x152 Initializing the spin lock in m_can_class_allocate_dev solves that problem.

Impact

For European organizations, the impact of CVE-2025-37993 depends largely on their use of Linux-based systems that incorporate the m_can CAN driver, typically found in embedded systems, automotive control units, industrial automation, and IoT devices. If exploited, this vulnerability could lead to kernel crashes or denial of service (DoS) conditions on affected devices, disrupting critical operations. In sectors such as automotive manufacturing, transportation, and industrial control systems prevalent in Europe, this could result in operational downtime, safety risks, and potential financial losses. While no known exploits are currently reported in the wild, the vulnerability's presence in the kernel could be leveraged by attackers with local access or through compromised software to destabilize systems. Confidentiality and integrity impacts are limited since the vulnerability primarily causes availability issues through kernel instability. However, in safety-critical environments, availability disruptions can have severe consequences. European organizations relying on embedded Linux devices with CAN bus communication should be particularly vigilant, as these devices are integral to vehicle networks and industrial machinery.

Summary

CVE-2025-37993 is a vulnerability identified in the Linux kernel's CAN (Controller Area Network) subsystem, specifically within the m_can driver. The issue arises because the spin lock named tx_handling_spinlock, which is part of the m_can_classdev structure, is not properly initialized during the device probe phase in the function m_can_class_allocate_dev(). This lack of initialization leads to a 'spinlock bad magic' error when the kernel attempts to send CAN frames, for example, using the cansend utility from can-utils. The error manifests as a kernel bug report indicating corrupted or uninitialized spinlock state, which can cause kernel instability or crashes. The root cause is that the spinlock's magic number, owner, and owner_cpu fields remain unset, triggering kernel warnings and potential deadlocks or race conditions during CAN frame transmission. The vulnerability was resolved by ensuring that the spinlock is properly initialized during device allocation, preventing the kernel from encountering invalid spinlock states. This vulnerability affects Linux kernel versions prior to the patch and is relevant to systems using the m_can CAN controller driver, which is common in embedded and automotive Linux environments.

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Description

AI analysisMachine-generated, updated 8 Jul 2025, 03:27 UTC

Technical details

References

Community reviews

Related threats