p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-nvidia-bos · Page n° 3

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 6048

  1. CVE-2026-99164

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

    spi: imx: fix slab corruption from undersized DMA bounce buffers

    In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix slab corruption from undersized DMA bounce buffers Since commit faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode"), the driver allocates its private DMA TX/RX buffers with kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but maps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e. rounded up to the cache line size. As a result, the DMA API operates on memory beyond the end of the allocation. This was observed on a custom i.MX8MP platform with an mcp251xfd CAN controller under heavy RPMSG load, as a series of

    Publication Mise à jour
  2. CVE-2026-99163

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

    tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields

    In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields In check_synth_field(), when a synthetic event field is a stacktrace (field->is_stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison. Because parse_synth_field() sets a stacktrace field's type to "__data_loc unsigned long[]", its size is sizeof(u64) and synth_field_signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently

    Publication Mise à jour
  3. CVE-2026-99162

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

    gpio: shared: fix use-after-free bug when adding shared proxies

    In the Linux kernel, the following vulnerability has been resolved: gpio: shared: fix use-after-free bug when adding shared proxies The GPIO lookup table can stay alive for longer than the kobject whose name string's address we're assigning to lookup->dev_id. Fix a potential UAF by duplicating the string.

    Publication Mise à jour
  4. CVE-2026-99161

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

    i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe()

    In the Linux kernel, the following vulnerability has been resolved: i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe() In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak. Switch to devm_clk_get() so that the clock is automatically managed and released.

    Publication Mise à jour
  5. CVE-2026-99160

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

    ring-buffer: Do not show buffer_meta for CPUs without a buffer

    In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not show buffer_meta for CPUs without a buffer The per_cpu/cpuN/buffer_meta files are created for every possible CPU, but buffer->buffers[cpu] is only allocated once that CPU comes online. Reading the file of a CPU that never came online dereferences a NULL cpu_buffer in rbm_start(). Fail the open with -ENODEV when the CPU has no buffer, as the other per CPU ring buffer interfaces do.

    Publication Mise à jour
  6. CVE-2026-99159

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

    ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx()

    In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[] shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma() dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader() writes two such indices into meta->buffers[], which rb_cpu_meta_valid() would reject on the next boot, discarding the previous boot's trace. A CPU's sub-buffer array starts after its meta header and the nr_subbufs integers tha

    Publication Mise à jour
  7. CVE-2026-99158

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

    ring-buffer: Fix false warning in ring_buffer_map_get_reader()

    In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix false warning in ring_buffer_map_get_reader() The mmap reader can warn when it catches up with a writer that is still committing events. rb_get_reader_page() returns NULL in this case, but ring_buffer_map_get_reader() treats that result as an error. The initial rb_per_cpu_empty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take reader_lock and can advance commit_page before publishing the committed length on the new page. rb_get_reader_page() can swap to that page, catch up with

    Publication Mise à jour
  8. CVE-2026-99157

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

    scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies

    In the Linux kernel, the following vulnerability has been resolved: scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after the 40-byte header and writes 8 bytes past the end of the buffer. Let each BSG transport pass its reply buffer size to bsg_setup_queue() and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full reply reaches user space. O

    Publication Mise à jour
  9. CVE-2026-99156

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

    scsi: st: Fix use-after-free race between st_remove() and st_open()

    In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix use-after-free race between st_remove() and st_open() st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove()

    Publication Mise à jour
  10. CVE-2026-99155

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

    scsi: xen/scsifront: Check for a NULL shadow entry on a backend response

    In the Linux kernel, the following vulnerability has been resolved: scsi: xen/scsifront: Check for a NULL shadow entry on a backend response scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NU

    Publication Mise à jour
  11. CVE-2026-99154

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

    scsi: libiscsi: Reject a negative task index from parse_pdu_itt

    In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Reject a negative task index from parse_pdu_itt A transport that implements parse_pdu_itt hands libiscsi an index taken from the PDU, and both lookups bound it from above only: if (i >= session->cmds_max) i and cmds_max are both int, so a negative index passes and session->cmds[i] is read from before the array. be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt; and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also

    Publication Mise à jour
  12. CVE-2026-99153

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

    scsi: libiscsi: Validate the ITT reflected in a Reject PDU

    In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Validate the ITT reflected in a Reject PDU A Reject PDU carries a copy of the header it rejects, and iscsi_handle_reject() takes the ITT out of that copy to find the task to clean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt); That value is whatever the target put there. iscsi_itt_to_task() bounds the index against cmds_max and checks nothing else, so any task in the pool can be named, and iscsi_nop_out_rsp() then completes it. An index that has never been used gives a NUL

    Publication Mise à jour
  13. CVE-2026-99152

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

    scsi: libiscsi: Validate the task named by a management response

    In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Validate the task named by a management response __iscsi_complete_pdu() fetches the task for five response types from one place and checks only that the index resolved: case ISCSI_OP_LOGOUT_RSP: case ISCSI_OP_LOGIN_RSP: case ISCSI_OP_TEXT_RSP: case ISCSI_OP_SCSI_TMFUNC_RSP: case ISCSI_OP_NOOP_IN: task = iscsi_itt_to_task(conn, hdr->itt); if (!task) return ISCSI_ERR_BAD_ITT; iscsi_itt_to_task() bounds the index against cmds_max and looks at nothing else, so a target can name any

    Publication Mise à jour
  14. CVE-2026-99150

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

    drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and cop

    Publication Mise à jour
  15. CVE-2026-99149

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

    drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e)

    Publication Mise à jour
  16. CVE-2026-99148

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

    drm/amdgpu: keep the eviction fence until the last handle is closed

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: keep the eviction fence until the last handle is closed amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses i

    Publication Mise à jour
  17. CVE-2026-99147

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

    drm/exec: don't immediately add prelocked obj to array of locked objs

    In the Linux kernel, the following vulnerability has been resolved: drm/exec: don't immediately add prelocked obj to array of locked objs When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked

    Publication Mise à jour
  18. CVE-2026-99146

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

    drm/i915/dmc: Add sanity check for DMC load address

    In the Linux kernel, the following vulnerability has been resolved: drm/i915/dmc: Add sanity check for DMC load address For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c)

    Publication Mise à jour
  19. CVE-2026-99143

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

    tracing: Keep the predicate limit separate from program capacity

    In the Linux kernel, the following vulnerability has been resolved: tracing: Keep the predicate limit separate from program capacity predicate_parse() adds two to nr_preds to reserve the terminal TRUE and FALSE entries. It also uses that increased value as the limit for parsed predicates. If the initial count is smaller than the number actually parsed, the program can fill the allocation and subsequent accesses can go past its end. Keep nr_preds as the predicate limit and use a separate value for the allocation size. This leaves space for both terminal entries and a zeroed entry when parsing stops at the limit.

    Publication Mise à jour
  20. CVE-2026-99142

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

    tracing: Check operator stack capacity before pushing

    In the Linux kernel, the following vulnerability has been resolved: tracing: Check operator stack capacity before pushing predicate_parse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack. Reject the push when top reaches the last allocated entry.

    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 →