p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-bos vulnerabilities · Page 191

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

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 6090

  1. CVE-2026-72395

    High · CVSS 7.1EPSS 0.18%No fix published

    hwmon: (pmbus) Fix passing events to regulator core

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix passing events to regulator core Sashiko reports: Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") introduced a worker to batch regulator events over time using atomic_or(). The delayed worker then passes the combined bitmask unmodified to regulator_notifier_call_chain(). The core regulator subsystem's regulator_handle_critical() function evaluates the event parameter using a strict switch statement. If multiple distinct faults occur before the worker runs (e.g., REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CUR

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

  2. CVE-2026-72394

    Not ratedEPSS 0.21%No fix published

    hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-zero

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-zero Sashiko reports: In the aspeed-g6-pwm-tacho driver, the aspeed_tach_val_to_rpm() function calculates the fan RPM using the tachometer value. However, it does not check if the tachometer value is zero before performing the division. If the hardware reports a tachometer value of 0 (which can happen due to an extremely fast pulse, a stuck edge, or a hardware glitch), the calculated tach_div evaluates to 0. The subsequent call to do_div() with tach_div as the divisor triggers a divide-by-zero excepti

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

  3. CVE-2026-72393

    Critical · CVSS 9.8EPSS 0.63%No fix published

    eth: fbnic: don't cache shinfo across skb realloc

    In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327

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

  4. CVE-2026-72392

    Not ratedEPSS 0.22%No fix published

    ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump

    In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 00000

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

  5. CVE-2026-72391

    Not ratedEPSS 0.21%No fix published

    net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy

    In the Linux kernel, the following vulnerability has been resolved: net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(), a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy() only unregisters the bus and clears sfp->i2c_mii without calling mdiobus_free(). As the only reference to the bus is then cleared, the struct mii_bus is leaked. This is hit whenever a copper/RollBall SFP module that instantiated an MDIO bus is removed: sfp_sm_main() takes the global teardown path and calls sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees

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

  6. CVE-2026-72390

    High · CVSS 7.8EPSS 0.17%No fix published

    net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF

    In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF The teql master->slaves singly linked list is not protected against multiple writes. It can be mod'ed concurently from teql_master_xmit(), teql_dequeue(), teql_init() and teql_destroy() without holding any list lock or RCU protection. [email protected] has demonstrated that the qdisc is freed after an RCU grace period, but teql_master_xmit() running on another CPU can still hold a stale pointer into the list, resulting in a slab-use-after-free: BUG: KASAN: slab-use-after-free in teql_m

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

  7. CVE-2026-72389

    High · CVSS 7.8EPSS 0.16%No fix published

    bridge: stp: Fix a potential use-after-free when deleting a bridge

    In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the miss

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

  8. CVE-2026-72388

    Not ratedEPSS 0.21%No fix published

    drm/panthor: Always use the IRQ-safe variant when acquiring the fence lock

    In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Always use the IRQ-safe variant when acquiring the fence lock Since dma_fence objects can be shared with other subsystems, they may be accessed from hardirq context in those drivers, and we have to take that into account by also using the IRQ-safe variant when acquiring the lock. While at it, switch to the guard model.

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

  9. CVE-2026-72387

    Not ratedEPSS 0.21%No fix published

    drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom()

    In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom() If heaps is an ERR_PTR(), panthor_heap_pool_put() will deref an invalid pointer. Make sure we set it to NULL in that case.

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

  10. CVE-2026-72386

    Not ratedEPSS 0.21%No fix published

    drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced

    In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective.

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

  11. CVE-2026-72385

    Not ratedEPSS 0.21%No fix published

    tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()

    In the Linux kernel, the following vulnerability has been resolved: tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry() fprobe_fgraph_entry() sizes a shadow-stack reservation in one walk of the per-ip fprobe list and fills it in a second walk, both under rcu_read_lock() only. A fprobe registered on an already-live ip can become visible between the two walks, so the fill walk processes an exit_handler the sizing walk did not count and used runs past reserved_words. If the sizing walk counted nothing, fgraph_data is NULL and the first write_fprobe_header() faults: Oops: general protection fault, probably for non-canonical

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

  12. CVE-2026-72384

    Not ratedEPSS 0.21%No fix published

    irqchip/ts4800: Fix missing chained handler cleanup on remove

    In the Linux kernel, the following vulnerability has been resolved: irqchip/ts4800: Fix missing chained handler cleanup on remove The driver installs a chained handler for the parent interrupt during probe using irq_set_chained_handler_and_data(), but the remove function does not clear this handler. This leaves a dangling handler that may be called when the parent interrupt fires after the driver has been removed, potentially accessing freed memory and causing a kernel crash. Additionally, the parent_irq obtained via irq_of_parse_and_map() is not stored, making it inaccessible in the remove function. Moreover, interrupt mappings created du

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

  13. CVE-2026-72383

    High · CVSS 7.8EPSS 0.16%No fix published

    sctp: fix addr_wq_timer race in sctp_free_addr_wq()

    In the Linux kernel, the following vulnerability has been resolved: sctp: fix addr_wq_timer race in sctp_free_addr_wq() sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed. This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free. Fix this by calling timer_shutdown_sync() before taking addr_wq_lock. This guarantees that any in-flight timer handler has finish

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

  14. CVE-2026-72382

    High · CVSS 8.8EPSS 0.68%No fix published

    ksmbd: reject undersized DACLs before parsing ACEs

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject undersized DACLs before parsing ACEs parse_dacl() limits the attacker-controlled ACE count by comparing it with the number of minimal ACEs that fit in the DACL size. The DACL size field is 16 bits, but the expression subtracts sizeof(struct smb_acl). Because sizeof() is unsigned, a DACL size smaller than the ACL header underflows to a large size_t. A malicious client can reach this with: SMB2_SET_INFO (InfoType=SMB2_O_INFO_SECURITY) -> smb2_set_info_sec() -> set_info_sec() -> parse_sec_desc() -> parse_dacl() -> init_acl_state(..., 0xffff) -

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

  15. CVE-2026-72381

    Critical · CVSS 9.8EPSS 0.65%No fix published

    ksmbd: fix use-after-free of fp->owner.name in durable handle owner check

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d ("ksmbd: fix durable reconnec

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

  16. CVE-2026-72380

    High · CVSS 8.8EPSS 0.35%No fix published

    xen/pvcalls: bound backend response req_id before indexing rsp[]

    In the Linux kernel, the following vulnerability has been resolved: xen/pvcalls: bound backend response req_id before indexing rsp[] pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >

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

  17. CVE-2026-72379

    Medium · CVSS 4.8EPSS 0.21%No fix published

    fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid

    In the Linux kernel, the following vulnerability has been resolved: fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid vfs_tmpfile() never checked that the caller's fsuid and fsgid map into the filesystem. On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1. Every other creation path already refuses this: may_o_create() (O_CREAT) and may_create_dentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidg

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

  19. CVE-2026-72377

    Not ratedEPSS 0.2%No fix published

    afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints

    In the Linux kernel, the following vulnerability has been resolved: afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). Symlinks and mountpoints in AFS use afs_dir_aops, which does not provide a release_folio callback. However, afs_apply_status() unconditionally calls mapping_set_release_always() for these. In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() whi

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

  20. CVE-2026-72376

    Medium · CVSS 5.7EPSS 0.21%No fix published

    afs: Fix misplaced inc of net->cells_outstanding

    In the Linux kernel, the following vulnerability has been resolved: afs: Fix misplaced inc of net->cells_outstanding Fix net->cells_outstanding being incremented before the check for failure of idr_alloc_cyclic(), leaving the count incremented on error.

    linux-nvidia-bosOperating 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 →