p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-fips · Page n° 138

Vulnérabilités publiées pour linux-fips au cours des 30 derniers jours : 628. Présentes dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8629

  1. CVE-2026-64345

    Moyenne · CVSS 5.5EPSS 0,12%Aucun correctif publié

    usb: gadget: f_printer: take kref only for successful open

    In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_printer: take kref only for successful open printer_open() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference. Move kref_get() into the successful-open branch.

    Publication Mise à jour
  2. CVE-2026-64344

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    USB: idmouse: fix use-after-free on disconnect race

    In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use t

    Publication Mise à jour
  3. CVE-2026-64343

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    USB: ldusb: fix use-after-free on disconnect race

    In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the

    Publication Mise à jour
  4. CVE-2026-64342

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    USB: iowarrior: fix use-after-free on disconnect

    In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.

    Publication Mise à jour
  5. CVE-2026-64341

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    USB: iowarrior: fix use-after-free on disconnect race

    In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object

    Publication Mise à jour
  6. CVE-2026-64340

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    USB: legousbtower: fix use-after-free on disconnect race

    In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still

    Publication Mise à jour
  7. CVE-2026-64337

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    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.

    Publication Mise à jour
  8. CVE-2026-64336

    Moyenne · CVSS 5.5EPSS 0,12%Aucun correctif publié

    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

    Publication Mise à jour
  9. CVE-2026-64335

    Moyenne · CVSS 5.5EPSS 0,12%Aucun correctif publié

    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.

    Publication Mise à jour
  10. CVE-2026-64334

    Moyenne · CVSS 5.5EPSS 0,1%Aucun correctif publié

    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.

    Publication Mise à jour
  11. CVE-2026-64333

    Élevée · CVSS 7.8EPSS 0,17%Aucun correctif publié

    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

    Publication Mise à jour
  12. CVE-2026-64332

    Moyenne · CVSS 5.5EPSS 0,12%Aucun correctif publié

    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.

    Publication Mise à jour
  13. CVE-2026-64331

    Moyenne · CVSS 5.5EPSS 0,12%Aucun correctif publié

    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

    Publication Mise à jour
  14. CVE-2026-64330

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    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

    Publication Mise à jour
  15. CVE-2026-64329

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    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

    Publication Mise à jour
  16. CVE-2026-64323

    Élevée · CVSS 7.1EPSS 0,17%Aucun correctif publié

    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

    Publication Mise à jour
  17. CVE-2026-64322

    Élevée · CVSS 7.8EPSS 0,17%Aucun correctif publié

    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

    Publication Mise à jour
  18. CVE-2026-64320

    Critique · CVSS 9.1EPSS 0,8%Aucun correctif publié

    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 */ ...

    Publication Mise à jour
  19. CVE-2026-64318

    Élevée · CVSS 7.1EPSS 0,16%Aucun correctif publié

    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

    Publication Mise à jour
  20. CVE-2026-64317

    Élevée · CVSS 7.1EPSS 0,17%Aucun correctif publié

    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

    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →