p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-6.17 vulnerabilities · Page 171

Vulnerabilities published for linux-nvidia-6.17 in the last 30 days: 1109. Listed in the KEV catalogue: 0.

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 8281

  1. CVE-2026-74729

    Not ratedEPSS 0.21%No fix published

    soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read

    In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory expos

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-74728

    Not ratedEPSS 0.21%No fix published

    xfs: handle NULL b_addr in xfs_buf_free

    In the Linux kernel, the following vulnerability has been resolved: xfs: handle NULL b_addr in xfs_buf_free When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash. Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 Fix this by skipping folio_put() when bp->b_ad

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-74727

    Critical · CVSS 9.8EPSS 0.65%Public exploitNo fix published

    ovpn: skip rehash for peers already removed from by_id

    In the Linux kernel, the following vulnerability has been resolved: ovpn: skip rehash for peers already removed from by_id ovpn_nl_peer_set_doit() resolves the target peer via ovpn_peer_get_by_id() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpn_peer_remove() to unhash the peer from all four tables (by_id, by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which re-inserts the now-

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-74726

    High · CVSS 7.3EPSS 0.13%No fix published

    bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor

    In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it fa

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-74725

    High · CVSS 7.8EPSS 0.12%No fix published

    enic: fix tx_hang_reset use-after-free on device removal

    In the Linux kernel, the following vulnerability has been resolved: enic: fix tx_hang_reset use-after-free on device removal enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work(

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-74724

    High · CVSS 7.8EPSS 0.12%No fix published

    ipvs: avoid out-of-bounds write in ip_vs_nat_icmp

    In the Linux kernel, the following vulnerability has been resolved: ipvs: avoid out-of-bounds write in ip_vs_nat_icmp Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once.

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-74723

    Critical · CVSS 9.8EPSS 0.49%No fix published

    btrfs: lzo: reject inline extents without valid headers

    In the Linux kernel, the following vulnerability has been resolved: btrfs: lzo: reject inline extents without valid headers [BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent: BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77 Call Trace: <TASK> dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-74722

    Not ratedEPSS 0.17%No fix published

    btrfs: fix memory leak in btrfs_do_encoded_write()

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmall

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-74721

    High · CVSS 7.8EPSS 0.17%No fix published

    accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()

    In the Linux kernel, the following vulnerability has been resolved: accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages() Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma) before returning an error code to the caller. This is incorrect: amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo that registration. Calling vm_ops->close() manually — which drops the shmem pages_pin_count and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2026-74720

    High · CVSS 7.8EPSS 0.13%No fix published

    bpf: Preserve pointer state for commuted arithmetic

    In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-74719

    Not ratedEPSS 0.18%No fix published

    net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()

    In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SM

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-74718

    Not ratedEPSS 0.17%No fix published

    devlink: fix net namespace reference leak in reload

    In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-74717

    High · CVSS 7.5EPSS 0.5%No fix published

    net/mlx5: fw_tracer, return NULL on create error

    In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-74716

    Not ratedEPSS 0.21%No fix published

    accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()

    In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages() In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM object and then calls madvise(MADV_DONTNEED), the PTEs will be successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP). When userspace subsequently accesses the memory, drm_gem_shmem_fault() handles the page fault and attempts to map the backing shmem page via vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing shmem page is n

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-74715

    High · CVSS 7.8EPSS 0.13%No fix published

    bpf: Fix netns reference imbalance in conntrack kfuncs

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix netns reference imbalance in conntrack kfuncs The opts argument of the BPF conntrack kfuncs can point to a shared map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference. The reference imbalance can occur as follows: CPU 0 CPU 1 read opts->netns_id (-1) skip get_net_ns_by_id() write opts->netns_id (id) read opts->netns_id (id) put_net(net) /* no matching get */ The reverse transitio

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-74714

    High · CVSS 7.8EPSS 0.13%No fix published

    bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()

    In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 -----

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-74713

    High · CVSS 7.1EPSS 0.14%No fix published

    vhost_iotlb: bound map allocation in add_range

    In the Linux kernel, the following vulnerability has been resolved: vhost_iotlb: bound map allocation in add_range vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive val

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-74712

    Critical · CVSS 9.3EPSS 0.14%No fix published

    vdpa/mlx5: Fix buffer length in create_direct_keys()

    In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte reg

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-74711

    High · CVSS 8.4EPSS 0.2%No fix published

    hwmon: (pmbus) Fix type confusion in notification logic

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix type confusion in notification logic Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmb

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-74710

    High · CVSS 7.8EPSS 0.13%No fix published

    xsk: require at least 16 bytes of TX metadata

    In the Linux kernel, the following vulnerability has been resolved: xsk: require at least 16 bytes of TX metadata AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata.

    linux-nvidia-6.17Operating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →