CVE-2022-47518

What it actually does

Missing validation of the number of operating channels in the WILC1000 wireless driver allows a heap-based buffer overflow when copying the channel list from incoming Wi-Fi management frames into a fixed-size kernel buffer.

Why it matters to the business

Local attackers can obtain full kernel-level control of affected Linux systems, enabling data theft, persistence, or denial of service on devices using the WILC1000 wireless chip; the large installed base of Linux increases exposure across servers, embedded devices, and workstations.

How an attack unfolds

An attacker with local access crafts or supplies a Wi-Fi management frame containing an excessive number of operating channels; the driver fails to validate the count before copying the list, overflowing the heap buffer and allowing arbitrary kernel code execution.

How to fix it

Upgrade the Linux kernel to version 6.0.11 or later (commit 0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0 or equivalent backport). Rebuild and reboot with the patched kernel; disable the WILC1000 driver if the hardware is not required.

How to confirm the fix worked

Confirm the running kernel is 6.0.11 or newer; inspect the driver source for the channel-count validation check before the memcpy of the operating-channel list; attempt to load the module and verify no crash occurs with a large channel list.

Typical attack path

1. Obtain local access to a system running a vulnerable kernel with the WILC1000 driver loaded
2. Trigger or inject a crafted 802.11 management frame containing an oversized channel list
3. Trigger the cfg80211 channel-list copy path in drivers/net/wireless/microchip/wilc1000/cfg80211.c
4. Exploit the resulting heap overflow to execute arbitrary code with kernel privileges

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for WILC1000 driver oops or slab-allocation warnings around channel-list handling; correlate with unexpected process creation or privilege-escalation events after wireless frame processing.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the WILC1000 driver to local users
• Apply the fix within normal patch windows given the local attack vector and lack of known in-the-wild exploitation
• Audit wireless driver usage and remove the module from kernel configurations where the hardware is absent
• Monitor kernel update channels for backported patches in supported LTS releases