p PatchFirst

PatchFirst · Vulnérabilités récentes

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

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8790

  1. CVE-2026-89582

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

    bnx2x: fix double free in bnx2x_init_firmware() error path

    In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-o

    Publication Mise à jour
  2. CVE-2026-89580

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

    bpf: Disable preemption in __bpf_get_stack

    In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in __bpf_get_stack get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below. A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->

    Publication Mise à jour
  3. CVE-2026-89576

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

    dm-era: fix shadowed superblock leak on take-snap failure

    In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().

    Publication Mise à jour
  4. CVE-2026-89575

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

    dm raid1: reserve space for NUL-terminator in build_constructor_string()

    In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().

    Publication Mise à jour
  5. CVE-2026-89574

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

    dm array: validate array block headers on read

    In the Linux kernel, the following vulnerability has been resolved: dm array: validate array block headers on read array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: rejec

    Publication Mise à jour
  6. CVE-2026-89573

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

    dm array: reject an array block whose value size is not the caller's

    In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() ar

    Publication Mise à jour
  7. CVE-2026-89569

    Élevée · CVSS 8.8EPSS 0,34%Aucun correctif publié

    Bluetooth: RFCOMM: serialize security confirmation handling

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink()

    Publication Mise à jour
  8. CVE-2026-89565

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

    ipip: fix skb leak in collect_md mode when metadata_dst allocation fails

    In the Linux kernel, the following vulnerability has been resolved: ipip: fix skb leak in collect_md mode when metadata_dst allocation fails In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv()

    Publication Mise à jour
  9. CVE-2026-89563

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

    ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()

    In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases

    Publication Mise à jour
  10. CVE-2026-89562

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

    ip6_gre: fix hardware header length for NBMA tunnels

    In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed

    Publication Mise à jour
  11. CVE-2026-89559

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

    libnvdimm/labels: Prevent integer overflow in __nd_label_validate()

    In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted --

    Publication Mise à jour
  12. CVE-2026-89557

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

    md: do overflow check for sb->bblog_shift in super_1_load()

    In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 19

    Publication Mise à jour
  13. CVE-2026-89555

    Critique · CVSS 9.8EPSS 0,69%Aucun correctif publié

    mpls: reload header after pskb_may_pull()

    In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to fr

    Publication Mise à jour
  14. CVE-2026-89553

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

    nouveau/gem: reserve the bo in the info ioctl around the vma lookup

    In the Linux kernel, the following vulnerability has been resolved: nouveau/gem: reserve the bo in the info ioctl around the vma lookup In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free. Spotted with the help of Opus 4.6.

    Publication Mise à jour
  15. CVE-2026-89552

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

    params: fix charp corruption on allocation failure

    In the Linux kernel, the following vulnerability has been resolved: params: fix charp corruption on allocation failure param_set_charp() stores charp parameters in allocated memory after slab is available, and releases the previous value when the parameter is updated. The previous value is released before the replacement allocation succeeds. If kmalloc_parameter() fails, the setter returns -ENOMEM with the parameter left as NULL. Failing zswap's compressor update before zswap is initialized can later trigger: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strcmp+0x10/0x30 Call Trace: zswap_setup+0x3b1

    Publication Mise à jour
  16. CVE-2026-89551

    Critique · CVSS 9.8EPSS 0,51%Aucun correctif publié

    SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow

    In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps

    Publication Mise à jour
  17. CVE-2026-89550

    Critique · CVSS 9.8EPSS 0,49%Aucun correctif publié

    SUNRPC: svcauth_gss: enforce krb5 token minimum length

    In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which

    Publication Mise à jour
  18. CVE-2026-89549

    Élevée · CVSS 7.5EPSS 0,71%Aucun correctif publié

    sunrpc: route to a populated pool in svc_pool_for_cpu()

    In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in "pernode" or "percpu" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread serv

    Publication Mise à jour
  19. CVE-2026-89548

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

    SUNRPC: always drain cache_cleaner before destroying a cache_detail

    In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put a

    Publication Mise à jour
  20. CVE-2026-89545

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

    sunrpc: defer rq_argp and rq_resp free until after RCU grace period

    In the Linux kernel, the following vulnerability has been resolved: sunrpc: defer rq_argp and rq_resp free until after RCU grace period svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu(). After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free. Fix this by moving the kfree of rq_argp and rq_resp in

    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 →