本页列出影响 linux linux_kernel 的已公开 CVE 漏洞（通过 NVD CPE 关联）。每行包含严重程度评分、摘要与发布日期，便于识别与分析安全问题。
| CVE | 摘要 | 来源 | 最高 CVSS | EPSS % | 公开时间 | 更新时间 |
|---|---|---|---|---|---|---|
| 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 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 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63956 | In the Linux kernel, the following vulnerability has been resolved: USB: serial: cypress_m8: fix memory corruption with small endpoint Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63955 | In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: do not trigger BUG() on BH disabled context __get_vm_area_node() currently triggers a BUG() if in_interrupt() returns true. However, in_interrupt() also reports true when BH are disabled. The bridge code can call rhashtable_lookup_insert_fast() with bottom halves disabled: __vlan_add() -> br_fdb_add_local() spin_lock_bh(&br->hash_lock); <-- Disable BH -> fdb_add_local() -> fdb_create() -> rhashtab | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63954 | In the Linux kernel, the following vulnerability has been resolved: hpfs: fix a crash if hpfs_map_dnode_bitmap fails If hpfs_map_dnode_bitmap fails, the code would call hpfs_brelse4 on uninitialized quad buffer head, causing a crash. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-20 |
| CVE-2026-63953 | In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due to a PMD check failure, the pgtable allocated earlier via pte_alloc_one() is never freed, causing a memory leak. Added free_abort label to release the pgtable in error path. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63952 | In the Linux kernel, the following vulnerability has been resolved: memfd: deny writeable mappings when implying SEAL_WRITE When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEAL_EXEC to apply SEAL_WRITE while having writeable mappings. This breaks the contract that SEAL_WRITE provides and can be used by an attacker to pass a memfd that appears to be wri | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63951 | In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_writeback_endio A crash was observed in zram_writeback_endio due to a NULL pointer dereference in wake_up. The root cause is a race condition between the bio completion handler (zram_writeback_endio) and the writeback task. In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after releasing wb_ctl->done_lock. This creates a race window where the writeback task can see num_infl | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63950 | In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the la | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63949 | In the Linux kernel, the following vulnerability has been resolved: auxdisplay: line-display: fix OOB read on zero-length message_store() linedisp_display() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]: write(fd, "", 0); -> message_store(..., buf, count=0) -> linedisp_display(linedisp, buf, count=0) -> msg[count - 1] == '\n' ; OOB read The kernfs write buffer for that store is a | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63948 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn __set_chan_timer() takes a l2cap_chan reference via l2cap_chan_hold() before scheduling the delayed work. The normal path in l2cap_chan_timeout() drops this reference with l2cap_chan_put() at the end, but the early return when chan->conn is NULL skips the put, leaking the reference. Add the missing l2cap_chan_put() before the early return. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |
| CVE-2026-63947 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: fix missing length checks in hidp_input_report() hidp_input_report() reads keyboard and mouse payload data from an skb without first verifying that skb->len contains enough data. hidp_recv_intr_frame() pulls the 1-byte HIDP header before dispatching to hidp_input_report(). If a paired device sends a truncated packet, the handler reads beyond the valid skb data, resulting in an out-of-bounds read of skb data. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | — | 2026-07-19 | 2026-07-19 |