A newly disclosed Linux kernel vulnerability, CVE-2026-31506, exposes a double-free mistake in the bcmasp Ethernet driver’s Wake-on-LAN (WoL) interrupt cleanup path. Published on April 22, 2026, the bug can cause system crashes, memory corruption, or instability during device teardown—particularly when network interfaces are brought down, suspended, or unloaded. The flaw affects Broadcom ASP network hardware and, while the fix is straightforward, it’s a stark reminder of how dangerous resource management slip-ups can be in kernel code.

What Actually Changed

The bcmasp driver uses the Linux kernel’s managed resource (devm) API to request its WoL interrupt. When a driver uses devm_request_irq, the kernel automatically releases the interrupt when the device is detached—no manual cleanup required. In the faulty code, however, the driver explicitly freed that same IRQ later on, a classic ownership mismatch. The first automatic release already handled it; the manual free hit the same object again, a textbook double free.

The upstream fix is a one-liner: delete the redundant free_irq call. The patch landed in the net tree and is being backported across stable branches. The CVE entry on Microsoft’s Security Response Center (yes, that’s Microsoft—an artifact of the CVE assignment process) carries no CVSS score yet, but that’s normal for fresh disclosures.

Why a Double Free Matters

Even if this seems like a tiny bug, kernel memory management errors are never trivial. A double free can corrupt slab allocator state, trigger a use-after-free, or—in the worst case—create an exploitable path for privilege escalation. For most sysadmins, the likelier symptom is a kernel oops, a driver crash, or a sudden warning when unbinding the device. Because WoL paths run during power transitions, the bug can also surface silently after a resume from sleep, making it hard to diagnose.

The Linux community increasingly treats such reliability bugs as security issues because of the kernel’s privilege level. This CVE follows that trend, even though no public exploit has been demonstrated.

What It Means for You

The practical impact depends heavily on whether you run hardware that uses the bcmasp driver.

For Home Users

If you’re running a standard Linux desktop or laptop with Intel, Realtek, or older Broadcom Wi‑Fi adapters, you’re almost certainly not affected. The bcmasp driver supports a niche set of Broadcom ASP Ethernet controllers found mainly in embedded and specialized devices. Even if you have a compatible NIC, you’d also need Wake-on-LAN enabled and actively toggling the interface to hit the teardown path. For most home users, risk is negligible.

For IT Administrators and Data Center Operators

Here’s where things get real. If you manage Linux servers with Broadcom NetXtreme-S or similar ASP-based NICs, or if your infrastructure includes appliances built around Broadcom silicon (industrial gateways, NAS boxes, or out-of-band management cards), you need to check. These devices often have WoL enabled for remote wake, and the driver may be compiled in or loaded as a module.

A crash during a maintenance window—say, after a modprobe -r or a routine stop of network services—can look like a hardware fault. If you’ve ever tracked down a mysterious reboot in a fleet of identical nodes, a kernel bug like this is often the culprit. Without the fix, any workload that triggers driver unload or power-state changes becomes a stability gamble.

For Developers and DevSecOps

If you write or audit kernel code, this CVE is a free lesson in resource ownership semantics. Mixing devm-managed and manually released resources is a well-known anti-pattern. The bug isn’t in the WoL logic itself; it’s in the teardown. Every devm_request_irq must be matched by a corresponding devm_free_irq—or better yet, no explicit free at all. Code review tools should flag any manual free_irq that pairs with a managed request.

How We Got Here

The bcmasp driver was added to the Linux kernel to support Broadcom ASP Ethernet controllers, common in embedded and server environments. Like many network drivers, it handles interrupts, power management, and device lifecycle—a perfect storm for ownership bugs. When developers use devm_request_irq, the kernel’s device resource manager (devres) takes ownership of the IRQ. But older code paths often carry over manual free_irq calls from before devm adoption, creating time bombs.

Wake-on-LAN makes teardown even trickier. The WoL interrupt must stay registered to wake the system, yet it must be torn down cleanly when the device is removed. The bug triggered exactly in that boundary zone: the driver set up the WoL IRQ with devm, but later, when cleaning up the general interrupt structure, it also freed the WoL IRQ explicitly.

This isn’t the first—or last—time such a mismatch has bitten the kernel. Similar CVEs have appeared in other drivers. The kernel’s own CVE documentation notes that “nearly any bug may be exploitable,” which is why fixes like this one often receive CVE identifiers before a real-world exploit is known.

The timeline is quick: the fix was merged upstream, and the CVE was published within days. NVD has not yet added a severity score, but that doesn’t lower the urgency for affected systems.

What to Do Now

If you think you might have vulnerable hardware, here’s a step-by-step action plan.

  1. Check if the bcmasp module is loaded
    Run lsmod | grep bcmasp on any Linux host. If you see output, you’re using the driver.

  2. Verify Wake-on-LAN state
    Use ethtool <interface> | grep Wake-on. If Wake-on is enabled (shows g or d), the WoL interrupt path is live.

  3. Monitor distribution advisories
    Track security announcements from your Linux vendor (Red Hat, Ubuntu, SUSE, etc.). The fix will appear as a kernel update, often with the CVE explicitly referenced.

  4. Apply patches on a regular schedule
    Since there’s no known active exploit, you have a window to test updates. But don’t let this sit for months—long-lived unpatched fleets multiply the chance of hitting the bug during a maintenance event.

  5. Temporary workaround
    If you experience sporadic crashes and suspect this driver, you can disable WoL temporarily: ethtool -s <interface> wol d. This stops the WoL interrupt path without removing the driver. It’s not a permanent fix, but it can buy time until patching.

  6. Validate in a test environment
    If you’re cautious, replicate the teardown sequence—modprobe removal, suspend/resume cycles—in a sandbox with the patched kernel to ensure stability before broad rollout.

For embedded device owners, check if your manufacturer has a firmware or kernel update. Many vendors are slow to backport; you may need to lobby for a patch or replace the device if it’s mission-critical.

Outlook

The immediate fix will propagate through the stable kernel trees (6.1.y, 6.6.y, etc.) within days. Vendors like Red Hat and Canonical typically issue errata within a week or two. NVD will eventually assign a CVSS score—likely in the medium or high range given the potential for crashes and the driver’s privileged context.

More importantly, this CVE is likely to trigger an audit of similar WoL cleanup paths in other Broadcom drivers and beyond. The broader lesson—that mixing managed and unmanaged resource releases is a recipe for disaster—is now underscored by a public vulnerability. Expect stricter code reviews around devm usage, and maybe even static analysis rule updates in tools like Sparse or Coccinelle.

For the average Windows user, this story is a non-event—unless you’re running Linux VMs or managing a fleet of servers. But for IT professionals bridging both worlds, it’s a clear signal: kernel-level stability bugs don’t care about your OS religion. Keep an eye on your Linux boxes, apply patches early, and remember that even a one-line fix can prevent a week of headache.