p PatchFirst

PatchFirst · Vulnérabilités récentes

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

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 20122

  1. CVE-2026-97605

    Non évaluéeEPSS 0,21%Correctif disponible

    erofs: preserve LZMA decoders on resize failure

    In the Linux kernel, the following vulnerability has been resolved: erofs: preserve LZMA decoders on resize failure The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unr

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  2. CVE-2026-97604

    Non évaluéeEPSS 0,21%Correctif disponible

    fbdev: vfb: defer cleanup until the last reference

    In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  3. CVE-2026-97603

    Élevée · CVSS 7.1EPSS 0,21%Correctif disponible

    idpf: disable DIM work before freeing q_vectors

    In the Linux kernel, the following vulnerability has been resolved: idpf: disable DIM work before freeing q_vectors idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them. idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed q_vector. No configuration is needed t

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  4. CVE-2026-97602

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

    inet: frags: invalidate queues before flushing them

    In the Linux kernel, the following vulnerability has been resolved: inet: frags: invalidate queues before flushing them fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() u

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  5. CVE-2026-97601

    Non évaluéeEPSS 0,21%Correctif disponible

    ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  6. CVE-2026-97600

    Non évaluéeEPSS 0,2%Correctif disponible

    ieee802154: cc2520: fix FIFOP work use-after-free

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: cc2520: fix FIFOP work use-after-free The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  7. CVE-2026-97599

    Non évaluéeEPSS 0,21%Correctif disponible

    ieee802154: hwsim: serialize pib updates to fix double-free

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(),

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  8. CVE-2026-97598

    Non évaluéeEPSS 0,22%Correctif disponible

    ipv4: fib: bound automatic table ID allocation

    In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TA

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  9. CVE-2026-97597

    Moyenne · CVSS 6.8EPSS 0,22%Correctif disponible

    ipv6: flowlabel: cap duplicate leases per socket

    In the Linux kernel, the following vulnerability has been resolved: ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  10. CVE-2026-97596

    Non évaluéeEPSS 0,22%Correctif disponible

    ipvs: reject invalid states in connection template sync records

    In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  11. CVE-2026-97595

    Élevée · CVSS 7.5EPSS 0,29%Correctif disponible

    mac802154: fix use-after-free of sdata via queued RX frames

    In the Linux kernel, the following vulnerability has been resolved: mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  12. CVE-2026-97594

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

    landlock: Fix use-after-free of the source's parent directory

    In the Linux kernel, the following vulnerability has been resolved: landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filenam

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  13. CVE-2026-97593

    Non évaluéeEPSS 0,2%Correctif disponible

    iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX

    In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX get_rso_from_iova() returns NULL when the region-first entry is invalid. Yet in get_rto_from_iova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iova_to_phys() is called on a unmapped IOVA. Fix this by adding the missing NULL check.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  14. CVE-2026-97592

    Non évaluéeEPSS 0,21%Correctif disponible

    s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  15. CVE-2026-97591

    Non évaluéeEPSS 0,2%Correctif disponible

    s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  16. CVE-2026-97590

    Non évaluéeEPSS 0,2%Correctif disponible

    s390/crypto: Fix missing scrub of temp buffers with PAES algorithm

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with PAES algorithm In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  17. CVE-2026-97589

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

    s390/crypto: Fix wrong return code to engine in asynch callbacks

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix wrong return code to engine in asynch callbacks When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_reques

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  18. CVE-2026-97588

    Non évaluéeEPSS 0,2%Correctif disponible

    s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation.

    • Mettez à jour vers 7.2.7-1
    Publication Mise à jour
  19. CVE-2026-97587

    Non évaluéeEPSS 0,21%Correctif disponible

    perf: RISC-V: store available counter mask as bitmap

    In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: store available counter mask as bitmap The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On q

    • Mettez à jour vers 7.2.7-1
    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 →