Microsoft has quietly added CVE-2026-23357 to its Security Update Guide — a Linux kernel vulnerability that can cause a system to freeze when a CAN bus interface is brought up. The bug, rated medium severity with a CVSS score of 5.5, affects drivers for the wildly popular MCP251x and MCP25625 SPI CAN controllers found in countless development boards, industrial gateways, and automotive prototypes.

The vulnerability isn’t a traditional remote exploit. It’s a deadlock in the driver’s error-handling path that occurs when opening a CAN interface fails and an interrupt fires at just the wrong moment. The result: the kernel hangs, the network interface setup stalls, and in embedded environments, the whole device may become unresponsive until a hard reboot.

The technical breakdown

At the heart of the problem is a locking-order mistake in the mcp251x_open() function of the SocketCAN mcp251x driver. When a user or script tries to bring up a CAN interface (like can0), the driver acquires a mutex lock (mcp_lock) to protect shared resources. If something goes wrong during initialization — a clock issue, an SPI hiccup, a hardware reset failure — the driver enters an error cleanup path that attempts to release the interrupt request (IRQ) by calling free_irq().

Here’s where it gets messy. free_irq() doesn’t just cancel the IRQ; it waits for any in-flight interrupt handler to complete. But in this driver, the interrupt handler itself may need to grab that same mcp_lock mutex. If the error path holds the mutex and then calls free_irq(), while the interrupt handler is patiently waiting for the lock, neither side can move forward. The kernel is deadlocked.

To be clear: this isn’t a bug triggered by sending malicious CAN frames over the wire. A local user or service with the ability to open a CAN interface — even accidentally — can trip the deadlock if the driver’s failure path is exercised. In practice, that could be an admin running ip link set can0 up, a monitoring script, or an automated configuration tool.

Who should care?

If you’re a Windows user reading this, you might wonder why a Linux kernel CVE appears on Microsoft’s radar. The answer says a lot about today’s cross-platform reality.

  • Windows sysadmins managing mixed environments: Your organization may run Linux virtual machines, containers, or IoT devices that use CAN bus hardware. Microsoft’s tracking of this CVE ensures it appears in your security tooling if you scan Linux endpoints.
  • WSL and Azure Linux workloads: While typical Windows Subsystem for Linux installations won’t have an SPI-connected MCP2515 module, specialized development environments or hardware-in-the-loop test benches might. And Azure IoT Edge devices, often Linux-based, can absolutely include these CAN controllers.
  • Embedded and industrial system maintainers: This is the group that should pay closest attention. If you use Raspberry Pi, BeagleBone, or custom boards with MCP2515 modules for CAN communication, a deadlock in the kernel driver is an availability killer. In an automotive diagnostic tool or a factory floor controller, a frozen kernel means lost data, missed alarms, or worse.

For the typical home Windows user who never touches Linux or embedded systems, this CVE is noise. For anyone who has ever typed dtoverlay=mcp2515-can0 into a config file, it’s a patch-now situation.

Affected kernel versions

The vulnerable driver has been present in the mainline Linux kernel since version 2.6.34, way back in 2009. NVD’s advisory lists a wide range of affected stable branches, including:

  • 5.10.x before 5.10.253
  • 5.15.x before 5.15.203
  • 6.1.x before 6.1.167
  • 6.6.x before 6.6.130
  • 6.12.x before 6.12.77
  • 6.18.x before 6.18.17
  • 6.19.x before 6.19.7
  • Various 7.0 release candidates (rc1 through rc7)

These version ranges are a starting point, not the last word. Linux distributions often backport fixes without bumping the reported kernel version. A Red Hat Enterprise Linux 8 system showing kernel 4.18 may already have the patch, while a custom Yocto build claiming 5.15.100 might not. The only reliable check is to look for a specific commit from your vendor’s changelog or confirm that the mcp251x_open() function no longer calls free_irq() while holding mcp_lock.

The fix is out, but not everyone will get it quickly

Upstream kernel maintainers pushed a straightforward repair: set a force_quit flag while the mutex is still held, then drop the lock, and only then call free_irq(). That breaks the circular wait. The interrupt handler, once it finally acquires the mutex, sees the quit flag and exits immediately instead of trying to work with a partially torn‑down interface.

