Vulnerability database
Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.
1,483 results · page 1 of 30
Oct 28, 2026The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller.CVE-2026-82961 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller. z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() and z_vrfy_gpio_pin_interrupt_configure() verified only the device object (K_SYSCALL_DRIVER_GPIO() / K_SYSCALL_OBJ()) and then passed the caller-supplied gpio_pin_t straight through to z_impl_gpio_pin_*() and on to the driver. The only pin check in include/zephyr/drivers/gpio.h was __ASSERT(gpio_port_pin_is_supported(cfg->port_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all. GPIO drivers use pin as a shift count and as an array index on the documented assumption that it is a pin the controller supports. On STM32, for example, gpio_stm32_pin_interrupt_configure() turns pin into an EXTI line and stm32_gpio_intc_set_irq_callback() writes data->cb[line_num].cb and data->cb[line_num].data into a NUM_EXTI_LINES-entry array (default 16) in drivers/interrupt_controller/intc_gpio_stm32.c, guarded only by a compiled-out __ASSERT_NO_MSG(); the same function then reads exti_irq_table[line_num] and calls irq_enable() on the result. Ot
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 28, 2026In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Don't reset VMBus connection state on error/exit paths In two places, currentCVE-2026-99216 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Don't reset VMBus connection state on error/exit paths In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Oct 26, 2026Mistral Vibe before 3.0.3 contains a remote code execution vulnerability that allows attackers to run commands by defining git filter drivers in an untrusted reCVE-2026-116843 · Other software · mistralai · reported by VulnCheckHigh 8.7
Mistral Vibe before 3.0.3 contains a remote code execution vulnerability that allows attackers to run commands by defining git filter drivers in an untrusted repository's .git/config. When started with --worktree, git worktree add applies .gitattributes and runs filter smudge, clean, or process commands before the trusted-folder check, executing attacker commands with user privileges.
- Product
- mistral-vibe
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (defaCVE-2026-82390 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.7
The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold. As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for examp
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026NXP MCUXpresso SDK USB middleware (mcuxsdk-middleware-usb) before 2.13.0 contains a heap buffer overflow in host audio, video and CDC class drivers that trust dCVE-2026-116488 · Other software · NXP · reported by VulnCheckHigh 7
NXP MCUXpresso SDK USB middleware (mcuxsdk-middleware-usb) before 2.13.0 contains a heap buffer overflow in host audio, video and CDC class drivers that trust device-supplied bNumEndpoints and bLength values. A malicious USB device can supply crafted descriptors that write endpoint entries past the fixed-size epList array, corrupting heap memory for code execution or denial of service.
- Product
- mcuxsdk-middleware-usb
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The 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 rCVE-2026-79978 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.6
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 = MIN(fifo_bytes, buf_avail)) to the space actually returned by rtio_sqe_rx_buf(), but then queues one 6-byte bus read per hardware FIFO entry at consecutive offsets from read_buf, bounded by the device-reported entry count rather than by the clamp. When the allocated buffer is smaller than a full batch, the driver writes up to 186 bytes past the end of the allocation; a companion defect left data->fifo_total_bytes un-reset at batch start, so an aborted or errored chain could leave a stale write offset that pushes the next batch's writes out of bounds as well. A short buffer is an expected, first-class outcome of the RTIO allocator: rtio_block_pool_alloc() walks the requested size down one block at a time until a contiguous run is available, and the driver only demands sizeof(struct adxl345_fifo_data) + 6 bytes as its minimum. Any streaming configuration whose mempool block granularity is smaller than a full FIFO batch (204 bytes) — for example the sensor shell's RTIO_DEFINE_WITH_MEMPOOL(sensor_read_rtio, 8,
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The 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 directlyCVE-2026-78119 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.3
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 request header in the FLASHRXBUF FIFO. For write and RPMC OP1 requests it copied DIV_ROUND_UP(len, 4) words into struct espi_taf_pckt.src, a fixed 16-word (64-byte) member of a static structure, without ever comparing the length against that buffer or against the negotiated eSPI receive payload size (rx-plsize, 64 bytes on all in-tree NPCX/NPCK SoCs). Both the loop counter and the word count were uint8_t, so the copy ran up to 255 iterations. An eSPI controller that emits a flash request whose header claims a payload larger than the negotiated maximum therefore drives up to 239 32-bit stores past the end of the structure — roughly 956 bytes of out-of-bounds write into .bss — from the eSPI flash receive interrupt handler, while the source reads walk past the end of the 18-word FLASHRXBUF register array into neighbouring eSPI registers. The same unvalidated length was then passed on to flash_write() in espi_taf_npcx_flash_write() with the 64-byte src buffer as source, reading up to 4 KB of adjacent controller SRAM
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The 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, staCVE-2026-78117 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.2
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 cy_stc_ble_hci_tx_packet_info_t hci_tx_pkt. psoc6_bless_send() cleared and populated that descriptor's packetType, dataLength and data fields before acquiring psoc6_bless_operation_sem, so the driver's serialising semaphore protected only the call into Cy_BLE_SoftHciSendAppPkt() and not the shared state that call reads. The Bluetooth host does not guarantee a single HCI sender. Most transmissions are funnelled through the cooperative TX-processor work queue, but bt_hci_cmd_send() deliberately bypasses bt_dev.cmd_tx_queue for BT_HCI_OP_HOST_NUM_COMPLETED_PACKETS and calls bt_send() directly from the caller's thread; that caller is bt_hci_host_num_completed_packets(), the acl_in_pool destroy callback, which runs on whichever thread drops the last reference to a received ACL buffer. CONFIG_BT_HCI_ACL_FLOW_CONTROL defaults to y on this driver's boards, and an application that returns -EINPROGRESS from its L2CAP recv callback and later calls bt_l2cap_chan_recv_complete() performs that unref from its own preemptible thread. A
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set().CVE-2026-19947 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.3
The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set(). When CONFIG_USERSPACE is enabled, their user-mode verifiers z_vrfy_devmux_select_get() and z_vrfy_devmux_select_set() forwarded directly to the kernel implementations without performing any kernel-object validation — no k_object_access_check() and no driver object check. Compounding this, DEVICE_DT_INST_DEFINE() registered devmux instances with a NULL driver API pointer, which causes scripts/build/gen_kobject_list.py to skip them entirely, so a devmux device had no struct k_object and no permission on it could be granted or withheld in the first place. Any thread running in user mode can reach the defect: device pointers such as DEVICE_DT_GET(DT_NODELABEL(devmux0)) are compile-time constants available to application code, and the syscall accepted them from a thread that had never been granted access to the device. The kernel implementations do validate the pointer against the static devmux instance table and bounds-check the selection index, so this is not a memory-safety issue; the failure is purely one of authorization. Exposure requires CON
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The 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 anCVE-2026-19676 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
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 caller-supplied struct peci_msg with k_usermode_from_copy(). That copy validates the outer structure only; the buf pointers and len values inside the embedded struct peci_buf members tx_buffer and rx_buffer remained fully caller-controlled and were passed unchecked to the driver. Every in-tree PECI driver dereferences those pointers in supervisor mode: peci_npcx_transfer() in drivers/peci/peci_npcx.c and peci_it8xxx2_transfer() in drivers/peci/peci_ite_it8xxx2.c copy hardware bytes into rx_buffer.buf[i] and read command bytes out of tx_buffer.buf[i], and peci_xec_read()/peci_xec_write() in drivers/peci/peci_mchp_xec.c do the same with no bound on rx_buffer.len at all. A user-mode thread that has been granted the PECI device object — the normal way an application exposes a device under CONFIG_USERSPACE — could therefore point rx_buffer.buf at kernel data structures and have the driver write hardware-supplied bytes there, or point tx_buffer.buf at kernel memory and have its contents pushed onto the PECI/eSPI out-
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: USB: serial: fix port tear down use-after-free Some drivers for multiport devices access pCVE-2026-98772 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: USB: serial: fix port tear down use-after-free Some drivers for multiport devices access port driver data from completion handlers of shared URBs submitted at attach() or first open() and stopped at disconnect() or last close(), respectively. A simple NULL check before accessing the driver data makes sure that a port state container has at least been allocated, but a completion handler can still race with port tear down. Reorder the disconnect handling so that ports are not deregistered (and their driver data freed) until after all ports have been hung up and the driver disconnect() callback has run so that all I/O has been stopped.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: tty: port: fix tty_port_tty_vhangup() race Drivers rely on tty_port_tty_vhangup() to synchCVE-2026-98752 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: tty: port: fix tty_port_tty_vhangup() race Drivers rely on tty_port_tty_vhangup() to synchronously hang up their ports before tearing down resources as part of deregistration (e.g. on physical disconnect). If tty_port_tty_vhangup() races with another hangup it may however return before the port has been shut down. This is in turn can lead to use-after-free and NULL-pointer dereferences in racing ioctls (including a synchronous hangup) and in processing of racing asynchronous hangups (carrier loss). Add the missing serialisation to tty_port_tty_vhangup() and tty_port_hangup() so that the former does not return until the port has been shut down also when there is a racing hangup. Note that serial core does not use tty_port_hangup(), but it already holds the port mutex when clearing port->tty and shutting down the port in uart_hangup().
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Oct 14, 2026The 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 - IEECVE-2026-75085 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.2
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 - 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
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 14, 2026The 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_CVE-2026-75083 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.9
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 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 fram
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Integer overflow or wraparound in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-96915 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.8
Integer overflow or wraparound in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Use of uninitialized resource in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.CVE-2026-96849 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comMedium 5.5
Use of uninitialized resource in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.
- Product
- Windows 11 version 26H1
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Use of uninitialized resource in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.CVE-2026-96247 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comMedium 5.5
Use of uninitialized resource in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Heap-based buffer overflow in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-85871 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.8
Heap-based buffer overflow in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Insertion of sensitive information into log file in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.CVE-2026-85857 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comMedium 5.5
Insertion of sensitive information into log file in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Improper access control in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-83837 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.8
Improper access control in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Use after free in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-83834 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7
Use after free in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Out-of-bounds read in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-83637 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.8
Out-of-bounds read in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Improper access control in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.CVE-2026-83568 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.8
Improper access control in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally.
- Product
- Windows 11 Version 24H2
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026Incorrect authorization in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.CVE-2026-69971 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comMedium 5.5
Incorrect authorization in Windows Kernel-Mode Drivers allows an authorized attacker to disclose information locally.
- Product
- Windows 11 Version 24H2
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH.CVE-2026-19737 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.5
i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error. i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData().CVE-2026-19736 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes. entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the ove
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared twoCVE-2026-19669 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared two variable-length arrays, union fuel_gauge_prop_val k_vals[len] and fuel_gauge_prop_t k_props[len], sized directly by the caller-supplied len argument. len is an unvalidated size_t taken straight from the syscall ABI, and the VLAs were allocated before any check at all — including before the K_SYSCALL_DRIVER_FUEL_GAUGE() object-permission check. The subsequent k_usermode_from_copy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len. Any thread running in user mode with CONFIG_USERSPACE enabled can invoke fuel_gauge_get_props() or fuel_gauge_set_props() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount — Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POICVE-2026-19576 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.8
The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured. Each loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller — plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound Transport drivers (suchCVE-2026-98202 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device. When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex. Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Oct 5, 2026The system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c validated the outer struct i3c_ccc_payload, the broadcast ccc.data buffer and the targetCVE-2026-19185 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c validated the outer struct i3c_ccc_payload, the broadcast ccc.data buffer and the targets.payloads[] array, but did not validate the per-target data buffers those array elements point at. Each struct i3c_ccc_target_payload carries its own data pointer and data_len, and neither was passed through K_SYSCALL_MEMORY() before the payload was handed to z_impl_i3c_do_ccc() and on to the controller driver. The verifier also operated on the caller's live structure rather than a snapshot, so validated fields could be changed by a second user thread between the check and the driver's use — unlike the sibling z_vrfy_i3c_transfer(), which has always copied its message array first. The defect is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled. An unprivileged user-mode thread that has been granted access to the I3C controller device object — the ordinary way an application lets a user thread talk to I3C peripherals — can issue a direct CCC whose target payload data pointer names an arbitrary kernel address. Controller drivers dereference that pointer directly (for example drivers/i3c/i3
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 5, 2026The NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) validated the caller-supplied sequence->buffer_size, which is expressed in bytes, against the number of CVE-2026-19184 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 8.4
The NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) validated the caller-supplied sequence->buffer_size, which is expressed in bytes, against the number of active channels, which is a sample count. It then stored that byte count directly in data->results_length and used it in mcux_gau_adc_read_samples() as the number of uint16_t slots available. Because each conversion result occupies sizeof(uint16_t) bytes, a buffer that was accepted as "large enough" could be written with up to twice its size in bytes, so every sample past the buffer's midpoint was written out of bounds. adc_read() and adc_read_async() are Zephyr system calls. The syscall verifier in drivers/adc/adc_handlers.c only confirms that the caller owns buffer_size writable bytes (K_SYSCALL_MEMORY_WRITE); deciding whether that size is sufficient for the requested channels and extra_samplings is delegated entirely to the driver. On a build with CONFIG_USERSPACE=y, a user-mode thread that has been granted the ADC device object could therefore submit a deliberately half-sized buffer and cause the driver's work-queue handler — which runs in supervisor mode, outside the caller's MPU restrictions — to write ADC conversion
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 29, 2026U-Boot through 2026.10-rc5 contains an out-of-bounds write vulnerability in the video_display_rle8_bitmap function in drivers/video/video_bmp.c.CVE-2026-71972 · Other software · u-boot · reported by VulnCheckMedium 6
U-Boot through 2026.10-rc5 contains an out-of-bounds write vulnerability in the video_display_rle8_bitmap function in drivers/video/video_bmp.c. Attackers can supply a crafted RLE8-compressed BMP image to corrupt memory adjacent to the framebuffer and crash the bootloader.
- Product
- u-boot
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 26, 2026Adminer 6.0.0 through 6.0.1, when the official ClickHouse driver plugin (plugins/drivers/clickhouse.php, rewritten in 6.0.0) is loaded, is vulnerable to pre-autCVE-2026-100697 · Other software · vrana · reported by VulnCheckMedium 5.3
Adminer 6.0.0 through 6.0.1, when the official ClickHouse driver plugin (plugins/drivers/clickhouse.php, rewritten in 6.0.0) is loaded, is vulnerable to pre-authentication server-side request forgery. An unauthenticated attacker can submit auth[driver]=clickhouse with auth[server] set to an arbitrary URL (for example http://127.0.0.1:18089), causing the Adminer server to issue an HTTP POST containing 'SELECT version()' to that host. In rootQuery(), if the target returns a status outside 200-299 (other than 401/403), the raw HTTP response body is assigned to the connection error and rendered on the login page, so the attacker receives the full response body of the internal service. This enables internal network/port reconnaissance and disclosure of sensitive information contained in internal error pages (stack traces, internal hostnames, file paths, configuration identifiers). Fixed in Adminer 6.0.2.
- Product
- adminer
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comvulncheck.com
Sep 26, 2026Adminer 4.16.0 through 6.0.1 contain a pre-authentication Server-Side Request Forgery (SSRF) vulnerability in the optional Elasticsearch driver (plugins/driversCVE-2026-100696 · Other software · vrana · reported by VulnCheckMedium 6.9
Adminer 4.16.0 through 6.0.1 contain a pre-authentication Server-Side Request Forgery (SSRF) vulnerability in the optional Elasticsearch driver (plugins/drivers/elastic.php), fixed in 6.0.2. Because adminer/include/auth.inc.php invokes Driver::connect() before the login result is validated, an unauthenticated attacker who submits crafted auth[server], auth[username], and auth[password] parameters can cause the Adminer server to issue an HTTP GET request (via get_url()/file_get_contents()) to an arbitrary reachable host and port. The driver validates only general server syntax and does not block loopback, private, link-local, or other reserved addresses; if no port is given it appends the default 9200, and Adminer's generic port check rejects ports below 1024. Selected JSON error fields from non-2xx Elasticsearch-style responses, as well as connection failures, are rendered on the login page, providing a port-scanning oracle and enabling internal network reconnaissance and service fingerprinting. Exploitation requires that the optional Elasticsearch driver be explicitly deployed (e.g., via the adminer/elastic.php template or an adminer_object() configuration; it is not loaded in a d
- Product
- adminer
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comvulncheck.com
Sep 24, 2026In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermCVE-2026-97475 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 24, 2026In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() CVE-2026-93219 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 21, 2026The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task().CVE-2026-17054 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.3
The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object. Only the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame — its per-fragment header and checksum are genuine, so both validation steps pass — and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unaut
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 21, 2026The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port devicCVE-2026-17052 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded. tgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller. The result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 21, 2026The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose().CVE-2026-17051 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6
The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image. The doorbell register is written by the peer processor on the other side of the IPC link — for the intel_ish_5_* targets, the host CPU's ISH driver, reached through the device's memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 20, 2026Missing Authorization in the IOCTL handlers of the wsdkd.sys kernel drivers in Watchdog WatchDog Antivirus 1.8.640 (driver versions 1.3.0.0 and earlier) on MicrCVE-2026-92254 · Other software · Watchdog · reported by 34edf4f2-2577-40ab-82ce-39f45972c129Medium 6.9
Missing Authorization in the IOCTL handlers of the wsdkd.sys kernel drivers in Watchdog WatchDog Antivirus 1.8.640 (driver versions 1.3.0.0 and earlier) on Microsoft Windows allows local, low-privileged attackers to delete arbitrary files with SYSTEM privileges, bypassing NTFS access controls and potentially disabling security products or destabilizing the operating system, via crafted IOCTL requests sent to the \Device\wsdk device.
- Product
- Anti-Virus
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordwatchdog.comwatchdog.com
Sep 18, 2026virtio-win provides Windows paravirtualized drivers for QEMU and KVM.CVE-2026-46655 · Other software · virtio-win · reported by GitHubHigh 7.8
virtio-win provides Windows paravirtualized drivers for QEMU and KVM. From mm210 until mm320, the Viosock driver permits a low-privilege local process to submit an IOCTL_SELECT request with attacker-controlled VIRTIO_VSOCK_SELECT.Fdss[*].fd_count values that overflow the 32-bit sum used by VIOSockSelect for bounds checking. The wrapped sum can pass the FD_SETSIZE check even though an individual descriptor count is much larger than the expected limit. VIOSockSelectCopyFds then iterates using the unchecked count and writes beyond the allocated pPkt->Fds array in the NonPagedPool kernel heap. Successful exploitation can corrupt kernel memory and enable privilege escalation in a Windows guest running the driver. This issue is fixed in mm320.
- Product
- kvm-guest-drivers-windows
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zCVE-2026-93142 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of "priv->zone". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dump_workCVE-2026-90365 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type Samsung PWM timer might be CVE-2026-90208 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition The VMBus moduCVE-2026-90097 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of ro
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 14, 2026The ITE IT82xx2 USB device-controller driver (drivers/usb/udc/udc_it82xx2.c) mishandles multi-packet OUT transfers on non-control endpoints.CVE-2026-16147 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.8
The ITE IT82xx2 USB device-controller driver (drivers/usb/udc/udc_it82xx2.c) mishandles multi-packet OUT transfers on non-control endpoints. In work_handler_out() the active transfer buffer is obtained with udc_buf_peek() (which does not dequeue it); when a full max-packet-size packet arrives but the buffer still has tailroom (the transfer is not yet complete), the pre-fix code both re-arms the endpoint to keep filling that same buf via work_handler_xfer_continue() and simultaneously hands the same, still-being-filled buffer to the upper stack with udc_submit_ep_event(). Because udc_submit_ep_event() transfers ownership of the buffer to the USB device stack (usbd_event_carrier() appends &buf->node to uds_ctx->ep_events, after which the class handler processes and net_buf_unref()s it), the driver continues to DMA subsequent host-controlled OUT packets into a buffer the upper stack may already have freed and recycled — a use-after-free write. In addition, since the buffer was never dequeued, the completing packet runs udc_buf_get() on the same object and submits it a second time, appending &buf->node to the event slist twice (singly-linked-list corruption) and causing a double net_b
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 11, 2026In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error path When cpuhp_setupCVE-2026-89769 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.4
In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error path When cpuhp_setup_state fails after pit_clockevent_per_cpu_init has successfully called request_irq, the error handling jumps directly to out_pit_clocksource_unregister without freeing the registered IRQ. This leaks the IRQ line and, since kfree(pit) follows, leaves a dangling pointer registered as the interrupt handler's dev_id, potentially leading to a use-after-free if the IRQ fires afterwards. Fix it by calling pit_clockevent_per_cpu_exit to properly release the IRQ before falling through to the existing cleanup chain.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 11, 2026In the Linux kernel, the following vulnerability has been resolved: block: validate user space vectors during extraction The bio-based drivers don't necessariCVE-2026-89584 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: block: validate user space vectors during extraction The bio-based drivers don't necessarily check the alignment split, and stacking block drivers don't always handle a misalignment detected after submitting the bio. Validate user vectors against the device's dma_alignment as the bio is built from the iov_iter, rejecting misaligned early with -EINVAL.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Sep 10, 2026The Sierra Wireless HL78xx modem GNSS driver (drivers/modem/hl78xx/, later drivers/modem/vendor_standalone/hl78xx/) embeds a generic struct gnss_nmea0183_match_CVE-2026-15461 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.3
The Sierra Wireless HL78xx modem GNSS driver (drivers/modem/hl78xx/, later drivers/modem/vendor_standalone/hl78xx/) embeds a generic struct gnss_nmea0183_match_data match_data inside struct hl78xx_gnss_data. The generic NMEA0183 match helper (drivers/gnss/gnss_nmea0183_match.c) requires that context to be the first member because its callbacks cast user_data directly to struct gnss_nmea0183_match_data . In the affected releases match_data was the second member (after const struct device dev), so it sat at a non-zero offset while gnss_nmea0183_match_init() initialized it at the correct address. The registered NMEA handlers instead pass the whole device data object (data->devices.gnss->data, offset 0), producing an offset-shifted type confusion between where state is initialized and where the parse callbacks read and write it. When NMEA sentences from the GNSS receiver are parsed, the GGA/RMC callbacks write parsed fix data into the wrong location within the struct, and the GSV callback (gnss_nmea0183_match_gsv_callback, active under CONFIG_GNSS_SATELLITES) reads its satellites pointer and bound from the wrong offsets — non-pointer bytes of struct hl78xx_gnss_data — and then writes
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 8, 2026In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying CVE-2026-86600 · Other software · Snowflake · reported by 412d305a-227d-44f9-a262-a31ba44f2aeaHigh 8.2
In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying that the configured host is a Snowflake endpoint. An attacker who can modify the connection configuration can cause the driver to mint a fresh attestation and send it to a host they control. The captured token can be replayed to Snowflake for its remaining lifetime in accounts where that workload identity is already registered. On Azure, the token audience is also taken from connection configuration. Combined with an attacker-controlled host, the driver can request a Managed Identity access token scoped to a non-Snowflake Azure resource and deliver it to the attacker. That path is the only case in which impact extends beyond Snowflake; it is bounded by the token lifetime and the managed identity’s permissions. Successful exploitation requires WORKLOAD_IDENTITY authentication on a workload that already has an ambient cloud identity. Patched driver versions restrict this authenticator to recognized Snowflake hosts. Users must manually upgrade.
- Product
- Snowflake Connector for Python
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recorddocs.snowflake.comdocs.snowflake.com
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
Tell us what you're building.
A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.
Not ready to talk yet? Run the free website check and see what Google sees.