p PatchFirst

PatchFirst · Свежие уязвимости

Уязвимости linux-nvidia-bos · Страница 145

За последние 30 дней в linux-nvidia-bos опубликовано уязвимостей: 1030; в каталоге KEV: 0.

RSS ↗ JSON ↗
Фильтры уязвимостей
Сбросить фильтры

Уязвимостей: 6090

  1. CVE-2026-80876

    Без оценкиEPSS 0,22%Нет опубликованного исправления

    ring-buffer: Fix event length with forced 8-byte alignment

    In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix event length with forced 8-byte alignment When RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length() reserves the space of event->array[0] for placing the data length and rb_update_event() stores the data length in event->array[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally. But ring_buffer_event_length() only subtracts the sizeof(event->array[0]) for events larger than RB_MAX_SMALL_DATA + sizeof(event->array[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALI

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  2. CVE-2026-80875

    Без оценкиEPSS 0,22%Нет опубликованного исправления

    ipvs: use parsed transport offset in TCP state lookup

    In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in TCP state lookup TCP state handling reparses the skb to find the TCP header. For IPv6 it uses sizeof(struct ipv6hdr), while the surrounding IPVS code already parsed the packet with ip_vs_fill_iph_skb() and has the real transport-header offset in iph.len. This makes TCP state handling look at the wrong bytes when an IPv6 packet carries extension headers. Use the parsed transport offset passed down from ip_vs_set_state() when reading the TCP header. For IPv4 and for IPv6 packets without extension headers, the passed offset matches the pr

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  3. CVE-2026-80874

    Без оценкиEPSS 0,2%Нет опубликованного исправления

    arm64: dts: renesas: ironhide: Describe inline ECC carveouts

    In the Linux kernel, the following vulnerability has been resolved: arm64: dts: renesas: ironhide: Describe inline ECC carveouts The DBSC5 DRAM controller protects DRAM content using inline ECC. The inline ECC utilizes areas of DRAM for its operation, which are in the DRAM address range, but must not be accessed or modified. Describe the inline ECC carveout areas used by the DBSC5 controller on this hardware as reserved-memory, which must not be accessed. Include DRAM areas which are unprotected by ECC as well, those are parts of the DRAM which directly precede the ECC carveout. In case of high DRAM utilization, unless the inline ECC carve

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  4. CVE-2026-80873

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions kvm_inject_el2_exception() writes ESR_EL2 for synchronous exceptions but not for SError. enter_exception64() does not write ESR_ELx for any exception type, so the constructed syndrome is dropped. A guest L2 hypervisor taking a nested SError observes stale ESR_EL2. This affects both kvm_inject_nested_serror() and the EASE path in kvm_inject_nested_sea(). Write ESR_EL2 for except_type_serror, matching except_type_sync.

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  5. CVE-2026-80872

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    ALSA: hda/tas2781: Cancel async firmware request at unbind

    In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/tas2781: Cancel async firmware request at unbind TAS2781 HDA I2C and SPI queue RCA firmware loading from component bind with request_firmware_nowait(). The firmware loader keeps the callback module pinned and holds a device reference, but the callback still uses driver-private HDA state. Component unbind removes controls and DSP state immediately. Later device removal tears down the TAS2781 private data, including codec_lock. If the async firmware callback runs after unbind has started, it can operate on state that is being torn down. Cancel or synchronize the a

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  6. CVE-2026-80871

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    crypto: xilinx-trng - Remove crypto_rng interface

    In the Linux kernel, the following vulnerability has been resolved: crypto: xilinx-trng - Remove crypto_rng interface Implementing the crypto_rng interface has no purpose, as it isn't used in practice. It's being removed from other drivers too. Just remove it. This leaves hwrng, which is actually used. Tagging with 'Cc stable' due to the bugs that this removes: - xtrng_trng_generate() sometimes returned success even when it didn't fill in all the bytes. - It was possible for xtrng_trng_generate() and xtrng_hwrng_trng_read() to run concurrently and interfere with each other, as the locking code in xtrng_hwrng_trng_read(

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  7. CVE-2026-80870

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    drm/amdkfd: Validate CRIU-restored IDs before idr_alloc

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Validate CRIU-restored IDs before idr_alloc The KFD CRIU restore flow restores previously saved object IDs from userspace. For event restore: kfd_criu_restore_event() -> create_signal_event() / create_other_event() -> allocate_event_notification_slot() -> idr_alloc(..., *restore_id, *restore_id + 1, ...) For BO restore: criu_restore_memory_of_gpu() -> idr_alloc(..., bo_priv->idr_handle, ...) In both cases, the restored ID comes from userspace-provided CRIU data. idr_alloc() expects the ID range values to fit within s

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  8. CVE-2026-80868

    Без оценкиEPSS 0,2%Нет опубликованного исправления

    ntfs3: Allocate iomap inline_data using alloc_page

    In the Linux kernel, the following vulnerability has been resolved: ntfs3: Allocate iomap inline_data using alloc_page This fixes a BUG reported in iomap_write_end_inline: iomap_inline_data_valid checks that the inline_data fits within a page. If the inline_data is allocated with kmemdup there's no guarantee that it's page-aligned, so the check sometimes fails. Allocate it with alloc_page to ensure it's page-aligned.

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  9. CVE-2026-80867

    Без оценкиEPSS 0,22%Нет опубликованного исправления

    alpha/PCI: Add security_locked_down() check to pci_mmap_resource()

    In the Linux kernel, the following vulnerability has been resolved: alpha/PCI: Add security_locked_down() check to pci_mmap_resource() Currently, Alpha's pci_mmap_resource() does not check security_locked_down(LOCKDOWN_PCI_ACCESS) before allowing userspace to mmap PCI BARs. The generic version has had this check since commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") to prevent DMA attacks when the kernel is locked down. Add the same check to Alpha's pci_mmap_resource().

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  10. CVE-2026-80866

    Средний · CVSS 5.7EPSS 0,21%Нет опубликованного исправления

    tipc: avoid busy looping in tipc_exit_net()

    In the Linux kernel, the following vulnerability has been resolved: tipc: avoid busy looping in tipc_exit_net() Blamed commit introduced a busy-wait loop in tipc_exit_net() to wait for pending UDP bearer cleanup works to complete: while (atomic_read(&tn->wq_count)) cond_resched(); This loop can busy-wait for a long time if cond_resched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In such cases, it wastes CPU cycles and can lead to soft lockups. Fix this by replacing the busy loop with wait_var_event(),

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  11. CVE-2026-80865

    Без оценкиEPSS 0,16%Нет опубликованного исправления

    bpf: Add missing access_ok call to copy_user_syms

    In the Linux kernel, the following vulnerability has been resolved: bpf: Add missing access_ok call to copy_user_syms As reported by sashiko we use __get_user without prior access_ok call on the user space pointer. Adding the missing call for the whole pointer array. Plus removing the err check in the error path, because it's not needed and also we can return -ENOMEM directly from the first kvmalloc_array fail path. [1] https://lore.kernel.org/bpf/20260611115503.AC16D1F00893@smtp.kernel.org/

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  12. CVE-2026-80811

    Без оценкиНет опубликованного исправления

    UBUNTU-CVE-2026-80811

    In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd: fix iovec leak when the async cmd is not recycled An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmd_cache. On two paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without it. io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX == 128 entries, so once it is full the put fails and the vec is left behind. An NVMe passthrough workload gets there without doing anythin

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  13. CVE-2026-80864

    Высокий · CVSS 7.3EPSS 0,2%Нет опубликованного исправления

    RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp

    In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  14. CVE-2026-80863

    Без оценкиEPSS 0,18%Нет опубликованного исправления

    RDMA/rxe: Fix OOB in free_rd_atomic_resources()

    In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: sla

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  15. CVE-2026-80862

    Без оценкиEPSS 0,16%Нет опубликованного исправления

    nvme-tcp: fix usage of page_frag_cache

    In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix usage of page_frag_cache nvme uses page_frag_cache to preallocate PDU for each preallocated request of block device. Block devices are created in parallel threads, consequently page_frag_cache is used in not thread-safe manner. That leads to incorrect refcounting of backstore pages and premature free. That can be catched by !sendpage_ok inside network stack: WARNING: CPU: 7 PID: 467 at ../net/core/skbuff.c:6931 skb_splice_from_iter+0xfa/0x310. tcp_sendmsg_locked+0x782/0xce0 tcp_sendmsg+0x27/0x40 sock_sendmsg+0x8b/0xa0 nvme_tcp_try_send_cmd_pdu+0x149/0x2a

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  16. CVE-2026-80861

    Средний · CVSS 5.1EPSS 0,18%Нет опубликованного исправления

    usb: xhci: bail out of setup if the controller is inaccessible

    In the Linux kernel, the following vulnerability has been resolved: usb: xhci: bail out of setup if the controller is inaccessible xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory.

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  17. CVE-2026-80860

    Без оценкиEPSS 0,16%Нет опубликованного исправления

    fuse: fix race between interrupt and resend

    In the Linux kernel, the following vulnerability has been resolved: fuse: fix race between interrupt and resend After commit f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  18. CVE-2026-80859

    Без оценкиEPSS 0,15%Нет опубликованного исправления

    fuse: fix missing barrier when checking io-uring readiness

    In the Linux kernel, the following vulnerability has been resolved: fuse: fix missing barrier when checking io-uring readiness fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  19. CVE-2026-80858

    Без оценкиEPSS 0,15%Нет опубликованного исправления

    fuse: publish io-uring queues with release semantics

    In the Linux kernel, the following vulnerability has been resolved: fuse: publish io-uring queues with release semantics fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  20. CVE-2026-80857

    Без оценкиEPSS 0,15%Нет опубликованного исправления

    fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free

    In the Linux kernel, the following vulnerability has been resolved: fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free The abort_on_kill path in request_wait_answer() calls fuse_abort_conn() and returns without waiting for FR_FINISHED. If fuse_dev_do_write() is concurrently processing the same request (FR_LOCKED set), the caller frees req->args while it is still being accessed, causing a use-after-free. Fix this by jumping to the existing wait_event(FR_FINISHED) instead of returning early. The wait will not hang because fuse_abort_conn() ensures all requests are ended.

    linux-nvidia-bosОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

Проверьте свой сервер

Сопоставьте установленный стек и версии со свежими базами уязвимостей.

Проверьте свой сервер →