CVE-2026-31506

What it actually does

This is a local Linux kernel memory-corruption flaw in the Broadcom ASP network driver path related to Wake-on-LAN interrupt handling. The vulnerable code frees a WoL IRQ resource even though it was allocated through device-managed resource handling, which means the kernel’s devres cleanup can free the same resource again. A double free in kernel context can corrupt kernel memory and may lead to local privilege escalation, kernel crash, or unpredictable system behavior. The CVSS vector indicates exploitation requires local access and low privileges, with no user interaction, and can affect confidentiality, integrity, and availability at high impact.

Why it matters to the business

Systems running affected Linux kernel builds may allow a low-privileged local user or compromised process to escalate privileges or crash the host. The main operational risk is to multi-user Linux systems, servers where untrusted code can run, container hosts, build workers, edge devices, appliances, or embedded platforms using the affected Broadcom ASP networking driver. EPSS is currently very low and there is no known KEV listing or public exploit maturity, so broad opportunistic exploitation is not indicated, but kernel privilege-escalation issues should still be treated seriously because they can turn an initial foothold into full system compromise.

How an attack unfolds

An attacker first needs local code execution or a low-privileged account on a system running an affected kernel with the vulnerable bcmasp driver code reachable. They then attempt to exercise the driver lifecycle or Wake-on-LAN IRQ cleanup path that incorrectly frees an IRQ resource already managed by devres. By triggering the cleanup sequence in a controlled way, the attacker may cause the same kernel resource to be released twice. Depending on allocator state, hardening configuration, hardware availability, and kernel build options, the result may be a kernel crash or exploitable memory corruption. If the memory corruption can be shaped reliably, the attacker may escalate from a low-privileged context to kernel-level execution or otherwise compromise host integrity.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the upstream fix removing the unnecessary free of the devm-managed WoL IRQ resource in the bcmasp driver. Because no exact fixed versions were provided, use distribution advisories and kernel changelogs to identify patched packages for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the affected Broadcom ASP driver if not required, disabling Wake-on-LAN features where feasible, restricting local shell access, limiting the ability to load or interact with kernel drivers, and applying kernel hardening controls such as lockdown mode, module signing, SELinux/AppArmor confinement, and least-privilege controls for users and workloads. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated by checking uname -r and comparing it against the vendor advisory for the platform. Verify the patched source or vendor kernel contains the bcmasp change that avoids explicitly freeing the devm_request_irq()-managed WoL IRQ. Check whether the affected driver is present or loaded using standard module and device inventory commands such as lsmod, modinfo, lspci, dmesg, and distribution package queries. After patching and rebooting, validate that network interfaces using the driver initialize and shut down cleanly and that Wake-on-LAN behavior, if used, continues to operate without kernel warnings. Vulnerability scanners should be configured to evaluate the active kernel version and distribution backport status rather than relying only on upstream version numbers.

Typical attack path

1. Obtain local access to an affected Linux system, such as through a shell, compromised service, container escape prerequisite, or low-privileged user account.
2. Confirm the system is running an affected kernel and that the Broadcom ASP network driver path is present and reachable.
3. Trigger network device, driver, or Wake-on-LAN cleanup behavior that reaches the faulty double-free path.
4. Use repeated attempts or heap-shaping techniques to turn the double free into a controlled kernel memory-corruption condition, if feasible.
5. Achieve one of the likely outcomes: local privilege escalation, kernel crash, or denial of service.
6. If privilege escalation succeeds, establish persistence, access sensitive data, or move laterally from the compromised host.

How to detect it

Detection should focus on evidence of attempted local kernel exploitation or instability around the affected bcmasp driver path. Review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for double-free, use-after-free, slab corruption, kernel oops, panic, or warnings involving bcmasp, Wake-on-LAN, IRQ cleanup, devres, or devm-managed IRQ resources. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, auditd logs, EDR telemetry, and privileged command history. Because no public exploit or unique network indicator is known, absence of a specific IOC does not prove absence of exploitation. Hunt for suspicious sequences where a low-privileged user or process repeatedly manipulates network interface state, triggers driver unload/reload behavior, changes Wake-on-LAN settings, or is followed by a kernel crash, unexpected reboot, new root-level process, modified sudoers/authorized_keys files, or newly loaded kernel modules.

• bcmasp
• WoL irq
• wol_irq
• devm_request_irq
• double free
• kernel BUG
• kernel oops
• kernel panic
• slab corruption
• general protection fault
• BUG: unable to handle kernel
• WARNING: CPU
• use-after-free
• KASAN
• KFENCE
• devres
• Wake-on-LAN

What your security team should do

• Prioritize patching systems where local users, CI/CD jobs, containers, third-party workloads, or internet-facing services can provide an attacker with an initial foothold.
• Inventory Linux hosts for affected kernel packages and for use of the Broadcom ASP/bcmasp driver, with special attention to appliances, embedded systems, edge devices, and ARM-based platforms.
• Apply vendor kernel updates and reboot systems into the fixed kernel; track exceptions where reboot windows delay remediation.
• If patching is delayed, disable the affected driver or Wake-on-LAN functionality where operationally acceptable and restrict local access to trusted administrators only.
• Monitor for kernel crashes, oops messages, slab allocator warnings, or suspicious privilege escalation activity on systems with the affected driver.
• Because EPSS is low, not KEV-listed, and exploit maturity is reported as none, balance emergency response against asset criticality, but do not defer remediation indefinitely for multi-user or workload-hosting systems.