Description

The Silicon Labs SiWx917 WiFi driver's transmit callback siwx91x_send() in drivers/wifi/siwx91x/siwx91x_wifi.c frees a network packet it does not own. In the Zephyr TX path the net_pkt is owned by the L2/networking stack; the driver only borrows it to copy the frame bytes into a local net_buf. Before the fix, after transmitting, siwx91x_send() additionally called net_pkt_unref(pkt) on the caller-owned packet, dropping its last reference and returning it to the shared packet pool prematurely. This code path is compiled in by default (CONFIG_WIFI_SILABS_SIWX91X_NET_STACK_NATIVE). The caller, ethernet_send() in subsys/net/l2/ethernet/ethernet.c, keeps using the packet after the driver returns: it reads net_pkt_get_len(pkt), updates TX statistics, and then performs its own net_pkt_unref(pkt). Because the driver already released the packet, these are use-after-free reads followed by a second unref (a double free). When concurrent network activity recycles the freed slab slot between the two unrefs, the trailing unref decrements a different, live packet's reference count and frees it, corrupting the net_pkt pool shared by both the receive and transmit paths. The defect is exercised by ordinary transmission over the native-stack SiWx917 WiFi interface, and an adjacent attacker on the same WiFi network can induce transmissions (for example ARP or ICMP echo replies, or TCP handshakes) to drive the path. The primary observable impact is loss of availability (transmit hangs and crashes from pool corruption), with race-dependent memory corruption of the kernel networking buffer pool. The fix removes the erroneous net_pkt_unref(pkt) from siwx91x_send(); the driver's receive-path unref, which correctly frees a packet the driver itself allocated, is unaffected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-08-31T17:17:36.920Z",
  "pubdate": "2026-08-31T17:17:36.920Z",
  "executiveSummary": "The Silicon Labs SiWx917 WiFi driver for the Zephyr RTOS contains a critical use-after-free vulnerability within its transmit callback function, siwx91x_send(). The issue stems from improper reference counting where the driver prematurely releases a network packet that it does not own. This flaw allows an attacker to induce memory corruption within the kernel's networking buffer pool.\nThe vulnerability affects the native networking stack implementation (CONFIG_WIFI_SILABS_SIWX91X_NET_STACK_NATIVE) in the Zephyr kernel. Exploitation leads to a double-free scenario, which can result in denial-of-service via system crashes or non-deterministic behavior caused by the corruption of active network packets. An adjacent attacker on the same network can trigger this vulnerability by stimulating transmission traffic, such as ARP or ICMP requests, which forces the driver into the vulnerable code path. The primary risk is loss of system availability and potential kernel instability due to the corruption of shared memory pools.",
  "technicalDetails": "The root cause of this vulnerability is an ownership violation within the transmit (TX) path of the Silicon Labs SiWx917 driver, specifically located in drivers/wifi/siwx91x/siwx91x_wifi.c. In the Zephyr network stack architecture, the net_pkt structure is managed by the L2/networking layer. When ethernet_send() in subsys/net/l2/ethernet/ethernet.c invokes the driver's transmit callback, the driver is expected to only borrow the packet to copy its contents into local hardware-accessible buffers. However, the siwx91x_send() function erroneously calls net_pkt_unref(pkt) upon completion of the frame transmission.\nThis call prematurely decrements the reference count of the net_pkt, effectively returning the packet to the shared slab-based memory pool while the L2 layer still maintains a reference. Consequently, the caller (ethernet_send) proceeds to perform post-transmission operations, including reading net_pkt_get_len(pkt) and updating TX statistics, while operating on memory that has already been deallocated and potentially reclaimed. This constitutes a classic use-after-free (UAF) condition.\nThe exploitation flow is triggered by network activity. An attacker on the local WiFi network can induce transmissions (e.g., through ICMP echo requests or TCP handshakes) that force the stack to process packets using this flawed driver path. If the network stack recycles the freed memory slot for a different packet before the kernel executes its own mandatory net_pkt_unref(pkt) in the caller function, the second 'unref' will decrement the reference count of the newly allocated, legitimate packet. This secondary unref results in a double-free, corrupting the reference counter of the active, recycled memory slot.\nThe post-exploitation impact is severe. Because the networking subsystem relies on a shared pool of buffers for both ingress and egress traffic, corrupting these descriptors leads to non-deterministic failures. Active network streams may be prematurely dropped, or the kernel may experience a panic due to invalid memory states when the corrupted reference count causes a live buffer to be released. In a production environment, this facilitates a reliable denial-of-service attack against the embedded device by simply flooding the device with unsolicited valid network traffic, thereby depleting or corrupting the heap/slab management structures responsible for network I/O."
}