p PatchFirst

PatchFirst · Vulnérabilités récentes

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

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8340

  1. CVE-2026-74664

    Non évaluéeEPSS 0,18%Correctif disponible

    net: openvswitch: reallocate update replies for mismatched IDs

    In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary ide

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  2. CVE-2026-74663

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

    net/sched: reject overly deep qdisc hierarchies

    In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.

    Publication Mise à jour
  3. CVE-2026-74662

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

    inet: frags: publish queues before arming timer

    In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the

    Publication Mise à jour
  4. CVE-2026-74660

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

    netfilter: ebt_nflog: pin the NFLOG backend

    In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_su

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  5. CVE-2026-74659

    Non évaluéeEPSS 0,17%Correctif disponible

    net: bridge: mrp: fix uninitialised bytes on the wire

    In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with sub_tlv = skb_put(skb, sizeof(*sub_tlv)); sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised byt

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  6. CVE-2026-74658

    Non évaluéeEPSS 0,18%Correctif disponible

    futex: Prevent robust futex exit race some more

    In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commi

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  7. CVE-2026-74657

    Non évaluéeEPSS 0,18%Correctif disponible

    ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops

    In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 n

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  8. CVE-2026-74656

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

    ipv4: fix use-after-free in fib_nhc_update_mtu()

    In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest()

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  9. CVE-2026-74654

    Non évaluéeEPSS 0,18%Correctif disponible

    serial: 8250_dma: Clear stale RX state on shutdown

    In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250_dw: Ensure BUSY is deasserted") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_r

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  10. CVE-2026-74653

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

    serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx

    In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-pa

    Publication Mise à jour
  11. CVE-2026-74651

    Élevée · CVSS 8.1EPSS 0,27%Correctif disponible

    staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()

    In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body l

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  12. CVE-2026-74650

    Non évaluéeEPSS 0,18%Correctif disponible

    staging: rtl8723bs: fix OOB read in WMM_param_handler()

    In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in WMM_param_handler() WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  13. CVE-2026-74649

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

    staging: rtl8723bs: fix missing shared-key auth challenge length check

    In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix missing shared-key auth challenge length check The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  14. CVE-2026-74648

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

    staging: rtl8723bs: validate monitor transmit frame lengths

    In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: validate monitor transmit frame lengths rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated h

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  15. CVE-2026-74647

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

    misc: fastrpc: Remove buffer from list prior to unmap operation

    In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or a

    Publication Mise à jour
  16. CVE-2026-74641

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

    ALSA: usx2y: bound the hwdep mmap fault offset

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: bound the hwdep mmap fault offset snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: offset = vmf->pgoff << PAGE_SHIFT; vaddr = (char *)(...)->us428ctls_sharedmem + offset; page = virt_to_page(vaddr); get_page(page); vmf->page = page; return 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  17. CVE-2026-74637

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

    perf/core: Fix group leader use-after-free after sibling detach

    In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as duri

    Publication Mise à jour
  18. CVE-2026-74636

    Non évaluéeEPSS 0,17%Correctif disponible

    tracing: Fix race between update_event_fields and, event_define_fields

    In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all()

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  19. CVE-2026-74635

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

    fbdev: bitblit: bound-check glyph index in bit_cursor()

    In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_cursor() bit_cursor() fetches the glyph under the cursor with c = scr_readw(vc_pos); src = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without che

    • Mettez à jour vers 5.15.0-1117.124+fips1
    Publication Mise à jour
  20. CVE-2026-74632

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

    mm/huge_memory: fix huge_zero_pfn race

    In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series "mm/huge_memory: fix huge_zero_pfn race", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn()

    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 →