CVE-2026-31780

What it actually does

CVE-2026-31780 is a Linux kernel memory corruption flaw in the Microchip WILC1000 Wi-Fi driver. The driver calculates the size of an SSID scan buffer using an 8-bit integer even though the total size can exceed 255 bytes when multiple SSIDs are supplied. The value wraps, causing the kernel to allocate a buffer that is too small and then copy substantially more data into it. This creates a heap buffer overflow in kernel memory. Because the flaw is reachable by a local privileged or semi-privileged user able to trigger Wi-Fi scan operations, successful exploitation could corrupt kernel heap memory and may lead to local privilege escalation, kernel crash, or arbitrary kernel memory manipulation depending on platform hardening and exploit reliability.

Why it matters to the business

Systems using the affected Linux kernel driver for WILC1000 Wi-Fi hardware may be vulnerable to local compromise. An attacker who already has access to run code on the system could potentially gain higher privileges, disable the device through a kernel crash, or tamper with the operating system. The CVSS score is high, but the current EPSS is very low, has shown no upward trend, is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; priority should be highest for embedded, IoT, industrial, or appliance-like Linux systems that include WILC1000 Wi-Fi support and allow local users, applications, containers, or exposed services to trigger Wi-Fi scanning.

How an attack unfolds

An attacker first obtains local execution on a Linux system that includes the vulnerable WILC1000 Wi-Fi driver and has the relevant Wi-Fi interface available. The attacker then invokes wireless scan functionality through normal kernel interfaces, such as nl80211/cfg80211-based tooling or APIs, while supplying enough SSID entries of sufficient length to exceed the 8-bit size calculation used by the driver. The driver underestimates the required allocation size because the accumulated SSID length wraps around, allocates a small heap buffer, and then copies the full SSID scan list into it. This overwrites adjacent kernel heap memory. In a simple case, this may trigger a kernel warning, KASAN report, or system crash. In a more advanced case, the attacker attempts to shape the kernel heap so the overwrite corrupts useful adjacent objects, potentially gaining elevated kernel privileges or disabling security controls.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or kernel maintainer that includes the WILC1000 driver fix changing the SSID scan buffer size calculation from an 8-bit value to a wider integer type. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the specific kernel branch in use. Where immediate patching is not possible, mitigate by disabling or blacklisting the WILC1000 driver if the hardware is not required, disabling unused Wi-Fi functionality, restricting local shell or application access on affected devices, reducing the ability of untrusted workloads to interact with wireless management interfaces, and using kernel hardening features such as KASAN in test builds, lockdown, module signing, SELinux/AppArmor, and container isolation where applicable.

How to confirm the fix worked

Confirm exposure by checking whether the system runs a Linux kernel build that includes the WILC1000 Wi-Fi driver and whether WILC1000 hardware or modules are active. Review kernel package changelogs or vendor advisories to verify that the specific fix for the WILC1000 SSID scan buffer size overflow is included. Operational checks include inspecting loaded modules for wilc1000-related drivers, reviewing kernel configuration for WILC1000 support, and confirming whether affected Wi-Fi interfaces are present. After remediation, verify the updated kernel is booted, not merely installed, and that vulnerable modules are either patched or not loadable. In non-production test environments, KASAN-enabled kernels can help validate that scan operations no longer produce slab-out-of-bounds or heap-buffer-overflow reports.

Typical attack path

1. Gain local code execution on a Linux system with the affected WILC1000 Wi-Fi driver present and usable.
2. Confirm that WILC1000 Wi-Fi functionality is loaded, enabled, or reachable through wireless scan interfaces.
3. Trigger a Wi-Fi scan request containing multiple long SSID probe entries so the total encoded SSID list exceeds the 8-bit length limit.
4. Cause the driver to allocate an undersized kernel heap buffer due to integer wraparound.
5. Allow the subsequent copy operation to overflow the heap buffer and corrupt adjacent kernel memory.
6. Use the resulting memory corruption to crash the kernel or, with a reliable exploit, manipulate kernel memory for privilege escalation.

How to detect it

To assess possible prior exploitation, focus on host-level and kernel-level telemetry rather than network perimeter logs, because exploitation is local and occurs through Wi-Fi scan handling. Review journald, syslog, dmesg, kernel crash dumps, pstore/ramoops, KASAN/KFENCE reports, audit logs, EDR telemetry, and command history around times of unexplained reboots, kernel panics, or Wi-Fi instability. Look for WILC1000 driver activity followed by slab corruption, heap buffer overflow, general protection faults, kernel oops messages, or panics in wireless scan paths. Audit local processes or containers with permissions to manage wireless interfaces, especially those with CAP_NET_ADMIN or access to nl80211/cfg80211 operations. Because no public exploit or named threat actor is reported and exploitation artifacts may be indistinguishable from crashes or fuzzing, treat repeated scan-related kernel faults on systems with wilc1000 modules as the strongest available signal. Correlate any such events with newly created local accounts, suspicious privilege changes, unexpected setuid files, kernel module loading, or persistence activity after the crash window.

• wilc1000
• wilc_sdio
• wilc_spi
• WILC1000
• /sys/module/wilc1000
• /sys/module/wilc_sdio
• /sys/module/wilc_spi
• CONFIG_WILC1000
• slab-out-of-bounds
• heap-buffer-overflow
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• kernel BUG
• general protection fault
• Unable to handle kernel paging request
• Oops:
• cfg80211_scan
• nl80211
• SSID scan
• ramoops
• pstore

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and IoT platforms that include WILC1000 Wi-Fi hardware or the wilc1000 kernel driver.
• Prioritize patching systems where local users, third-party applications, containers, or remotely reachable services could trigger Wi-Fi scan behavior.
• Apply vendor kernel updates once available and ensure systems are rebooted into the fixed kernel.
• If WILC1000 Wi-Fi is unused, disable the interface and blacklist the related kernel modules as a compensating control.
• Limit untrusted local access and restrict capabilities that allow wireless interface management, especially CAP_NET_ADMIN in containers or services.
• Monitor kernel logs for crashes, KASAN findings, heap corruption, or suspicious Wi-Fi scan activity involving wilc1000 drivers.
• Track vendor advisories because fixed versions were not supplied and may differ by kernel branch, distribution, or embedded device firmware.
• Treat unexplained kernel panics on affected Wi-Fi-enabled devices as potentially security relevant until reviewed.