The Linux kernel project has disclosed and patched CVE-2026-31506, a double-free bug in the bcmasp network driver that can corrupt kernel memory and trigger crashes during device teardown or Wake-on-LAN (WoL) operations. The fix, a small upstream change, removes a manual interrupt-free call that was already being handled automatically by the kernel’s device-managed resource framework. While the bug has a narrow trigger, it underscores how ownership confusion in driver cleanup paths can silently destabilize systems—especially those relying on WoL for remote power management.

The Bug at a Glance

At its core, CVE-2026-31506 is a classic resource-ownership mistake. The bcmasp driver—used with certain Broadcom-based Ethernet controllers—requests a WoL interrupt using the devm_request_irq() function. That helper does two things: it registers an interrupt handler and, crucially, ties the interrupt lifecycle to the device object. The kernel’s managed-resource (devres) framework later frees the interrupt automatically when the device is released or the driver module is unloaded.

But the original driver code also explicitly freed the same interrupt (wol_irq) in its own cleanup routine. The result: when the device went away, the interrupt was freed first by the framework, then again by the driver’s leftover manual call. That’s a double free—a serious memory-safety violation that can scramble the kernel’s internal allocator bookkeeping and lead to undefined behavior, including panics.

The patch, according to the advisory, is a single removal of the redundant free. It does not add any new logic or conditional checks; it simply deletes the line that duplicated cleanup responsibility. That restraint is, in itself, a marker of good kernel maintenance: the fix aligns the code with the contract it had already implicitly signed by using a managed API.

Who’s Affected and What’s the Risk?

The practical exposure depends heavily on your hardware and how you use it. The bcmasp driver is device-specific; if you’re not running a system with the relevant Broadcom networking hardware, you’re almost certainly safe. But for those who are, the risk profile splits along two lines.

For home users and small offices: The danger is low. Most consumer desktops and laptops don’t lean heavily on WoL, and the double free only materializes on relatively rare teardown paths—driver unload, system suspend/resume cycles, or error recovery when the device fails to probe. In normal packet-forwarding, the bug never fires. However, a kernel panic during shutdown can be more than a nuisance: it might corrupt filesystems or leave the machine in an inconsistent state, even if only once in a blue moon.

For enterprise administrators: The stakes are higher. Data centers, server farms, and fleets of managed endpoints often rely on WoL to power machines on remotely—just when a sysadmin expects stability. If a server crashes on suspend or a bare-metal node panics during a routine driver reload, the operational impact can ripple outward. The bug is not a remote-code-execution engine; there is no indication it can be triggered by network traffic. But it can cause a denial of service locally, and in an environment where uptime is paramount, an avoidable crash is a security problem by any name.

Why a Double Free in the Kernel Matters

Double-free bugs in the kernel are worse than memory leaks. A leak slowly exhausts a resource; a double free actively corrupts the metadata the allocator uses to track memory. Once that metadata is scrambled, subsequent allocations or frees can hand out overlapping regions, write over live objects, or trigger fatal page faults at unrelated code locations. The result is seldom a neat panic message pointing at the guilty driver. Instead, the system may limp along in a corrupted state until it finally keels over in a way that makes post-mortem debugging extremely difficult.

This particular bug sits in territory that modern kernel development has worked hard to secure. The devm_* family of functions was introduced precisely to eliminate cleanup errors. By centralizing resource teardown in the device core, developers no longer need to remember to release every interrupt, memory region, or I/O mapping in every error branch. But the APIs are only effective when the rest of the code respects the new ownership model. If a driver manually frees what the framework already owns, the abstraction breaks, and the kernel is worse off than if it had never been used at all.

The Fix: A One-Line Change That Prevents Chaos

The upstream patch for CVE-2026-31506 is so minimal that it almost reads like a teaching example. It does not restructure the driver, add error handling, or introduce a safer wrapper. It just removes the free_irq() call for wol_irq. After the fix, the interrupt is requested via devm_request_irq() and thereafter left entirely to the device core’s cleanup machinery. No more duplication.

This is an ideal corrective for several reasons:

  • Low regression risk: The change affects only the teardown path, not the hot-path interrupt handling.
  • Clarity for future maintainers: Anyone reading the driver later will see a single, unambiguous source of truth about who frees the interrupt. That prevents the error from being reintroduced.
  • Backport-friendly: The patch applies cleanly to stable and long-term-support kernel branches, meaning distributions can adopt it quickly without fear of collateral breakage.

For administrators wondering about urgency: while the National Vulnerability Database had not assigned a severity score at the time of writing, the structural importance of the fix is high. Kernel developers don’t assign CVE numbers to trivial style nits; this bug was judged capable of causing real harm, and the patch should be treated as a routine but important part of the kernel security update cadence.

How to Defend Against This Vulnerability

The actions to take depend on your role and environment.

Check if you’re exposed. On any Linux machine, you can see if the bcmasp driver is loaded:

lsmod | grep bcmasp

If the module appears, or if your hardware uses a Broadcom network adapter that relies on this driver (common in certain embedded systems, set-top boxes, and some server NICs), assume vulnerability until you confirm otherwise.

Update your kernel. The first and simplest defense is to install the latest kernel update from your distribution. Most enterprise distros (Red Hat, Ubuntu, SUSE) will backport the fix to their supported streams. If you maintain a custom kernel, cherry-pick the upstream commit or rebuild with the driver statically updated.

Monitor vendor advisories. Broadcom and original equipment manufacturers may issue their own guidance, especially for appliances where the kernel is not easily user-upgradable. For cloud and data-center environments, keep an eye on the release notes of your kernel packages.

Consider a temporary workaround if you can’t patch immediately. If WoL is not required for operation, disabling it can eliminate the code path entirely. This can often be done with ethtool:

ethtool -s <interface> wol d

But be aware that this only disables WoL at the device level; it does not remove the vulnerable driver from the kernel, so it’s a mitigation, not a fix.

For enterprise fleet managers, the operational priority should be weighted by how you depend on WoL. If you wake machines remotely, a crash on teardown could cause missed recovery windows or require physical access. Escalate the patch as you would for any kernel bug that could lead to a panic.

What Comes Next

The immediate story is one of distribution: how quickly the patch flows into the stable and long-term kernel trees, and from there into commercial and community distributions. Because the change is so narrowly scoped, there is little barrier to backporting, and we can expect it to appear in most maintained kernels within a single update cycle.

But the longer arc is more subtle. This CVE is part of a quiet, ongoing shift in kernel security toward enforcing ownership invariants through managed APIs. Every time a bug like this surfaces, maintainers often sweep through nearby code looking for similar patterns. It would not be surprising to see additional patches clarifying interrupt ownership in other networking drivers, especially those that also implement WoL.

Finally, the Linux kernel community’s response to CVE-2026-31506 is a reminder that not all security fixes come with a flashy attack narrative. Sometimes the most important work is simply correcting a broken contract between a driver and the core kernel—one line at a time.