p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-lowlatency vulnerabilities · Page 192

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

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 9858

  1. CVE-2026-64108

    High · CVSS 7.8EPSS 0.13%Fix available

    cifs: Fix busy dentry used after unmounting

    In the Linux kernel, the following vulnerability has been resolved: cifs: Fix busy dentry used after unmounting Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry ref_cnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in generic_shutdown_super: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs] The detailed processs is: process A process B kworker fd = open(PATH) vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_filei

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-64106

    Critical · CVSS 9EPSS 0.15%Fix available

    KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-64103

    High · CVSS 7.8EPSS 0.13%Fix available

    scsi: isci: Fix use-after-free in device removal path

    In the Linux kernel, the following vulnerability has been resolved: scsi: isci: Fix use-after-free in device removal path The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() returns the IRQ handlers can still requeue the tas

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-64102

    Critical · CVSS 9.8EPSS 0.5%Fix available

    RDMA/siw: Reject MPA FPDU length underflow before signed receive math

    In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Reject MPA FPDU length underflow before signed receive math A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equal

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-64099

    High · CVSS 7.8EPSS 0.13%Fix available

    drm/v3d: Fix use-after-free of CPU job query arrays on error path

    In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix use-after-free of CPU job query arrays on error path The CPU job ioctl's fail label calls kvfree() on cpu_job's timestamp and performance query arrays after v3d_job_cleanup(), which drops the job's last reference and frees cpu_job. Reading cpu_job at that point is a use-after-free. Also, on the early v3d_job_init() failure path, it is a NULL dereference, since v3d_job_deallocate() zeroes the local pointer. In the success path, the arrays are released from the scheduler's .free_job callback, but on the error path, they are freed manually, as the job was never p

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1064.67.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-64098

    High · CVSS 7.8EPSS 0.11%Fix available

    drm/virtio: use uninterruptible resv lock for plane updates

    In the Linux kernel, the following vulnerability has been resolved: drm/virtio: use uninterruptible resv lock for plane updates virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held()

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-64097

    High · CVSS 7.8EPSS 0.13%Fix available

    drm/amd/display: Validate GPIO pin LUT table size before iterating

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate GPIO pin LUT table size before iterating [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the ful

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-64096

    High · CVSS 8.8EPSS 0.26%Fix available

    batman-adv: mcast: fix use-after-free in orig_node RCU release

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: fix use-after-free in orig_node RCU release batadv_mcast_purge_orig() removes entries from RCU-protected hlists but does not wait for an RCU grace period before returning. Concurrent RCU readers may still accesses references to those entries at the point of removal. RCU-protected readers trying to operate on entries like orig->mcast_want_all_ipv6_node will then access already freed memory. Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(), just before the call_rcu() invocation. This ensures RCU readers that were active at purge t

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-64095

    High · CVSS 7.1EPSS 0.27%Fix available

    batman-adv: bla: avoid double decrement of bla.num_requests

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid double decrement of bla.num_requests The bla.num_requests is increased when no request_sent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the request_sent is actually set to a specific state and the atomic_dec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently. At the same time, it is necessary to modify request_sent (state) and bla.num_requests atomically. Otherwise batadv_bla_send_request() might set r

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1064.67.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2026-64094

    Medium · CVSS 5.5EPSS 0.15%Fix available

    batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface Without rtnl_lock held, a hardif might be retrieved as primary interface of a meshif, but then (while operating on this interface) getting decoupled from the mesh interface. In this case, the meshif still exists but the pointer from the primary hardif to the meshif is set to NULL. The mesh_iface must be checked first to be non-NULL before continuing to send an ARP request using meshif.

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1064.67.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-64093

    High · CVSS 8.8EPSS 0.35%Fix available

    batman-adv: tp_meter: directly shut down timer on cleanup

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: directly shut down timer on cleanup batadv_tp_sender_cleanup() was calling timer_delete_sync() followed by timer_delete() to guard against the timer handler re-arming itself between the two calls. This double-deletion hack relied on the sending status being set to 0 to suppress re-arming. Replace both calls with a single timer_shutdown_sync(). This function both waits for any running timer callback to complete (like timer_delete_sync()) and permanently disarms the timer so it cannot be re-armed afterwards, making re-arming prevention unconditional and

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1064.67.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-64092

    Medium · CVSS 5.5EPSS 0.13%Fix available

    batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all()

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-64091

    Critical · CVSS 9.8EPSS 0.43%Fix available

    batman-adv: tt: fix TOCTOU race for reported vlans

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the nu

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1063.66.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-64090

    Medium · CVSS 5.5EPSS 0.13%Fix available

    batman-adv: tt: avoid empty VLAN responses

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid empty VLAN responses The commit 16116dac2339 ("batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs") added checks to the local (direct) TT response code. But the response can also be done indirectly by another node using the global TT state. To avoid such inconsistency states reported in the original fix, also avoid sending empty VLANs for replies from the global TT state.

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1064.67.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-64089

    Critical · CVSS 9.8EPSS 0.55%Fix available

    batman-adv: tt: fix negative last_changeset_len

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix negative last_changeset_len batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialize

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-64088

    High · CVSS 8.8EPSS 0.28%Fix available

    batman-adv: tt: fix negative tt_buff_len

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix negative tt_buff_len batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 a

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-64087

    Medium · CVSS 5.5EPSS 0.13%Fix available

    hwmon: (pmbus/adm1266) reject implausible blackbox record_count

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) reject implausible blackbox record_count adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap rec

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-64086

    High · CVSS 7.8EPSS 0.14%Fix available

    hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer adm1266_pmbus_block_xfer() sets up the read transaction with .buf = data->read_buf, .len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc != msgs[1].buf[msgs[1].buf[0] + 1])

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-64085

    High · CVSS 7.8EPSS 0.14%Fix available

    hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length: memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]); The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLO

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-64084

    High · CVSS 7.8EPSS 0.14%Fix available

    hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a h

    linux-nvidia-lowlatencyOperating systems
    • Update to 6.8.0-1062.65.1
    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 →