p PatchFirst

PatchFirst · Latest vulnerabilities

linux vulnerabilities · Page 186

Vulnerabilities published for linux in the last 30 days: 799. Listed in the KEV catalogue: 0.

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 10270

  1. CVE-2026-64338

    Medium · CVSS 5.5EPSS 0.12%Fix available

    USB: misc: uss720: unregister parport on probe failure

    In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is abo

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-64337

    Medium · CVSS 5.5EPSS 0.16%Fix available

    usb: mtu3: unmap request DMA on queue failure

    In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-64336

    Medium · CVSS 5.5EPSS 0.12%Fix available

    USB: serial: keyspan_pda: fix information leak

    In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intende

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-64335

    Medium · CVSS 5.5EPSS 0.12%Fix available

    USB: serial: digi_acceleport: fix broken rx after throttle

    In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-64334

    Medium · CVSS 5.5EPSS 0.1%Fix available

    USB: serial: digi_acceleport: fix hard lockup on disconnect

    In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-64333

    High · CVSS 7.8EPSS 0.17%Fix available

    USB: serial: digi_acceleport: fix write buffer corruption

    In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-64332

    Medium · CVSS 5.5EPSS 0.12%Fix available

    USB: ulpi: fix memory leak on registration failure

    In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-64331

    Medium · CVSS 5.5EPSS 0.12%Fix available

    usbip: vudc: fix NULL deref in vep_dequeue()

    In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving Functio

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-64330

    High · CVSS 7.8EPSS 0.13%Fix available

    usb: typec: tcpm: Validate SVID index in svdm_consume_modes()

    In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it r

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2026-64329

    High · CVSS 7.8EPSS 0.13%Fix available

    usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove

    In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-64326

    Medium · CVSS 5.5EPSS 0.16%Fix available

    block: skip sync_blockdev() on surprise removal in bdev_mark_dead()

    In the Linux kernel, the following vulnerability has been resolved: block: skip sync_blockdev() on surprise removal in bdev_mark_dead() bdev_mark_dead()'s @surprise == true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete. syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path: nvme_mark_namespaces_dead()

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-64324

    High · CVSS 7.8EPSS 0.16%Fix available

    udf: validate free block extents against the partition length

    In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CA

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-64323

    High · CVSS 7.1EPSS 0.17%Fix available

    udf: validate VAT header length against the VAT inode size

    In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: map->s_type_specific.s_virtual.s_start_offset = le16_to_cpu(vat20->lengthHeader); map->s_type_specific.s_virtual.s_num_entries = (sbi->s_vat_inode->i_size - map->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, wh

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-64322

    High · CVSS 7.8EPSS 0.17%Fix available

    udf: validate sparing table length as an entry count, not a byte count

    In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { struct sparingEntry *entry = &st->mapEntry[i]; ... entry->origLocation ... } in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTa

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-64321

    Medium · CVSS 5.5EPSS 0.12%Fix available

    nvme: target: rdma: fix ndev refcount leak on queue connect

    In the Linux kernel, the following vulnerability has been resolved: nvme: target: rdma: fix ndev refcount leak on queue connect nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which acquires a reference on the returned ndev via kref_get(). On the path where the host queue backlog is exceeded and the function returns NVME_SC_CONNECT_CTRL_BUSY, reference of ndev is not released, leaking the kref. Fix this by adding a goto to the existing put_device label before the early return.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-64320

    Critical · CVSS 9.1EPSS 0.8%Fix available

    nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

    In the Linux kernel, the following vulnerability has been resolved: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check: u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */ ...

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-64319

    Critical · CVSS 9.1EPSS 0.56%Fix available

    nvmet-auth: validate reply message payload bounds against transfer length

    In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: validate reply message payload bounds against transfer length nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes. A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp. With DH authentication configured, the OOB poin

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-64318

    High · CVSS 7.1EPSS 0.16%Fix available

    partitions: aix: bound the pp_count scan to the ppe array

    In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: int numpps = be16_to_cpu(pvd->pp_count); ... for (i = 0; i < numpps; i += 1) { struct ppe *p = pvd->ppe + i; ... lp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, s

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-64317

    High · CVSS 7.1EPSS 0.17%Fix available

    isofs: bound Rock Ridge symlink components to the SL record

    In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL recor

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-64316

    Medium · CVSS 5.5EPSS 0.12%Fix available

    crypto: caam - use print_hex_dump_devel to guard key hex dumps

    In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.

    linuxOperating systems
    • Update to 6.8.0-147.147
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →