Vulnerability feed
CVE and vendor PSIRT advisories from 13 sources, last 30 days. Updated hourly, last run
| Expand | Severity |
Score |
Advisory |
Title |
Source |
Flags |
Published |
|---|---|---|---|---|---|---|---|
| High | 8.8 | CVE-2026-79982 |
The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/device_next/class/bt_hci.c, copies every controller-to-host HCI packet into a USB transfer buffer...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79982The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/device_next/class/bt_hci.c, copies every controller-to-host HCI packet into a USB transfer buffer...
Executive summaryA flaw in the Bluetooth HCI USB transport class of the new USB device stack can let a nearby attacker overflow a memory buffer on affected devices. The advisory says it can cause a remote crash, and on production builds without memory protection it can potentially lead to arbitrary code execution. The advisory does not state a fixed version, and the fix described is a separate, larger buffer pool for the controller-to-host direction. Technical summaryThis is a buffer overflow (CWE class not stated) in subsys/usb/device_next/class/bt_hci.c, where HCI packets are copied into fixed 64-byte USB pool slots with no length check via net_buf_add_mem(). Attack preconditions include a Bluetooth-range attacker, with a connected peer using Data Length Extension or broadcasting extended advertising data, and the advisory notes the overflow is also reached on every host initialization in the stock configuration through a 70-byte Read Supported Commands event. With CONFIG_ASSERT=n and CONFIG_NET_BUF_HARDENING disabled, memory corruption may occur; with assertions enabled, the device panics. The advisory describes a fix that adds a bt_hci_tx_pool sized to MAX(BT_BUF_ACL_RX_SIZE, BT_BUF_EVT_RX_SIZE). Affected and fixed version numbers are not stated, and no workaround or detection guidance is stated beyond the configuration options discussed. CVSS score and exploitation status are not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Zephyr Zephyr Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.5 | CVE-2026-79981 |
The DNS stub resolver in subsys/net/lib/dns/resolve.c binds one UDP socket per configured server when the resolver context is initialised (dns_resolve_init_locked() ->...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79981The DNS stub resolver in subsys/net/lib/dns/resolve.c binds one UDP socket per configured server when the resolver context is initialised (dns_resolve_init_locked() ->...
Executive summaryThe advisory says the DNS stub resolver in an embedded networking stack reuses one source UDP port for all queries, which lets an attacker on the same network segment or with UDP reachability to the device race forged DNS replies and make an application resolve an attacker-chosen address. The advisory describes the flaw as allowing redirection of name resolution, but it does not state a severity score. The fix randomizes the source port per query, and the advisory describes it as controlled by a configuration option that defaults to enabled. Technical summaryThe flaw is a weak-randomness issue in DNS query matching, where the resolver keeps a constant UDP source port for its lifetime so only the 16-bit transaction identifier varies, contrary to RFC 5452 section 9.2. The advisory says the reply source address is never checked, so forged replies need only reach the resolver's port and win a race against the legitimate server. Preconditions are UDP reachability to the device, such as the same LAN or a globally routable address, and winning the race during a query window; the advisory notes TLS certificate validation largely protects applications. Affected versions are not stated, and no fixed version is given; the fix is described as dns_randomize_source_port() with CONFIG_DNS_RESOLVER_RANDOMIZE_SOURCE_PORT defaulting to y. No workaround beyond that configuration is stated, and no detection guidance is stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityNone
How it is exploited
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.6 | CVE-2026-79980 |
The DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c maintained its transaction identifier (iface->config.dhcpv4.xid) as a counter rather than as a per-transaction random value
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79980The DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c maintained its transaction identifier (iface->config.dhcpv4.xid) as a counter rather than as a per-transaction random value
Executive summaryThe DHCPv4 client in Zephyr's networking subsystem can be fooled by forged DHCP replies because its transaction identifier is predictable and reused. The advisory says an attacker on the same network, or a DHCP server the device previously joined, could redirect the device's default gateway and DNS resolvers. The advisory does not state a severity score; the vendor fix changes how the identifier is generated. Technical summaryThe flaw is a predictable transaction identifier (xid) in the DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c, which is treated as a counter instead of a fresh random value per transaction, so an observed xid stays valid for the device's uptime. The attack requires only that the attacker learn one xid, for example by seeing the broadcast DHCPDISCOVER, since the reply checks cover op, xid and chaddr (public MAC) and the UDP callback accepts any remote address and port. A single accepted forged reply can change the default gateway and DNS resolvers through option processing that runs before the state gate, and a forged DHCPACK or DHCPNAK can alter the lease during RENEWING or REBINDING. The advisory states the fixed version is not stated, no workaround is stated, and no detection guidance is stated; the fix draws fresh sys_rand32_get() values when transactions begin. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Zephyr Project Zephyr Impact if exploitedConfidentialityLow IntegrityLow AvailabilityLow
How it is exploited
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.8 | CVE-2026-79979 |
The arm64 MMU backend invalidates a single virtual address from the TLB with invalidate_tlb_page() in arch/arm64/core/mmu.c, which issued TLBI VAE1{IS} with an operand of virt...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79979The arm64 MMU backend invalidates a single virtual address from the TLB with invalidate_tlb_page() in arch/arm64/core/mmu.c, which issued TLBI VAE1{IS} with an operand of virt...
Executive summaryThe advisory describes a flaw in the arm64 memory management code of a system that uses memory domains and demand paging. An unprivileged user thread could keep access to a physical memory page after it was reclaimed and reused, potentially reading or changing kernel data or other threads' memory. The advisory does not state a severity score, and the fix is a code change that switches the cache invalidation instruction to one that clears all matching entries. Technical summaryThe root cause is that invalidate_tlb_page() issued a TLBI VAE1 operation with an operand that encoded only ASID 0, so stale non-global translations for user memory domains were not removed when a demand-paged frame was evicted. This is a stale translation (use-after-reclaim) class issue, reachable from unprivileged code in a user thread that drives memory pressure to force eviction. Preconditions are an arm64 build with CONFIG_USERSPACE and CONFIG_DEMAND_PAGING enabled, an active backing store, and a demand-paged page privately mapped into a user memory domain. The fix uses TLBI VAAE1{IS}, and the advisory also stops globalize_table() from stripping EL0 permissions during paging synchronization. Affected and fixed version numbers are not stated, and no workaround is stated. No detection guidance is stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Low | 3.6 | CVE-2026-79978 |
The RTIO streaming completion callback adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c clamps the amount of FIFO data it will report (read_len...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79978The RTIO streaming completion callback adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c clamps the amount of FIFO data it will report (read_len...
Executive summaryA flaw in the Zephyr-style ADXL345 accelerometer streaming driver can cause the driver to write sensor data past the end of a memory buffer when the buffer pool is short on space. The advisory says the result is silent corruption of other data or a crash, and it is reached only through local conditions on boards with this sensor and streaming enabled. The advisory does not state a fix or a vendor recommendation. Technical summaryThis is an out-of-bounds write (buffer overflow) in adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c, where the number of queued 6-byte FIFO reads is bounded by the device entry count rather than the clamped buffer length, writing up to 186 bytes past an undersized allocation. A second defect leaves data->fifo_total_bytes unreset at batch start, so a stale offset after an aborted chain can cause further out-of-bounds writes. Preconditions are an interrupt-wired ADXL345, CONFIG_ADXL345_STREAM enabled, and RTIO block pool starvation or fragmentation, which can be induced by a co-resident local workload. The advisory states there is no network, USB or radio attack path. Affected and fixed version numbers are not stated, and no workaround or detection guidance is given. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Zephyr Project Zephyr Dropped extracted product not named in the source: Analog Devices ADXL345 Impact if exploitedConfidentialityNone IntegrityLow AvailabilityLow
How it is exploited
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 8.2 | CVE-2026-79977 |
The WireGuard VPN service in subsys/net/lib/wireguard/wg.c updated the peer endpoint from a message it could not authenticate
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79977The WireGuard VPN service in subsys/net/lib/wireguard/wg.c updated the peer endpoint from a message it could not authenticate
Executive summaryThe advisory says the WireGuard VPN service in subsys/net/lib/wireguard/wg.c can be made to send tunnel traffic to an address chosen by an attacker, because it accepts an unauthenticated message and updates the peer endpoint from it. A single spoofed UDP packet sent to the default port 51820 can persistently break the tunnel and let an attacker sit in its path, though the advisory states that encryption still prevents decryption or forgery of content. The advisory does not state a severity score, and it describes a fix that stops learning endpoints from unauthenticated messages. Technical summaryThe flaw is classified as the update of a peer endpoint from an unauthenticated message. In handle_transport_data(), a transport-data message whose 32-bit receiver index matches no session causes a new handshake to be scheduled and the datagram source address to be copied into peer->endpoint with memcpy. The listener has no remote address or port filter and defaults to UDP port 51820, so an off-path host can send a 16-byte spoofed datagram, and the vulnerable branch runs when the peer has no valid handshake or current keypair, such as at boot or after a session expires. The advisory states that the impact is loss of availability and limited confidentiality of metadata, not key compromise. Affected and fixed version numbers are not stated, and no CVSS score, workaround, or detection guidance is stated. The advisory describes the fix as keeping stale-session recovery while sending handshakes only to an endpoint learned from an authenticated message or the configured cfg_endpoint, and it notes CONFIG_WIREGUARD is marked experimental and not enabled by default. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.5 | CVE-2026-19741 |
Zephyr's OpenThread integration defined CONFIG_OPENTHREAD_JOINER_PSKD with default "J01NME" in modules/openthread/Kconfig.thread (previously subsys/net/l2/openthread/Kconfig,...
zephyrproject, Zephyr, OpenThreadzephyrproject zephyr, Zephyr, OpenThread
|
NVD | |||
|
CVE-2026-19741Zephyr's OpenThread integration defined CONFIG_OPENTHREAD_JOINER_PSKD with default "J01NME" in modules/openthread/Kconfig.thread (previously subsys/net/l2/openthread/Kconfig,...
Executive summaryThe advisory says Zephyr's OpenThread integration shipped a publicly known default joining credential, "J01NME", that could let an unauthenticated attacker within radio range take over commissioning of an uncommissioned device. The advisory describes the consequence as a device joining an attacker-controlled network and remaining mis-provisioned until reset. The fix removes the default and requires a per-device credential, and the advisory recommends provisioning a unique credential per device from factory data. The advisory does not state a severity score. Technical summaryThis is a use of a hardcoded or publicly known default credential (CONFIG_OPENTHREAD_JOINER_PSKD defaulting to "J01NME") in the Thread commissioning handshake. The attack requires an attacker within 802.15.4 radio range of an uncommissioned device, such as one that is factory-fresh, freshly reset, or had its settings erased, and that is built with CONFIG_OPENTHREAD_JOINER_AUTOSTART=y without overriding the PSKd. The attacker can run a stock commissioner with that credential, complete the DTLS-PSK handshake, and supply a malicious operational dataset. The advisory states the option is not enabled by default and no in-tree sample uses the vulnerable combination. Affected and fixed version numbers are not stated, and no CVSS score, workaround beyond overriding the PSKd, or detection guidance is stated. The fix adds a BUILD_ASSERT() requiring a 6-to-32-character PSKd when joiner autostart is enabled. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H AffectszephyrprojectZephyrOpenThreadzephyrproject zephyrZephyrOpenThread
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.1 | CVE-2026-79976 |
The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-79976The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number...
Executive summaryThe advisory describes a flaw in the MCTP-over-I2C+GPIO target binding of a firmware subsystem. Any device able to act as bus controller on the shared management bus could crash or halt an affected target, causing a denial of service, and the impact is limited to availability. The advisory does not state a CVSS score or a fixed version, and it says the fix resets stale state at every I2C STOP, which is the vendor-side change described. Technical summaryThe flaw is a stale-state issue (CWE class not stated) in subsys/pmci/mctp/mctp_i2c_gpio_target.c, where the selected register and data-phase flag persist after an I2C STOP and can refer to a packet buffer already freed and set to NULL. A bus controller needs only two ordinary, unauthenticated transactions: a packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP, then a bare read followed by STOP, which leads to a NULL packet being passed to mctp_bus_rx(). On targets that trap accesses to address 0 this causes a fatal exception and reset or halt; on targets where address 0 is readable, malformed buffers and lost transmit packets result. The advisory describes a symmetric transmit-side issue involving MCTP_I2C_GPIO_TX_MSG_ADDR. The fix resets b->reg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b->rxtx at every STOP. Only builds with the experimental CONFIG_MCTP subsystem and CONFIG_MCTP_I2C_GPIO_TARGET=y are affected. Affected and fixed version numbers are not stated, and no workaround or detection guidance is stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-78119 |
The Nuvoton NPCX eSPI driver parses Target-Attached-Flash (TAF) requests in espi_taf_parse() (drivers/espi/espi_npcx.c), taking the 12-bit length field directly out of the...
zephyrproject, Nuvotonzephyrproject zephyr, Nuvoton NPCX eSPI driver
|
NVD | |||
|
CVE-2026-78119The Nuvoton NPCX eSPI driver parses Target-Attached-Flash (TAF) requests in espi_taf_parse() (drivers/espi/espi_npcx.c), taking the 12-bit length field directly out of the...
Executive summaryA flaw in the Nuvoton NPCX eSPI driver, used for Target-Attached-Flash handling on NPCX and NPCK microcontrollers, allows an oversized flash request from the eSPI host to write past a fixed-size buffer in controller memory. The advisory says this can crash or hang the controller or corrupt driver state that controls flash protection regions, and it is only reachable by host firmware or bus-level control. The advisory describes a code fix that rejects oversized requests, but it does not state any affected or fixed version numbers. Technical summaryThe vulnerability is a buffer overflow caused by an unvalidated 12-bit length field in espi_taf_parse() in drivers/espi/espi_npcx.c, where a uint8_t counter can drive up to 255 copy iterations into a fixed 16-word (64-byte) structure member. The advisory says the overflow can write about 956 bytes past the end of the structure into .bss and can also cause out-of-bounds reads and a flash write of up to 4 KB of adjacent SRAM, and a related four-byte stack overflow exists in taf_npcx_completion_handler() on SoCs with tx-plsize of 64. The attack requires an eSPI host that sends a request violating the negotiated rx-plsize, and only configurations with CONFIG_ESPI_TAF enabled are affected. The advisory describes the fix as widening the counters, rejecting oversized word counts, adding an invalid_flag path, bounding the transmit payload, and adding a default case for unsupported cycle types. Affected version numbers, fixed version numbers, CVSS score, and in-the-wild exploitation status are not stated, and no detection guidance is given. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H AffectszephyrprojectNuvotonzephyrproject zephyrNuvoton NPCX eSPI driver
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.0 | CVE-2026-78118 |
The kernel helper z_waitq_head() (kernel/include/wait_q.h) reads the head of a thread wait queue, but on SMP systems it was called from several places without holding the...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-78118The kernel helper z_waitq_head() (kernel/include/wait_q.h) reads the head of a thread wait queue, but on SMP systems it was called from several places without holding the...
Executive summaryA race condition in the Zephyr kernel's thread wait queue handling affects multi-CPU builds, where a local user-mode thread may be able to corrupt kernel memory. The advisory describes the most likely result as a kernel crash, with controlled corruption less likely. The advisory does not state a CVSS score or a fixed release version. Technical summaryThe flaw is a race in the kernel helper z_waitq_head(), which reads a thread wait queue head without holding the scheduler spinlock on SMP systems. In z_timer_expiration_handler() the head is read under only timer_lock, while halt_thread() removes waiters under only _sched_spinlock, so a removal on another CPU can leave the handler with a list sentinel or a stale or freed thread pointer, leading to out-of-bounds or use-after-free writes in supervisor context. Exploitation requires CONFIG_MP_MAX_NUM_CPUS greater than one, local code execution, and winning a narrow timing window, and with CONFIG_USERSPACE an unprivileged thread can attempt it using system calls such as k_timer_start() and k_thread_abort(). The advisory states the fix splits the helper into z_waitq_head_locked() and a locking z_waitq_head(), and brings the timer handler under LOCK_SCHED_SPINLOCK. Affected and fixed version numbers, workarounds, and detection guidance are not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Zephyr Project Zephyr Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 4.2 | CVE-2026-78117 |
The Infineon PSOC 6 BLESS HCI driver in drivers/bluetooth/hci/hci_infineon_psoc6_bless.c stored the outgoing HCI packet descriptor in a file-scope variable, static...
zephyrproject, Infineonzephyrproject zephyr, Infineon PSOC 6 BLESS HCI driver
|
NVD | |||
|
CVE-2026-78117The Infineon PSOC 6 BLESS HCI driver in drivers/bluetooth/hci/hci_infineon_psoc6_bless.c stored the outgoing HCI packet descriptor in a file-scope variable, static...
Executive summaryA flaw in the Infineon PSOC 6 BLESS Bluetooth HCI driver for Linux can cause concurrent transmissions to share a single packet descriptor, which may leak nearby device memory contents to a connected Bluetooth peer. The advisory describes the impact as information disclosure and link disruption, with no memory corruption or code execution. The advisory does not state a severity score, and it does not describe a vendor-issued fixed release, only the code change that removes the shared state. Technical summaryThis is a race condition (concurrent access to shared state without adequate locking) in the driver's TX path, where a file-scope HCI packet descriptor is populated before the serialising semaphore is acquired. The condition is reached when the Bluetooth host sends HCI traffic from a second thread, such as through the ACL buffer destroy callback when an application uses -EINPROGRESS and bt_l2cap_chan_recv_complete(), and a remote peer generating traffic raises the collision rate. The result can be disclosure of adjacent RAM up to a full HCI/ACL payload to the connected peer, or duplicated and dropped HCI packets. The advisory states that the driver only reads through the shared descriptor and that the disclosed bytes are not attacker-chosen. Affected and fixed version numbers are not stated, and no workaround is stated beyond the code fix that makes the descriptor a local variable. No detection guidance is given. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityLow
How it is exploited
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L AffectszephyrprojectInfineonzephyrproject zephyrInfineon PSOC 6 BLESS HCI driver
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.2 | CVE-2026-78116 |
The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails
zephyrproject, Broadcomzephyrproject zephyr, Broadcom AFBR-S50
|
NVD | |||
|
CVE-2026-78116The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails
Executive summaryA bug in the Broadcom AFBR-S50 time-of-flight sensor driver can corrupt memory in devices that use this sensor, causing crashes or loss of availability. The advisory says an attacker in front of the sensor could trigger the fault with light conditions, though the attacker does not control the corrupted content. The advisory does not state a severity score or a fixed version, and it does not give vendor recommendations beyond the description of the fault. Technical summaryThe driver's data_ready_work_handler() in drivers/sensor/broadcom/afbr_s50/afbr_s50.c completes the same RTIO submission twice when Argus_EvaluateData() returns a non-OK status, because the error branch does not return. This double completion frees and reuses a submission pool entry, corrupts the mpsc submission queue, and can write through a released buffer, which the advisory describes as memory corruption and loss of availability rather than code execution. The fault is triggered by sensor conditions such as harsh ambient light or sharp distance transitions, and SPI transfer errors reach the same branch, so no physical or software access is required per the advisory. Affected and fixed versions are not stated, and no workaround is stated. The advisory does not give detection guidance. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityNone IntegrityLow AvailabilityHigh
How it is exploited
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.3 | CVE-2026-19947 |
The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set()
zephyrproject, Zephyrzephyrproject zephyr, Zephyr
|
NVD | |||
|
CVE-2026-19947The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set()
Executive summaryA flaw in the Zephyr device multiplexer pseudo-driver lets any thread running in user mode read and change which downstream device the multiplexer forwards to, without the access check that should apply. The advisory says an attacker could suppress console, log, or shell output, or redirect that output to a device they can observe. The advisory describes the fix as adding the missing kernel object tracking and access checks; no CVSS score or workaround is stated. Technical summaryThis is an authorization flaw (missing object permission check) in the devmux syscall verifiers in drivers/misc/devmux/devmux.c, not a memory-safety issue, because the kernel implementations validate the device pointer and selection index. The affected verifiers, z_vrfy_devmux_select_get() and z_vrfy_devmux_select_set(), forward to the kernel without k_object_access_check(), and devmux instances registered with a NULL driver API are skipped by gen_kobject_list.py, so they have no kernel object. Exploitation requires a user-mode thread, CONFIG_USERSPACE=y, the experimental CONFIG_DEVMUX=y (which depends on CONFIG_DEVICE_MUTABLE), and a zephyr,devmux devicetree node. The advisory does not state affected or fixed version numbers, and it does not state a workaround or any detection guidance. The fix adds DEVICE_API(devmux, devmux_api) instances and K_OOPS checks to both verifiers. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityLow AvailabilityLow
How it is exploited
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.8 | CVE-2026-19676 |
The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission and copied the...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-19676The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission and copied the...
Executive summaryA flaw in the PECI transfer interface of the Zephyr real-time operating system lets a user-mode application escape into the kernel. The advisory says an attacker with local code execution in a user-mode thread that holds the PECI device could gain supervisor-level control, read kernel memory, or crash the system, when specific PECI drivers and user-space support are enabled. The advisory describes the fix as adding memory checks to the affected system call; it does not state a severity score or the fixed release version. Technical summaryThe vulnerability is a missing input validation issue in the user-mode verifier z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, which checks only device object permission and does not validate the buf pointers and len values inside the embedded peci_buf structures. The three in-tree PECI drivers (npcx, it8xxx2, and mchp_xec) then read from or write to those caller-controlled addresses in supervisor mode, enabling an arbitrary kernel write, an arbitrary kernel read exposed on the PECI bus, and a supervisor-mode fault on unmapped addresses. Preconditions are CONFIG_USERSPACE=y, one of CONFIG_PECI_NPCX, CONFIG_PECI_XEC, or CONFIG_PECI_ITE_IT8XXX2 enabled, and local code execution in a user-mode thread holding the PECI device. The advisory does not state affected or fixed version numbers, a CVSS score, workarounds, or exploitation in the wild, and it gives no detection guidance. The described fix adds K_SYSCALL_MEMORY_READ() and K_SYSCALL_MEMORY_WRITE() checks plus a size_add_overflow() guard on the frame-check-sequence byte. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Zephyr Zephyr Dropped extracted product not named in the source: Zephyr PECI npcx driver Dropped extracted product not named in the source: Zephyr PECI it8xxx2 driver Dropped extracted product not named in the source: Zephyr PECI XEC driver Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Low | 3.5 | CVE-2026-18748 |
The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array
zephyrproject, Bluetoothzephyrproject zephyr, Bluetooth Classic A2DP host
|
NVD | |||
|
CVE-2026-18748The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array
Executive summaryA flaw in the Bluetooth Classic A2DP host component can let a paired Bluetooth device read a bounded region of nearby memory on the affected device. The advisory describes this as an information disclosure issue, and it does not state a severity score. The advisory describes a fix that makes the length limit configurable and rejects oversized codec data, but it does not state a fixed version number. Technical summaryThe vulnerability is an out-of-bounds read caused by a length field that is not reconciled with a fixed 8-byte codec Information Element buffer in struct bt_a2dp_codec_ie. When an AVDTP peer sends a longer codec IE in SET_CONFIGURATION, only 8 bytes are copied but the full length is stored, and later GET_CONFIGURATION responses read up to about 245 bytes past the array and send them to the peer. Exploitation requires CONFIG_BT_CLASSIC and CONFIG_BT_A2DP, a peer that has completed pairing, and a local endpoint registered for a non-SBC codec, although the bt_a2dp_get_config_cb() path has no such gate. The advisory states there is no out-of-bounds write. Affected version numbers are not stated, fixed version numbers are not stated, and no workaround is stated beyond the described fix. Detection guidance is not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityNone
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N AffectszephyrprojectBluetoothzephyrproject zephyrBluetooth Classic A2DP host
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.7 | CVE-2026-77684 |
The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-77684The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when...
From the advisoryThe Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when the RFCOMM DLC goes down. hfp_hf_disconnected() only cancelled the work items and cleared hf->acl, and no other code path ever dequeues those buffers, so each one is permanently lost from the fixed hf_pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. two in the default configuration). The same function also left BT_HFP_HF_FLAG_CONNECTED set, and hfp_hf_create() wiped the object with memset() as soon as hf->acl was NULL, without checking whether hf->work, hf->slc_work or hf->deferred_work was still pending or running. The remote Audio Gateway peer controls the trigger end to end and needs no application involvement: an unsolicited +BCS: 1 response makes bcs_handle() call bt_hfp_hf_select_codec() and queue an AT+BCS buffer, which cannot be transmitted while BT_HFP_HF_FLAG_RX_ONGOING is set, and an immediately following RFCOMM DISC strands that buffer. Repeating the connect / +BCS / disconnect cycle a couple of times empties hf_pool for good. With the pool exhausted, HFP command sending fails permanently, and because hfp_hf_send_cmd() allocates with K_FOREVER (bt_rfcomm_create_pdu() → bt_conn_create_pdu()) from the Bluetooth RX context — where that timeout is not downgraded to K_NO_WAIT — one further +BCS from the peer parks the Bluetooth RX thread inside net_buf_alloc() with no possible waker, halting all HCI event processing until the device is rebooted. Separately, reusing the HF slot while a work handler was still queued or running allowed memset() to wipe live k_work items out from under the system workqueue, corrupting shared kernel workqueue state. Exploitation requires an established HFP session (for SSP devices L2CAP enforces authentication before the RFCOMM channel is reachable) and a build with CONFIG_BT_HFP_HF enabled. Impact if exploitedConfidentialityNone IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.1 | CVE-2026-19595 |
The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-19595The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with...
From the advisoryThe user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with K_SYSCALL_MEMORY_READ() rather than K_SYSCALL_MEMORY_WRITE(). Both are pure out-parameters: z_impl_rtio_cqe_get_mempool_buffer() stores the mempool buffer address and its length through them. The distinction is enforced by every architecture validator — arch_buffer_validate() on RISC-V PMP explicitly accepts the global __rom_region/__rodata_region for reads only, and the ARM MPU validators accept P_RO_U_RO and P_RW_U_RO regions for reads only — so a read-validated pointer is not necessarily writable by the calling thread. An unprivileged user-mode thread that has been granted access to an RTIO context (rtio_access_grant()) can invoke the rtio_cqe_get_mempool_buffer() syscall with buff/buff_len pointing at memory it may read but not write, and with a completion-queue entry whose flags field it fully controls (only RTIO_CQE_FLAG_MEMPOOL_BUFFER in flags[7:0] is required; flags[19:8] and flags[31:20] supply the block index and count). The kernel then performs a pointer-sized and a 4-byte store through those addresses while running in supervisor mode. Reaching the store requires CONFIG_USERSPACE together with CONFIG_RTIO_SYS_MEM_BLOCKS, the configuration behind RTIO_DEFINE_WITH_MEMPOOL; without the latter the implementation returns -ENOTSUP and writes nothing. Two outcomes follow. If the target lies in a memory-domain partition declared K_MEM_PARTITION_P_RW_U_RO (privileged read-write, user read-only), the kernel-mode store succeeds and deposits partly attacker-chosen values into memory the memory domain had marked read-only for that thread, bypassing the partition's write protection. If the target lies in globally readable but unwritable memory such as .text/.rodata in flash, the store faults in kernel mode; the fault is delivered to z_fatal_error() and the default k_sys_fatal_error_handler() halts or reboots the device, giving an unprivileged thread a reliable full denial of service. The read-permission check does bound the damage: the address must still be readable by the calling thread, so kernel-private memory cannot be targeted and no confidential data is disclosed. The fix replaces both checks with K_SYSCALL_MEMORY_WRITE(), so a thread lacking write permission is terminated by K_OOPS before the implementation runs; the cqe argument correctly remains read-validated. Impact if exploitedConfidentialityNone IntegrityLow AvailabilityHigh
How it is exploited
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 8.8 | CVE-2026-76788 |
The OSDP Control Panel reply parser cp_decode_response() in subsys/mgmt/osdp/src/osdp_cp.c decodes replies from a Peripheral Device into a stack-allocated struct osdp_event
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-76788The OSDP Control Panel reply parser cp_decode_response() in subsys/mgmt/osdp/src/osdp_cp.c decodes replies from a Peripheral Device into a stack-allocated struct osdp_event
From the advisoryThe OSDP Control Panel reply parser cp_decode_response() in subsys/mgmt/osdp/src/osdp_cp.c decodes replies from a Peripheral Device into a stack-allocated struct osdp_event. For the REPLY_KEYPPAD and REPLY_RAW reply types, the payload length is taken from the received frame and the only validation performed is that the declared length is self-consistent with the number of payload bytes present in the frame. Because the attacker controls both the length field and the frame length, that check imposes no bound, and the subsequent memcpy() writes into the fixed 64-byte data arrays of struct osdp_event_keypress / struct osdp_event_cardread (OSDP_EVENT_MAX_DATALEN). The sibling REPLY_FMT handler in the same switch already carried the missing > OSDP_EVENT_MAX_DATALEN bound. The defect is reached from cp_process_reply(), which reads bytes from the OSDP RS-485 channel and passes them through osdp_phy_check_packet() and osdp_phy_decode_packet() before dispatching on the reply ID. Triggering it requires CONFIG_OSDP with CONFIG_OSDP_MODE_CP and an application event callback registered (the normal Control Panel integration), plus a frame carrying a correct SOM, a valid CRC-16, and a matching 2-bit sequence number — all of which are computable or observable by anyone on the bus. No check ties the reply ID to the outstanding command, so an oversized REPLY_KEYPPAD or REPLY_RAW is accepted as the answer to a routine CMD_POLL. A malicious or compromised card reader, or anyone with access to the RS-485 wiring, can supply such a frame; CONFIG_OSDP_SC_ENABLED only helps while a secure channel is active, and a single unauthenticated frame carrying a bad MAC causes sc_deactivate(), after which plaintext replies are again accepted. With the default CONFIG_OSDP_UART_BUFFER_LENGTH of 256, roughly 180 bytes of fully attacker-chosen data can be written past the end of the stack-allocated event object, over saved registers and the return address on typical Cortex-M and RISC-V frame layouts (Zephyr does not enable stack canaries by default). The impact ranges from a hard crash of the access-control panel to potential control-flow hijack in the context of the OSDP receive thread. The fix adds an OSDP_EVENT_MAX_DATALEN bound to both handlers, capping each memcpy() at the size of its destination. Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.9 | CVE-2026-76787 |
The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehub.c)
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-76787The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehub.c)
From the advisoryThe UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehub.c). The decoder treats every descriptor field as optional — json_obj_parse() returns a bitmask of the fields it actually decoded and never fails on a missing one — so a response that omits the "sha256sum" string leaves the corresponding const char * in the zero-initialised struct resp_probe_any_boards / struct resp_probe_some_boards at NULL. Both metadata branches then computed sha256size = strlen(...objects.sha256sum) + 1 before any validation, dereferencing that NULL pointer; the SHA256_HEX_DIGEST_SIZE test that follows operates on a value the bad read has already produced and cannot prevent it. The metadata is supplied entirely by the network peer: probe_cb() accepts the datagram, runs coap_packet_parse() and copies the payload with no token matching and no cryptographic check. With CONFIG_UPDATEHUB_DTLS unset — the default — start_coap_client() uses plain CoAP over UDP on port 5683 with no peer authentication and resolves the server via unauthenticated DNS, so an on-path attacker, a DNS spoofer, or an off-path attacker who wins the race with a forged source address can deliver the malformed metadata. A probe response as simple as "objects":[[{}],[{}]] suffices, and no user interaction is required because updatehub_autohandler() polls on CONFIG_UPDATEHUB_POLL_INTERVAL. When CONFIG_UPDATEHUB_DTLS=y the trigger narrows to a malicious or compromised update server. The primitive is a read at address zero, not a write, so the impact is availability only. On targets where the low address range is unmapped or protected — MMU-based architectures, builds with CONFIG_NULL_POINTER_EXCEPTION_DETECTION_DWT/_MPU/_PMP, TrustZone non-secure images, and SoCs such as nRF54L whose 0x0–0x400 window is unmapped — the load faults and Zephyr's default fatal handler halts the system, giving a remotely re-triggerable denial of service on every poll. On classic Cortex-M targets where the vector table is readable at address zero the walk usually terminates immediately and the request is rejected by the length check, so the outcome is configuration- and SoC-dependent. There is no memory write, and the copied bytes are only compared against the locally computed image hash, so there is no information-disclosure channel. The fix adds an explicit sha256sum == NULL test that returns UPDATEHUB_METADATA_ERROR ahead of the strlen() in both metadata branches. Debug builds (CONFIG_UPDATEHUB_LOG_LEVEL=4) still format the same pointers with %s in a LOG_DBG() loop that runs before the new checks, so that variant remains in debug configurations only. Impact if exploitedConfidentialityNone IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 4.2 | CVE-2026-75085 |
The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length -...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-75085The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length -...
From the advisoryThe STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n). The length originates in the ST link-layer receive-done metadata (p_metadata->length, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value. When the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame->psdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads roughly 128 bytes past the end of the radio receive buffer and copies that adjacent memory into a network packet that is submitted to the networking stack, giving an out-of-bounds read with a potential disclosure of adjacent RAM plus needless oversized packet allocation in the RX thread. The fix rejects a frame whose reported length is smaller than IEEE802154_FCS_LENGTH before the subtraction, and replaces the compiled-out assertion with a runtime length check that drops oversized frames — matching the runtime check already present in drivers/ieee802154/ieee802154_nrf5.c. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityLow
How it is exploited
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.8 | CVE-2026-75084 |
The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-75084The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in...
From the advisoryThe CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len < 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped. An unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip's 128-byte RX FIFO has not overflowed, so the driver's RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than one fragment is satisfied by a chain of fragments, but read_rxfifo_content() performs a single SPI burst of pkt_len bytes into the first fragment's buf->data and then calls net_buf_add() with the same length. A length above 128 therefore writes up to 127 bytes past the end of a fragment in the contiguous rx_bufs pool and leaves a net_buf whose len exceeds its capacity. The overflowing bytes are FIFO-underflow output rather than attacker-chosen data, so the practical impact is network-buffer-pool corruption and crashes rather than a controlled write. Only builds that enable CONFIG_IEEE802154_CC1200 with an attached CC1200 radio are affected. Impact if exploitedConfidentialityNone IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.9 | CVE-2026-75083 |
The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-75083The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a...
From the advisoryThe receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a uint8_t, where len is the frame length reported by the radio. The interrupt handler kw41z_isr() obtained that length from the RX_FRAME_LENGTH field of the ZLL IRQSTS register — a copy of the PHY header length byte of the frame received over the air — and only rejected the value zero. A reported length of one therefore underflowed to pkt_len == 255. Because the packet is allocated with NET_AF_UNSPEC on a non-Ethernet L2, net_pkt_rx_alloc_with_buffer() does not clamp the request to the interface MTU; with the default fixed-size buffer pool (CONFIG_NET_BUF_FIXED_DATA_SIZE, CONFIG_NET_BUF_DATA_SIZE=128) the allocation succeeded as a chain of two fragments. The subsequent register-to-buffer copy loops write into the first fragment only, so 255 bytes were written into a 128-byte net_buf data block, overrunning it by up to 127 bytes into adjacent network-buffer-pool memory, and reading up to 128 bytes past the end of the radio's PKT_BUFFER_RX register array. The length field originates from an unauthenticated frame transmitted by any device within 802.15.4 radio range, and is captured by the hardware at PHY-header time — before frame filtering has completed — while the handler samples it after clearing the interrupt status, so an attacker flooding frames with a length byte of one can drive the underflow. The impact is memory corruption in the shared receive buffer pool from interrupt context, most plausibly a crash or corruption of other packets' data; the overflowing bytes are radio register contents rather than attacker-authored data, which bounds the integrity impact. The fix rejects any length below KW41Z_FCS_LENGTH and additionally verifies net_buf_tailroom() of the first fragment before the copy loops, which also covers the CONFIG_NET_L2_OPENTHREAD variant of the size computation. Impact if exploitedConfidentialityNone IntegrityLow AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.1 | CVE-2026-19673 |
ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-19673ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr
From the advisoryethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct net_eth_vlan_hdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdr_len is raised to 18 so the subsequent net_buf_pull() removes more bytes than the buffer holds. A single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node's VLAN configuration is needed: net_eth_get_vlan_iface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the "frame is for me" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum — the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to net_recv_data(). With assertions enabled, net_buf_simple_pull() asserts and the node panics. In a production build (assertions and CONFIG_NET_BUF_HARDENING off) the uint16_t buffer length underflows to 65534 and buf->data is advanced past the end of the fragment's storage, so every later parser reads far outside the buffer and any net_buf_add() on that fragment computes tailroom from the underflowed length. The result is a reliable remote denial of service and out-of-bounds access with information-disclosure and corruption potential. Only configurations built with CONFIG_NET_VLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNET_HW_VLAN_TAG_STRIP), are affected. The fix rejects the frame before the tag is read, so hdr_len is thereafter either 14 or 18 with both sizes validated against pkt->buffer->len. Impact if exploitedConfidentialityLow IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.5 | CVE-2026-19940 |
The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by...
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-19940The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by...
From the advisoryThe Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by ACL connection index. On link teardown, hfp_ag_disconnected() cancels ag->tx_work and the per-call work items and then clears ag->acl_conn, which marks the pool slot as free — but it leaves ag->ongoing_call_work (and ag->slc_work) untouched. The next connection that lands on the same slot enters hfp_ag_create(), whose only occupancy test is ag->acl_conn, and immediately executes memset(ag, 0, sizeof(struct bt_hfp_ag)) followed by k_work_init_delayable(). Zeroing and re-initialising a k_work_delayable whose struct _timeout node is still linked into the kernel timeout list leaves the kernel holding a reference to a node with NULL prev/next links. ag->ongoing_call_work is armed by the remote peer: when a Hands-Free unit sends AT+CIND? during Service Level Connection establishment and the application provides the asynchronous get_ongoing_call callback, the AG schedules the work for CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT milliseconds (default 10000). The timer is cancelled only if the application answers in time via bt_hfp_ag_ongoing_calls(). A peer that sends AT+CIND?, then disconnects the HFP RFCOMM DLC, then immediately re-opens it on the same ACL link, reuses the same pool slot deterministically while the timeout is still pending — the AG's RFCOMM server accept path (hfp_ag_accept()) calls hfp_ag_create() directly, so the remote side drives both teardown and re-creation. The result is corruption of the kernel's timeout list: sys_dlist_remove() on the zeroed node performs writes through NULL pointers from the clock-announce path, and rescheduling the re-initialised work re-inserts a node the list already references, creating a cycle that the announce loop walks with interrupts locked. The observable impact is a fault or hang of the whole system, i.e. a denial of service reachable from Bluetooth radio range; no attacker-controlled data is written, so this does not by itself yield code execution. Exposure is limited to builds with CONFIG_BT_HFP_AG (marked experimental and disabled by default) whose application implements the asynchronous get_ongoing_call callback. Impact if exploitedConfidentialityNone IntegrityNone AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-19939 |
The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request
zephyrprojectzephyrproject zephyr
|
NVD | |||
|
CVE-2026-19939The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request
From the advisoryThe AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session->timeout_work before clearing the pending request, but bt_avdtp_l2cap_disconnected() only cleared session->req and left the delayable work armed. The struct bt_avdtp session is the first member of struct bt_a2dp, whose instances live in a static per-connection array, and a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session->br_chan.chan.conn is NULL — which the L2CAP layer arranges immediately after the disconnect callback returns. A remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bt_a2dp_discover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dp_accept() → a2dp_get_connection(), which zeroes the whole struct bt_a2dp while the work item's struct _timeout is still linked into the kernel's global timeout list. Both the disconnect and the reconnect instants are chosen by the attacker, so no race has to be won; an encrypted BR/EDR link is required, and CONFIG_BT_A2DP (experimental) must be enabled. With the default CONFIG_TIMEOUT_BACKEND_DLIST backend the kernel decides a timeout is inactive by testing whether its list node is linked, so after the memset() the kernel treats a node that is still on the global timeout list as free: the announce path pops a node whose links and handler pointer are NULL, and the next bt_work_reschedule() on the recycled session re-inserts the same node into a list that already contains it. The consequence is corruption of the single kernel data structure every timer, timeslice and sleep depends on — writes through zeroed or stale list pointers and a NULL handler dispatch — producing a system-wide crash or hang rather than a fault confined to the A2DP session. The fix cancels session->timeout_work at the top of bt_avdtp_l2cap_disconnected() and moves k_work_init_delayable() from avdtp_send_cmd() to the session-establishment paths bt_avdtp_connect() and bt_avdtp_l2cap_accept(), so the work item is always initialized before a disconnect callback can run. Impact if exploitedConfidentialityNone IntegrityLow AvailabilityHigh
How it is exploited
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||