p PatchFirst

PatchFirst · Vulnérabilités récentes

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

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 15186

  1. CVE-2026-97952

    Non évaluéeEPSS 0,18%Correctif disponible

    sunvdc: unmap LDC cookies when the descriptor send fails

    In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failur

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  2. CVE-2026-97951

    Non évaluéeEPSS 0,18%Correctif disponible

    scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands

    In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in targe

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  3. CVE-2026-97950

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

    configfs: pin the symlink target's dirent instead of chasing ->ci_dentry

    In the Linux kernel, the following vulnerability has been resolved: configfs: pin the symlink target's dirent instead of chasing ->ci_dentry create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target(). That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). Take the dirent in get_t

    Publication Mise à jour
  4. CVE-2026-97949

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

    configfs: unhash the dentry before dropping the item in rmdir

    In the Linux kernel, the following vulnerability has been resolved: configfs: unhash the dentry before dropping the item in rmdir configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item. configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned. configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window: BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90 get_target fs/configfs/symlink.c:128 [inline

    Publication Mise à jour
  5. CVE-2026-97948

    Non évaluéeEPSS 0,18%Correctif disponible

    powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver

    In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>]

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  6. CVE-2026-97940

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

    ipv6: fix fib6 walker UAF on seq stop

    In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  7. CVE-2026-97939

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

    ipmr: account multicast table and route memory

    In the Linux kernel, the following vulnerability has been resolved: ipmr: account multicast table and route memory A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count. Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and altern

    Publication Mise à jour
  8. CVE-2026-97938

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

    reboot: fix cad_pid use-after-free race

    In the Linux kernel, the following vulnerability has been resolved: reboot: fix cad_pid use-after-free race cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl

    Publication Mise à jour
  9. CVE-2026-97935

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

    tracing: Set the trace clock before registering the histogram trigger

    In the Linux kernel, the following vulnerability has been resolved: tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_times

    Publication Mise à jour
  10. CVE-2026-97933

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

    tracing: Take trace_array reference when opening a tracer options file

    In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening a tracer options file When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this elemen

    Publication Mise à jour
  11. CVE-2026-97931

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

    ALSA: us122l: Prevent write upgrades for read mappings

    In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size f

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  12. CVE-2026-97930

    Non évaluéeEPSS 0,21%Correctif disponible

    ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array,

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  13. CVE-2026-97929

    Faible · CVSS 2.4EPSS 0,2%Aucun correctif publié

    ALSA: usbusx2y: validate URB actual_length in interrupt callback

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: validate URB actual_length in interrupt callback i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length. A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array. Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB.

    Publication Mise à jour
  14. CVE-2026-97927

    Non évaluéeEPSS 0,21%Correctif disponible

    ufs: create the root dentry after loading cylinder metadata

    In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: sb->s_root = d_make_root(inode); ... if (!sb_rdonly(sb)) if (!ufs_read_cylinder_structures(sb)) goto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_file

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  15. CVE-2026-97926

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

    ufs: validate cylinder group metadata before caching it

    In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  16. CVE-2026-97925

    Non évaluéeEPSS 0,21%Correctif disponible

    tick/broadcast: Plug clockevents replacement race

    In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affi

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  17. CVE-2026-97924

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

    tracing/user_events: Don't destroy fields when event removal fails

    In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Don't destroy fields when event removal fails destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the e

    Publication Mise à jour
  18. CVE-2026-97923

    Non évaluéeEPSS 0,21%Correctif disponible

    tracing: Free histogram the var ref when its initialization fails

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it.

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  19. CVE-2026-97922

    Non évaluéeEPSS 0,21%Correctif disponible

    tracing: Free histogram var refs regardless of how often they are referenced

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram var refs regardless of how often they are referenced Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f ("tracing: Fix histogram code when expression ha

    • Mettez à jour vers 6.1.190-1
    Publication Mise à jour
  20. CVE-2026-97921

    Non évaluéeEPSS 0,21%Correctif disponible

    tracing: Free histogram the field rejected for a bad modifier

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist

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