CVE-2023-52768

What it actually does

Slab out-of-bounds write in wilc_wlan_handle_txq caused by allocating vmm_table without multiplying the requested size by sizeof(u32), allowing writes past the end of the buffer when indexing into the table during TX queue processing.

Why it matters to the business

Systems using the wilc1000 Wi-Fi driver may experience kernel memory corruption, crashes, or potential privilege escalation under sustained wireless traffic, increasing downtime and security exposure on affected Linux devices.

How an attack unfolds

An attacker with the ability to influence TX queue activity (via crafted wireless frames or local traffic generation) triggers repeated calls to wilc_wlan_handle_txq, causing the out-of-bounds write into adjacent kernel slab memory and potentially leading to code execution or denial of service.

How to fix it

Update the Linux kernel to a fixed version such as 5.15.140 or apply commit 541b3757fd443a68ed8d25968eae511a8275e7c8 (or later stable equivalents) that corrects the vmm_table allocation size.

How to confirm the fix worked

Confirm the running kernel contains the corrected allocation (vmm_table size multiplied by sizeof(u32)) and test under load with KASAN or similar memory debugging enabled to verify absence of slab-out-of-bounds reports.

Typical attack path

1. Obtain access to a system or network segment that can generate traffic processed by the wilc1000 driver
2. Send or induce sustained TX queue activity (e.g., high-volume UDP or iperf-like flows over Wi-Fi)
3. Trigger the mismatched allocation/indexing path in wilc_wlan_handle_txq
4. Perform out-of-bounds write into slab memory to corrupt adjacent structures
5. Escalate to kernel code execution or induce a crash

How to detect it

Review kernel logs for KASAN or slab-out-of-bounds messages referencing wilc_wlan_handle_txq and wlan0-tx; inspect crash dumps or dmesg for vmm_table write violations.

• BUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq
• Write of size 4 at addr .* by task wlan0-tx
• vmm_table

What your security team should do

• Prioritize kernel upgrades on all systems exposing the wilc1000 driver
• Restrict wireless interfaces or disable the driver where not required until patched
• Monitor for kernel oops or slab corruption logs related to wilc_wlan_handle_txq
• Apply the fix within standard patch windows given low but non-zero exploitability