Mainline and stable trees received the patch in late summer 2024, and Microsoft’s security guidance now reflects the CVE. But embedded device vendors often run older kernels and may take months — or years — to release updates. That lag is where risk accumulates.

How to check if you’re exposed

Run through this checklist on any Linux system you suspect might have CAN hardware:

  1. Does the system have an MCP251x device? Look for an SPI-attached CAN controller in your device tree or /boot/config.txt on a Pi.
  2. Is the driver loaded? Run lsmod | grep mcp251x or check /proc/modules.
  3. Are CAN interfaces defined? ip link show type can will list known CAN devices.
  4. Who can bring them up? Usually you need CAP_NET_ADMIN (root or network admin privileges). If you grant those broadly, the attack surface expands.
  5. Check your kernel version against the fixed ranges above. But remember: vendor backports matter more.

Even if the driver is present but no CAN hardware physically exists on the board, the deadlock can still be reached simply by trying to bring up a nonexistent interface that the kernel thinks should be there — a common scenario on development boards with device‑tree overlays that load the driver at boot.

Immediate steps if patching is delayed

  • Blacklist the driver if you don’t need it. Add blacklist mcp251x to a file in /etc/modprobe.d/ and rebuild your initramfs. This stops the module from loading, even if a device‑tree overlay tries to probe it.
  • Restrict CAN interface management. Remove network administration capabilities from untrusted users or containers. On systemd-based systems, limit who can call ip link on CAN devices via polkit rules.
  • Monitor for quirks. Unexplained hangs during boot or when bringing up CAN interfaces are a red flag. Check dmesg for MCP251x initialization failures; they may precede a deadlock.

Microsoft’s stake in a Linux kernel CVE

Why is this on the Microsoft Security Update Guide? A few reasons:

  • Azure Sphere and IoT: Microsoft ships Linux-based operating systems for edge and IoT. Some of these can use CAN bus hardware in industrial scenarios.
  • Windows Subsystem for Linux: Although WSL typically virtualizes networking, direct hardware passthrough is uncommon but possible for USB-to-SPI adapters in specialized setups. Microsoft tracks kernel CVEs that could affect its WSL kernel builds.
  • Security ecosystem integration: Enterprise tools like Microsoft Defender for Cloud and the Security Update Guide aggregate CVEs across platforms. Including this vulnerability ensures it appears in your risk dashboards if you scan Linux workloads.

So no, this doesn’t mean your Windows 11 desktop is at risk. But it’s a reminder that modern IT environments are messy, and a Linux driver bug can ripple into your Windows-managed infrastructure.

The bigger picture for embedded Linux security

CVE-2026-23357 is another example of a long-tail kernel bug that sits unnoticed in error-handling code. Unlike the normal open/close path, the failure branch of mcp251x_open() rarely gets tested. The original commit that introduced the deadlock likely passed all smoke tests because nobody triggered a power‑failure reset or SPI bus error during interface initialization.

The same pattern has bitten the MCP251x driver before — kernel maintainers referenced a similar deadlock fix from years ago. This one hid in the error-path cleanup, surviving because most CAN interfaces either work perfectly or fail hard enough to reboot the system before the deadlock manifests.

For organizations running fleets of embedded Linux devices, this CVE highlights the importance of at least two practices:

  • Curated kernel updates. Don’t rely on upstream version numbers alone. Maintain a list of specific commits that fix known vulnerabilities in the drivers your product uses.
  • Fault‑injection testing. If your device depends on CAN communication, deliberately induce failures during interface bring‑up to see how the system behaves. A hang is unacceptable.

Outlook

Microsoft’s listing of this CVE may signal a broader trend: the security update guide is becoming a clearinghouse for vulnerabilities that cross the Windows/Linux boundary. As companies run more Linux workloads on Azure and integrate Windows with IoT devices, expect to see more Linux‑kernel CVEs appearing in Microsoft’s inventories.

Meanwhile, if you’re maintaining a system with an MCP2515 module, patch sooner rather than later. A deadlock with no remote trigger sounds harmless — until you’re on the factory floor at 3 a.m., staring at a frozen LCD panel that was supposed to show live CAN telemetry.