本页列出影响 linux linux_kernel 的已公开 CVE 漏洞（通过 NVD CPE 关联）。每行包含严重程度评分、摘要与发布日期，便于识别与分析安全问题。
| CVE | 摘要 | 来源 | 最高 CVSS | EPSS % | 公开时间 | 更新时间 |
|---|---|---|---|---|---|---|
| CVE-2026-53196 | In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination b | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 6.8 | 0.20% | 2026-06-25 | 2026-07-01 |
| CVE-2026-53195 | In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() valida | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.20% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53194 | In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_f | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-07-01 |
| CVE-2026-53193 | In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Forcibly close timer instances at closing When snd_timer object is freed via snd_timer_free() and still pending snd_timer_instance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namel | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53192 | In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Fix UAF at snd_timer_user_params() At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most o | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53191 | In the Linux kernel, the following vulnerability has been resolved: io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries When a bundle recv retries inside io_recv_finish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQE_F_MASK); Bits listed in CQE_F_MASK are inherited from the new iteration, and all other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53190 | In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, t | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53189 | In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put(). | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53188 | In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate the passed in fops for ib_get_ucaps() Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53187 | In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc The cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without first verifying that the value is within the valid CPU range. Passing such untrusted data to cpumask_test_cpu() may lead to an out-of-bounds read of the underlying cpumask bitmap: the helper expands to a test_bit() that indexes the bitmap | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.1 | 0.13% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53186 | In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromise | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.1 | 0.54% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53185 | In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffe | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.13% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53184 | In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.51% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53183 | In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the i | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.51% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53182 | In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53181 | In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once i | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53180 | In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix livelock in tmigr_handle_remote_up() tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.47% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53179 | In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix buffer over-read in rtw_update_protection rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53178 | In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.1 | 0.16% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53177 | In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |