p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux · Page n° 27

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 18203

  1. CVE-2026-98450

    Faible · CVSS 2EPSS 0,17%Correctif disponible

    smb: client: close completed creates on compound wait errors

    In the Linux kernel, the following vulnerability has been resolved: smb: client: close completed creates on compound wait errors compound_send_recv() waits for responses in order. If a later wait is interrupted, or if a later MID fails during response synchronization, an earlier CREATE may already have opened a remote handle. The earlier mid is then released without invoking handle_cancelled_mid(), leaving the remote handle open because no FID was copied to the caller. Mark completed earlier mids as cancelled when a compound wait or MID synchronization aborts. Keep their response buffers attached while the MIDs are synchronized, and transf

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  2. CVE-2026-98449

    Non évaluéeEPSS 0,16%Aucun correctif publié

    smb: client: delete compound mids on send failure before unlock

    In the Linux kernel, the following vulnerability has been resolved: smb: client: delete compound mids on send failure before unlock When sending a compound request fails, smb_send_rqst() kicks off a reconnect. compound_send_recv() still has those mids on pending_mid_q, but it unlocks the server without removing them first. During reconnect, cifs_abort_connection() walks pending_mid_q and runs each mid callback. With no response yet, those callbacks return credits and drop in_flight. Then compound_send_recv()'s send-error path returns the same credits again. in_flight ends up decremented twice and smb2_add_credits() WARNs. syzbot hits this

    Publication Mise à jour
  3. CVE-2026-98448

    Non évaluéeEPSS 0,18%Correctif disponible

    xfs: release orphanage dir inode if chown fails

    In the Linux kernel, the following vulnerability has been resolved: xfs: release orphanage dir inode if chown fails LOLLM points out that we leak the igrab'd reference to the orphanage directory inode if chowning it fails. Fix that.

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  4. CVE-2026-98445

    Non évaluéeEPSS 0,17%Correctif disponible

    xfs: don't let memory failures leak blocks and kill repairs

    In the Linux kernel, the following vulnerability has been resolved: xfs: don't let memory failures leak blocks and kill repairs LOLLM complains that a memory allocation failure in xrep_newbt_add_blocks results in online repair leaking blocks that were previously allocated to write a new btree, but the problem is worse than that -- a limitation of the codebase is that the callers cannot undo the transaction /and/ return the error -- either you undo all changes and commit the transaction, or you error out and the filesystem goes down. However, the new btree space reservation object isn't that big (~48 bytes). Let's just do a NOFAIL allocati

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  5. CVE-2026-98444

    Non évaluéeEPSS 0,15%Aucun correctif publié

    xfs: drop dquot flush lock when we can't find a buffer to flush

    In the Linux kernel, the following vulnerability has been resolved: xfs: drop dquot flush lock when we can't find a buffer to flush LOLLM noticed that xfs_qm_flush_one fails to drop the dquot flush lock if it can't grab the buffer associated with the dquot. Since there's no buffer, nobody else is going to drop the dqflock, so we need to do it ourselves.

    Publication Mise à jour
  6. CVE-2026-98443

    Élevée · CVSS 7.8EPSS 0,14%Correctif disponible

    xfs: fix cursor and pointer handling when recovering iunlink buckets

    In the Linux kernel, the following vulnerability has been resolved: xfs: fix cursor and pointer handling when recovering iunlink buckets LOLLM pointed out a bug in xlog_recover_iunlink_bucket: 1. We don't null out prev_ip after releasing it, which can lead to UAF problems if the inodegc flush call in the loop fails. at which point I noticed even more bugs: 2. If the inodegc flush inside the loop fails, we also leak @ip. 3. We set prev_agino to agino having already advanced agino, which results in inodes with i_prev_unlinked set to itself. 4. If we exit the bottom of the loop with prev_ip set, then prev_ip aliases ip and we als

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  7. CVE-2026-98442

    Élevée · CVSS 7.8EPSS 0,13%Correctif disponible

    net/sched: act_ct: fix helper UAF due to extensions realloc

    In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix helper UAF due to extensions realloc While calling the helpers, a raw pointer to the extensions area is wired into expectations list: -> nf_ct_helper() -> helper->help() -> nf_ct_expect_related_report() -> nf_ct_expect_insert() -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations) In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  8. CVE-2026-98441

    Élevée · CVSS 7.8EPSS 0,13%Correctif disponible

    net/sched: act_ct: avoid modifying shared unconfirmed ct entry

    In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: avoid modifying shared unconfirmed ct entry In a case where skb with an unconfirmed ct entry gets cloned, we may end up processing both again but with different sets of extensions. The series of events: 1. The first clone wants to commit and runs the helpers wiring up the extension pointer into the expectation list. 2. Then it looses the confirmation keeping the entry unconfirmed. 3. Second clone now wants to commit labels or run NAT and adds the new extension for that breaking the pointer in the expectation list causing UAF on the destru

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  9. CVE-2026-98440

    Élevée · CVSS 7EPSS 0,12%Correctif disponible

    KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great. Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  10. CVE-2026-98439

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

    smb/server: cancel async requests when closing connection

    In the Linux kernel, the following vulnerability has been resolved: smb/server: cancel async requests when closing connection An async request may still be waiting when a connection is closed. This can stop the connection from closing. Cancel active async requests before waiting for them to finish.

    Publication Mise à jour
  11. CVE-2026-98435

    Non évaluéeEPSS 0,16%Correctif disponible

    EDAC/altera: Use parent device for devres in altr_portb_setup()

    In the Linux kernel, the following vulnerability has been resolved: EDAC/altera: Use parent device for devres in altr_portb_setup() Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev. This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together.

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  12. CVE-2026-98433

    Moyenne · CVSS 6.9EPSS 0,17%Correctif disponible

    KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure

    In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure In kvmppc_svm_page_in(), if uv_page_in() fails after kvmppc_uvmem_get_page() has succeeded, the secure device page is never released. kvmppc_uvmem_get_page() sets a bit in kvmppc_uvmem_bitmap, allocates a kvmppc_uvmem_page_pvt struct, marks the GFN as KVMPPC_GFN_UVMEM_PFN, and calls zone_device_page_init() which sets refcount=1 and locks the page. The subsequent goto out_finalize skips the *mig.dst assignment, so migrate_vma_finalize() is a no-op for the page, and none of those resources are ever rec

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  13. CVE-2026-99999

    Critique · CVSS 9.3EPSS 0,79%Code d’exploitation publicCorrectif disponible

    ipv4: validate checksum_start before completing checksum

    In the Linux kernel, the following vulnerability has been resolved: ipv4: validate checksum_start before completing checksum If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work.

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  14. CVE-2026-98432

    Critique · CVSS 9.8EPSS 0,39%Correctif disponible

    ipv4: free inet_opt and ireq_opt after an RCU grace period

    In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  15. CVE-2026-98431

    Non évaluéeEPSS 0,2%Aucun correctif publié

    RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency

    In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lock Fix by removing disassociation_lock entirely and using the pre-existing hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same protec

    Publication Mise à jour
  16. CVE-2026-98430

    Non évaluéeEPSS 0,21%Correctif disponible

    RDMA/efa: Keep admin queues alive while IRQ is registered

    In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep admin queues alive while IRQ is registered The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration f

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  17. CVE-2026-98429

    Non évaluéeEPSS 0,21%Correctif disponible

    RDMA/efa: Keep EQ resources alive while IRQ is registered

    In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep EQ resources alive while IRQ is registered The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ.

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  18. CVE-2026-98428

    Moyenne · CVSS 5.4EPSS 0,21%Correctif disponible

    ALSA: usb: 6fire: Avoid embedded URBs

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: 6fire: Avoid embedded URBs The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward

    • Mettez à jour vers 6.12.113-1
    Publication Mise à jour
  19. CVE-2026-98427

    Moyenne · CVSS 6.8EPSS 0,2%Aucun correctif publié

    net/sched: codel: bound the dropping loop per dequeue call

    In the Linux kernel, the following vulnerability has been resolved: net/sched: codel: bound the dropping loop per dequeue call The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loo

    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 →