Improper input validation in the beacon handler for WF200 firmware versions 3.17.0 and earlier may result in a divide-by-zero fault.

In Z-Wave SDK 8.1.1 and earlier, a malformed NCP SPI command can trigger out-of-bounds reads that leak sensitive information.

In Z-Wave SDK 8.1.1 and earlier (for 700/800 series devices) and 6.85.02 and earlier (for 500 series devices), missing checks in the ZWAVECMDNODESEXIST handler can result in nodes being removed from the network. These messages must come from a device that has already joined the network.

In EmberZNet 9.1.1 and earlier, a malformed SimpleDescreq response can result in an out-of-bounds write potentially leading to remote code execution. This response must come from a device that has already joined the network, and the attacker must wait for a SimpleDescreq before the attack can be performed.

In EmberZNet 9.1.1 and earlier, a malformed Publish Price Matrix command can result in an out-of-bounds write potentially leading to remote code execution. These messages must come from a device that has already joined the network. Only devices supporting the Price Cluster are impacted.

In EmberZNet 9.1.1 and earlier, a malformed Publish Billing Period command can result in a recursive function call that will never reach its end condition. These messages must come from a device that has already joined the network. Only devices supporting the Price Cluster are impacted.

In EmberZNet 9.1.1 and earlier, a malformed Discover Attributes command can result in a loop with unreachable exit condition (infinite loop). These messages must come from a device that has already joined the network. Only devices supporting manufacturer-specific clusters are impacted.

In EmberZNet 9.1.1 and earlier, a malformed GetGroupMembership message can result in an out-of-bounds write leading to a crash. A limited number of values can be written using this vulnerability, so no route to remote code execution was observed. These messages must come from a device that has already joined the network. Only devices supporting the Group Cluster are impacted.

In the silabser.sys driver for CP210x devices v11.5.0 and earlier, a local unprivileged user with a malicious device can use malformed packets to corrupt kernel pool memory, resulting in arbitrary code execution with escalated privileges.

In the silabser.sys driver for CP210x devices v11.5.0 and earlier, a local unprivileged user with a malicious device can use malformed packets to leak up to 145 bytes of uninitialized kernel pool memory. This vulnerability affects Windows 10 and earlier.

The Silicon Labs SiWx917 WiFi driver's transmit callback siwx91xsend() in drivers/wifi/siwx91x/siwx91xwifi.c frees a network packet it does not own. In the Zephyr TX path the netpkt is owned by the L2/networking stack; the driver only borrows it to copy the frame bytes into a local netbuf. Before the fix, after transmitting, siwx91xsend() additionally called netpktunref(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 (CONFIGWIFISILABSSIWX91XNETSTACKNATIVE).

The caller, ethernetsend() in subsys/net/l2/ethernet/ethernet.c, keeps using the packet after the driver returns: it reads netpktgetlen(pkt), updates TX statistics, and then performs its own netpktunref(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 netpkt 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 netpktunref(pkt) from siwx91xsend(); the driver's receive-path unref, which correctly frees a packet the driver itself allocated, is unaffected.

The Silicon Labs SiWx917 WiFi driver's transmit callback siwx91xsend() in drivers/wifi/siwx91x/siwx91xwifi.c frees a network packet it does not own. In the Zephyr TX path the netpkt is owned by the L2/networking stack; the driver only borrows it to copy the frame bytes into a local netbuf. Before the fix, after transmitting, siwx91xsend() additionally called netpktunref(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 (CONFIGWIFISILABSSIWX91XNETSTACKNATIVE).

The caller, ethernetsend() in subsys/net/l2/ethernet/ethernet.c, keeps using the packet after the driver returns: it reads netpktgetlen(pkt), updates TX statistics, and then performs its own netpktunref(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 netpkt 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 netpktunref(pkt) from siwx91xsend(); the driver's receive-path unref, which correctly frees a packet the driver itself allocated, is unaffected.

A bug in the entropy initialization for SiWx917 causes the DRBG to use a predictable seed. As such, all random numbers generated in the Matter code use the same stream of numbers. This vulnerability was discovered after the impacted repository was already deprecated.

Improper bounds validation in EmberZNet SDK versions 9.0.2 and earlier may result in crashes or dynamic memory leakage.

In EmberZNet v9.0.2 and earlier, malformed ClearWeekdaySchedule messages can trigger out-of-bounds writes into Door Lock schedule state. The size and location of this data is limited. These messages must come from a device that has already joined the network. Only devices supporting the Door Lock cluster may be impacted.

An integer underflow vulnerability in Silicon Labs Secure NCP host implementation allows a buffer overread via a specially crafted packet.

An integer underflow vulnerability is present in Silicon Lab’s implementation of PSA Crypto and SE Manager EC-JPAKE APIs during ZKP parsing. Triggering the underflow can lead to a hard fault, causing a temporary denial of service.

A reachable infinite loop via an integer wraparound is present in Silicon Labs' Matter SDK which allows an attacker to trigger a denial of service. A hard reset is required to recover the device.

DPA countermeasures in Silicon Labs' Series 2 devices are not reseeded under certain conditions.

This may allow an attacker to eventually extract secret keys through a DPA attack.

An integer underflow vulnerability in the Silicon Labs Z-Wave Protocol Controller can lead to out of bounds memory reads.

When a WF200/WGM160P device is configured to operate as an Access Point, it may be vulnerable to a denial of service triggered by a malformed packet. The device may recover automatically or require a hard reset.

The web interface of the Silicon Labs Simplicity Device Manager is exposed publicly and can be used to extract the NTLMv2 hash which an attacker could use to crack the user's domain password.

When SmartStart Inclusion fails during the onboarding of a Z-Wave PIR sensor, the sensor will join the network as a non-secure device. This vulnerability exists in Silicon Labs' Z-Wave PIR Sensor Reference design delivered as part of SiSDK v2025.6.0 and v2025.6.1.

A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host system (CPCd) due to heavy Zigbee traffic, resulting in a Denial of Service (DoS) attack, Only hard reset will bring the device to normal operation

In high traffic environments, a Silicon Labs OpenThread RCP (see impacted versions) fails to clear the SPI transmit buffer and may send a corrupt packet over SPI to its host,  causing the host to reset the RCP which results in a denial of service.

The following APIs for the Silcon Labs SiWx91x prior to vesion 3.4.0 failed to check the size of the output buffer of the caller which could lead to data corruption on the host (Cortex-M4) application.

slsi91xaes slsi91xgcm slsi91xccm slsi91xsha

Silicon Labs Gecko OS HTTP Request Handling Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Silicon Labs Gecko OS. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the handling of HTTP requests. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the device. Was ZDI-CAN-23245.

The DPA countermeasures on Silicon Labs' Series 2 devices are not reseeded periodically as they should be. This may allow an attacker to eventually extract secret keys through a DPA attack.

A buffer overread can occur in the CPC application when operating in full duplex SPI upon receiving an invalid packet over the SPI interface.

This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Silicon Labs Gecko OS. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the debug interface. The issue results from the lack of proper validation of a user-supplied string before using it as a format specifier. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device.