This page lists publicly disclosed CVE vulnerabilities affecting linux linux_kernel (linked via NVD CPE). Each row includes severity scores, summaries, and publication dates to help identify and analyze security issues.
| CVE | Summary | Source | Max CVSS | EPSS % | Published | Updated |
|---|---|---|---|---|---|---|
| CVE-2026-63976 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value. A remote attacker that completed a reconfig | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.45% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63975 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected. Calling l2cap_chan_clone directly may stil | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.35% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63974 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.32% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63973 | In the Linux kernel, the following vulnerability has been resolved: net: mana: Add NULL guards in teardown path to prevent panic on attach failure When queue allocation fails partway through, the error cleanup frees and NULLs apc->tx_qp and apc->rxqs. Multiple teardown paths such as mana_remove(), mana_change_mtu() recovery, and internal error handling in mana_alloc_queues() can subsequently call into functions that dereference these pointers without NULL checks: - mana_chn_setxdp() dereferen | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-19 |
| CVE-2026-63972 | In the Linux kernel, the following vulnerability has been resolved: net: mana: Skip redundant detach on already-detached port When mana_per_port_queue_reset_work_handler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->tx_qp and apc->rxqs already freed. Calling mana_detach() again unconditionally leads to NULL pointer dereferences during queue teardown. Add an early exit in mana_detach() when the port is already in detached state (!net | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.58% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63971 | In the Linux kernel, the following vulnerability has been resolved: sctp: fix race between sctp_wait_for_connect and peeloff sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migrati | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.21% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63970 | In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: bind uarg before filling zerocopy skb virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg before entering the send loop, but virtio_transport_alloc_skb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfree_skb() to free an skb that carries | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.20% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63969 | In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in rt6_fill_node() Sashiko reported this issue [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings) without waiting for RCU readers; rt->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &rt->fib6_siblings, causing a CPU stall. fi | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-19 |
| CVE-2026-63968 | In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in fib6_select_path() Found while auditing the same pattern Sashiko reported in rt6_fill_node() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings) without waiting for RCU readers; first->fib6_siblings.next then still points into the old ring and this softirq-side walker ne | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.66% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63967 | In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer The tagged FIFO path declares iio_buff on the stack with __aligned(8) but no initializer, but there is a hole in the structure, which will then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be copied, but the space between that and the timestamp are not initialized. Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") moved the un | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-19 |
| CVE-2026-63966 | In the Linux kernel, the following vulnerability has been resolved: iio: imu: adis16550: fix stack leak in trigger handler adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigg | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-07-19 | 2026-07-19 |
| CVE-2026-63965 | In the Linux kernel, the following vulnerability has been resolved: iio: pressure: bmp280: fix stack leak in bmp580 trigger handler bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-07-19 | 2026-07-19 |
| CVE-2026-63964 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63963 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63962 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63961 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: validate count before reading Status Update VDO A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63960 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer() wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++) regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i); which has two problems: USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD] | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63959 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63958 | In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_connector_change() The connector number in a UCSI CCI notification is a 7-bit field supplied by the PPM. ucsi_connector_change() uses it to index the ucsi->connector[] array without checking it against the number of connectors the PPM reported at init time, so a buggy or malicious PPM (EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 / glink transports) c | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-20 |
| CVE-2026-63957 | In the Linux kernel, the following vulnerability has been resolved: USB: serial: safe_serial: fix memory corruption with small endpoint Make sure that the bulk-out buffer size is at least eight bytes to avoid user-controlled slab corruption in "safe" mode should a malicious device report a smaller size. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.21% | 2026-07-19 | 2026-07-19 |