CVE-2026-14366 in Zephyr
Summary
by MITRE • 08/31/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability in question resides within the Silicon Labs SiWx917 WiFi driver implementation for the Zephyr operating system, specifically affecting the transmit callback function siwx91x_send located in drivers/wifi/siwx91x/siwx91x_wifi.c. This flaw represents a critical memory management error where the driver incorrectly assumes ownership of network packet buffers that it does not actually own. In the standard Zephyr transmission path, the net_pkt structure is owned by the Layer 2 networking stack and is merely borrowed by the device driver for the purpose of copying frame bytes into a local net_buf buffer. The fundamental technical flaw occurs after the data has been successfully transmitted to the hardware; instead of simply returning control to the caller, the siwx91x_send function erroneously invokes net_pkt_unref on the packet pointer. This action prematurely drops the reference count held by the networking stack, causing the kernel to return the memory slab back to the shared packet pool while it is still in active use by higher-level network subsystems.
The operational impact of this defect manifests as a severe use-after-free condition coupled with a double free vulnerability within the kernel space. The caller function ethernet_send, located in subsys/net/l2/ethernet/ethernet.c, continues to interact with the net_pkt structure immediately after the driver returns from siwx91x_send. Specifically, it reads the packet length via net_pkt_get_len and updates transmission statistics before performing its own legitimate call to net_pkt_unref to release ownership back to the pool. Because the driver has already freed the memory in between these operations, any subsequent access by ethernet_send constitutes a use-after-free read of potentially invalid or recycled memory. More critically, when ethernet_send subsequently calls unref on an already-freed object, it triggers a double free scenario. This sequence is particularly dangerous because network traffic can be highly concurrent and rapid, creating tight timing windows where the race condition becomes exploitable under normal operating conditions rather than requiring exotic stress tests to trigger.
The security implications extend beyond simple application crashes or denial of service due to transmit hangs. When an adjacent attacker on the same WiFi network induces transmissions such as ARP requests, ICMP echo replies, or TCP handshake packets, they can drive this vulnerable code path repeatedly. If the freed slab slot is recycled by another thread or interrupt context between the driver's erroneous unref and the caller's subsequent operations, the second unref may decrement the reference count of a completely different, live packet object. This leads to memory corruption within the net_pkt pool shared by both receive and transmit paths. Such heap corruption can destabilize the entire networking stack, potentially leading to kernel panics or system reboots, thereby causing a significant loss of availability for any device relying on this WiFi interface. In terms of industry standards, this vulnerability aligns with CWE-416 Use After Free and CWE-415 Double Free, which are categorized as high-severity memory safety issues that compromise the integrity and reliability of system resources.
From an attack perspective, while direct code execution via heap corruption is theoretically possible depending on allocator behavior and kernel hardening features like KASLR or stack canaries, the most immediate and reliable impact observed is denial of service through pool exhaustion or structural corruption leading to crashes. The vulnerability falls under ATT&CK technique T1499 Endpoint Denial of Service, as an attacker with local network access can degrade system availability without needing elevated privileges on the host itself. Mitigation strategies primarily involve applying the upstream patch that removes the erroneous net_pkt_unref call from siwx91x_send. Developers must ensure that drivers only release resources they explicitly allocated or were granted ownership of via explicit transfer mechanisms, adhering to strict resource management protocols defined in secure coding standards such as CWE-754 Improper Check for Unusual or Exceptional Conditions and CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization. Maintaining up-to-date driver versions is essential to prevent exploitation by local network adversaries seeking to disrupt service availability through memory corruption attacks.