p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-oracle-6.17 · Page n° 189

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8384

  1. CVE-2026-74413

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

    wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers rtw89 stores an ieee80211_hw pointer via pci_set_drvdata() at probe time, but io_error_detected() and io_resume() retrieve it as a net_device pointer. This causes netif_device_detach/attach to operate on an ieee80211_hw struct, reading and writing at wrong offsets. The adjacent io_slot_reset() already does it correctly. Use ieee80211_stop_queues/wake_queues instead, consistent with every other queue stop/start path in the driver. Tested on RTL8852CE by calling the handlers from a test module before and after th

    Publication Mise à jour
  2. CVE-2026-74412

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

    wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers rtw88 stores an ieee80211_hw pointer via pci_set_drvdata() at probe time, but io_error_detected() and io_resume() retrieve it as a net_device pointer. This causes netif_device_detach/attach to operate on an ieee80211_hw struct, reading and writing at wrong offsets. Use ieee80211_stop_queues/wake_queues instead, consistent with every other queue stop/start path in the driver.

    Publication Mise à jour
  3. CVE-2026-74411

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

    wifi: rtw89: Correct data type for scan index to avoid infinite loop

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Correct data type for scan index to avoid infinite loop A kernel soft lockup was observed during Wi-Fi scanning on the 6GHz band. The CPU becomes stuck in rtw89_hw_scan_add_chan_ax for over 20 seconds, leading to a system panic. RIP points to 0f b6 c3 (movzbl %bl, %eax), which zero-extends the low 8 bits of RBX into RAX. RBX (the counter i) has reached a huge value: 0x137466a1. watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u16:4:6124] Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] RIP: 0010:rtw89_hw_scan_add_chan_ax+0xb3/0x6e0 [rt

    Publication Mise à jour
  4. CVE-2026-74410

    Élevée · CVSS 8.1EPSS 0,42%Aucun correctif publié

    wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer si

    Publication Mise à jour
  5. CVE-2026-74409

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

    wifi: rtw89: add bounds check on firmware mac_id in link lookup

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: add bounds check on firmware mac_id in link lookup The mac_id field in RX descriptors is 8 bits wide (0-255), but assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries. While the driver currently assigns mac_id values below 128, the descriptor value comes from firmware and is not validated before use as an array index. Add a defensive bounds check in rtw89_assoc_link_rcu_dereference() to guard against out-of-range firmware values.

    Publication Mise à jour
  6. CVE-2026-74408

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

    wifi: ath9k: fix OOB access from firmware tx status queue ID

    In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.

    Publication Mise à jour
  7. CVE-2026-74407

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

    wifi: ath11k: cancel SSR work items during PCI shutdown

    In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cancel SSR work items during PCI shutdown A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k

    Publication Mise à jour
  8. CVE-2026-74406

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

    vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

    In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().

    Publication Mise à jour
  9. CVE-2026-74405

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

    OPP: Fix race between OPP addition and lookup

    In the Linux kernel, the following vulnerability has been resolved: OPP: Fix race between OPP addition and lookup A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact(): CPU0 (add) CPU1 (lookup) ------------------------------- ------------------------------ _opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get()

    Publication Mise à jour
  10. CVE-2026-74404

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

    crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one

    In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one Sashiko notes: > regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 = 4088, which is <= 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_count > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer. Fix this by accounting for the ent

    Publication Mise à jour
  11. CVE-2026-74402

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

    crypto: atmel-sha204a - fix blocking and non-blocking rng logic

    In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.............

    Publication Mise à jour
  12. CVE-2026-74401

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

    dlm: fix add msg handle in send_queue ordered

    In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue". The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental

    Publication Mise à jour
  13. CVE-2026-74400

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

    bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries

    In the Linux kernel, the following vulnerability has been resolved: bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries bpf_set_dentry_xattr and bpf_remove_dentry_xattr BPF kfuncs attempt to lock the inode of the supplied dentry without checking if it is NULL. If a negative dentry is passed (e.g. from security_inode_create), d_inode(dentry) returns NULL, and inode_lock(inode) will cause a NULL pointer dereference. Trivially fix this by adding a NULL check for inode before attempting to lock it, returning -EINVAL if it is NULL. Additionally, drop WARN_ON(!inode) in bpf_xattr_read_permission() and bpf_xattr_write_permissio

    Publication Mise à jour
  14. CVE-2026-74399

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

    evm: terminate and bound the evm_xattrs read buffer

    In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().

    Publication Mise à jour
  15. CVE-2026-74398

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

    ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD

    In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault:

    Publication Mise à jour
  16. CVE-2026-74397

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

    IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier

    In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked. Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().

    Publication Mise à jour
  17. CVE-2026-74396

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

    RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure

    In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path through mlx5r_umr_unmap_free_xlt(). After mlx5_odp_populate_xlt() became fallible, its error path returned directly and skipped that cleanup. This leaks the XLT DMA mapping and buffer. If the emergency XLT page was used, it also leaves xlt_emergency_page_mutex locked. Break out of the loop so execution falls through the existing cleanup path.

    Publication Mise à jour
  18. CVE-2026-74395

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

    RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference

    In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as wel

    Publication Mise à jour
  19. CVE-2026-74394

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

    RDMA/srpt: fix integer overflow in immediate data length check

    In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.

    Publication Mise à jour
  20. CVE-2026-74393

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

    drm/syncobj: Fix memory leak in drm_syncobj_find_fence()

    In the Linux kernel, the following vulnerability has been resolved: drm/syncobj: Fix memory leak in drm_syncobj_find_fence() Commit 18226ba52159 ("drm/syncobj: reject invalid flags in drm_syncobj_find_fence") forgot to take into account the fact that drm_syncobj_find() takes a reference to syncobj and returns early without dropping the reference, leading to memory leaks. Reported by: Sam Spencer <[email protected]>

    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 →