The Linux kernel is the heart of most modern operating systems, especially in servers, embedded systems, and Android devices. With its complexity, even small design oversights can open the door to resource leaks or worse.

Today, let’s dive into CVE-2024-27391, a vulnerability fixed in the Wi-Fi driver (wilc100) for certain Microchip wireless chipsets. We’ll explain what happened, how you could spot it, how the bug manifested in practice, and how it was fixed—with clear examples and helpful snippets so you can follow along, whether you’re an enthusiast or a professional.

What Is CVE-2024-27391?

In short:
When adding new interfaces to a wilc100 Wi-Fi device, the Linux kernel used to create (allocate) a new *workqueue* every single time. The old workqueues stuck around, wasting memory and system resources, which could be abused. This resource leak could potentially allow a local attacker to make the system unstable or even crash it by exhausting kernel memory.

Original References

- Kernel Patch Commit
- Kernel Bugzilla Discussion
- NVD Entry (CVE-2024-27391)
---

Workqueue Allocation Change:

In a previous change, the creation of the Wi-Fi driver's workqueue was moved into a setup function (wilc_netdev_ifc_init).

The function wilc_netdev_ifc_init is called every time a new interface is added.

So, every time someone runs a command to add a virtual Wi-Fi interface, the driver creates another workqueue—without freeing the old one. Over time, this clutters up system resources.

You can trigger this leak yourself (on a vulnerable kernel with wilc100 hardware) like this

for i in $(seq  10)
do
  iw phy phy interface add wlan1 type managed
  iw dev wlan1 del
done

ps -eo pid,comm|grep wlan   # Reveals 'kworker' kernel threads for each workqueue

Sample output

 39 kworker/R-wlan
 98 kworker/R-wlan1
102 kworker/R-wlan1
...
129 kworker/R-wlan1

This is abnormal—normally, there should be only one such process per PHY. Here, we have one for each added interface, all hanging around even after the interfaces have been deleted.

Can This Be Exploited?

Yes, locally.
If an attacker can repeatedly add and remove Wi-Fi interfaces (using iw or any kernel API), they can create a workqueue leak. Over time, these kernel objects:

Can eventually *crash* the device (Denial of Service)

Who’s at risk?

Devices running the vulnerable kernel with wilc100 Wi-Fi hardware (common in some embedded devices)

- Any user (even non-root, in some configurations) able to create/destroy interfaces

Here’s a simplified version of what happened in the kernel

static int wilc_netdev_ifc_init(struct net_device *dev)
{
    // ...
    wilc->hif_workqueue = create_singlethread_workqueue(workqueue_name);
    // ... not tracking / cleaning up old workqueues!
}

You can see: No check for an existing workqueue.
Each call allocates one, and the old isn’t freed. Memory leak!

The Fix (How It Was Patched)

The solution:
- Move workqueue creation back to kernel initialization (wilc_cfg80211_init), so it happens *only once per PHY*.
- Name the workqueue according to the physical device, not the network interface, since it’s *shared* by all.

Post-fix code

// In wilc_cfg80211_init() — called once per device, not per interface
snprintf(workqueue_name, sizeof(workqueue_name), "wq_wilc_%s", wiphy_name);
wilc->hif_workqueue = create_singlethread_workqueue(workqueue_name);

Key Lessons

- Move resource allocation as high up as possible (least often called): Allocate costly objects (like workqueues, memory, threads) in functions that are called rarely—ideally at *init*—not at every dynamic event.
- Clean up after yourself: Always clean any previously allocated resources if you're about to overwrite.

Final Word

CVE-2024-27391 is a good example of how a "simple" refactoring can have subtle but system-critical consequences, especially when it comes to kernel resources.
If you use the wilc100 or develop kernel code: *pay attention to lifecycle management!* A small oversight can mean a big security headache.

Further Reading

- Linux Kernel Documentation: workqueue
- Full commit diff on kernel.org

Timeline

Published on: 05/01/2024 13:15:51 UTC
Last modified on: 09/18/2025 16:06:27 UTC