600910 matches found
CVE-2026-99027
The Linux kernel contains a slab-use-after-free vulnerability within the net: team component. The issue occurs because a nonzero dev_queue_xmit() result does not return ownership of the skb . Consequently, when an override port's qdisc drops the packet, the queue override helper incorrectly attem...
CVE-2026-99026
The Linux kernel contains a memory management issue in the net: team component. Specifically, when a broadcast transmission has no txable port, the bc_transmit() function returns false without consuming the original skb , yet team_xmit() returns NETDEV_TX_OK. This causes AF_PACKET sends to retain...
CVE-2026-99025
A vulnerability in the Linux kernel 's openvswitch component causes a soft lockup and system panic during a netlink flow dump . The issue occurs because ovs_flow_cmd_dump() calls ovs_flow_stats_get(), which uses spin_unlock_bh(). This repeatedly enables local softirqs, causing the dumping thread ...
Dirty-Frag-CVE-2026-43284
Dirty Frag CVE-2026-43284 and CVE-2026-43500 Exploit Reproduction and Detection Lab for a Linux kernel local privilege escalation chain. Status: VERIFIED. I completed the reproduction, the fileless verification, and the syscall-level detection in the lab kernel 6.18.9+kali-amd64. This document is...
CVE-2026-99024
The Linux kernel contains a vulnerability where optee_probe() calls tee_device_register() for both client and supplicant devices before the struct optee is fully initialized. Because tee_device_register() creates device nodes and links the device into the tee class, the device becomes accessible ...
CVE-2026-99023
The Linux kernel contains a memory leak vulnerability in the pcie-m2 power sequencing driver. Specifically, the function of_regulator_bulk_get_all() allocates a consumers array and expects the caller to release it. However, the file pwrseq-pcie-m2.c failed to free this array, resulting in a memor...
CVE-2026-99022
The Linux kernel contains a vulnerability in the ltc3676 regulator driver where the HRST (0x1e) and CLIRQ (0x1f) registers are incorrectly accessible for reading. Although these are write-only command strobes—where HRST triggers a hard reset and CLIRQ clears an interrupt—performing a read operati...
CVE-2026-99021
The Linux kernel contains a vulnerability in the of_regulator_bulk_get_all() function. The function allocates an array but fails to populate the supply names for each entry, whereas the core logic expects these names to be present. Specifically, regulator_bulk_enable() may attempt to print these ...
CVE-2026-99020
The Linux kernel contains a memory safety issue within the tps6594-regulator driver. Specifically, the TPS65224 BUCK2, BUCK3, and BUCK4 descriptors incorrectly report 4 as the number of linear ranges, while the underlying tps65224_bucks_2_3_4_ranges[] array only contains two entries. This discrep...
CVE-2026-99019
The Linux kernel contains a vulnerability in the scsi changer (ch) component where the ch_readconfig() function incorrectly maintains references to data transfer element devices . Because scsi_device_lookup() takes a reference that is never dropped, removed drives remain on the host's device list...
CVE-2026-99018
The Linux kernel is vulnerable to an unprivileged kernel arbitrary-write and control-flow-hijack primitive when CONFIG_SHADOW_CALL_STACK is enabled on riscv architecture. The root cause lies in handle_exception(), which incorrectly uses the user-writable tp register to determine if a trap origina...
CVE-2026-99017
The Linux kernel contains an issue where the T-Head C9xx CPU may not report its vulnerability to ghostwrite correctly. Specifically, in kernels where ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the RISCV_ALTERNATIVE_EARLY stage is not executed. This prevents errata_probe_ghostwrite() from m...
CVE-2026-99016
The Linux kernel contains a vulnerability in the riscv architecture's futex implementation. When the tagged address ABI is enabled (via CONFIG_RISCV_ISA_SUPM), the functions arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() fail to untag user pointers before performing atomic oper...
CVE-2026-99015
The Linux kernel contains a race condition in the Bluetooth hci_sock component where rebinding an HCI socket after a controller is unregistered can crash the kernel. The root cause is a lack of proper serialization: hci_sock_bind() clears the device reference under only the socket lock, while sen...
CVE-2026-99014
The Linux kernel contains a use-after-free vulnerability in the Bluetooth hci_sync component during PA sync scan setup. Specifically, the function hci_le_set_ext_scan_param_sync() retrieves a pointer from hci_sent_cmd_data() that borrows storage from sent_cmd or req_skb without holding a proper r...
CVE-2026-99013
The Linux kernel contains a vulnerability in the Bluetooth ISO stack where concurrent listen() calls on the same broadcast socket can lead to a use-after-free condition. This occurs because iso_sock_listen() drops the socket lock before calling iso_listen_bis() to maintain lock ordering. Conseque...
CVE-2026-99012
The Linux kernel contains a vulnerability in the Bluetooth ISO layer where iso_sock_connect() fails to properly serialize concurrent connection calls. Because the socket lock is released before connection setup, two concurrent callers can pass admission checks, leading to a race condition. This a...
CVE-2026-99011
The Linux kernel is vulnerable to a slab-use-after-free in the Bluetooth SCO subsystem. The issue arises because the sco_recv_scodata() function upgrades a weak back-pointer to a strong reference under hdev->lock, but the pointer is cleared in sco_conn_free() without holding that same lock. Th...
CVE-2026-99010
The Linux kernel Bluetooth RFCOMM component contains a memory leak vulnerability. The issue occurs in rfcomm_recv_data() when a Data Link Control (DLC) has no owner (e.g., after rfcomm_sock_destruct() clears d->owner but before the session closes). In the socket implementation, the skb is hand...
CVE-2026-99009
The Linux kernel contains a circular locking dependency vulnerability in the Bluetooth RFCOMM component. The issue arises because an RFCOMM connect() from userspace acquires rfcomm_mutex before hdev->lock, while the HCI event path (via rfcomm_security_cfm()) acquires them in the opposite order...