Export limit exceeded: 26147 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26147 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-74319 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock waiting for ticket during data relocation When performing data relocation on a zoned filesystem, BTRFS can deadlock in handle_reserve_tickets(). The relocation process is waiting on a space reservation ticket that can never be fulfilled, because the relocation itself is the operation responsible for freeing up that space. Fix this by introducing a new flush state, BTRFS_RESERVE_FLUSH_ZONED_RELOCATION, specifically for data chunk allocation during zoned relocation. Like BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE, this state uses priority_reclaim_data_space() instead of the normal flushing path, which avoids re-entering the relocation code and breaking the deadlock cycle. In btrfs_alloc_data_chunk_ondemand(), select this new flush state when the inode belongs to a data relocation root on a zoned filesystem. | ||||
| CVE-2026-74309 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 10 Critical |
| In the Linux kernel, the following vulnerability has been resolved: vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler Look up the IRQ index in oct_hw->irqs instead of assuming irq - irqs[0]. This supports non-contiguous IRQ numbers and avoids incorrect ring indexing when irqs[0] is not the base. | ||||
| CVE-2026-74326 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix resource leak in probe error path When pcim_iomap_region() or devm_kmemdup() fail, the code returns directly without cleaning up previously allocated resources: - mt76_device allocated by mt76_alloc_device() - pci irq vectors allocated by pci_alloc_irq_vectors() Fix this by jumping to the existing error cleanup path instead of returning directly. | ||||
| CVE-2026-74328 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommufd: Destroy the pages content after detaching from dmabuf Sashiko points out this has gotten out of order, the mutex could still be in use through the dmabuf invalidation callbacks. Don't destroy any of the pages content until the dmabuf is fully detached. | ||||
| CVE-2026-74352 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails The global pointer 'reserved_mem' continues to reference the reserved_mem_array which lives in __initdata if alloc_reserved_mem_array() fails. of_reserved_mem_lookup() is exported for post-init use, that would dereference freed memory and trigger a use-after-free. So reset reserved_mem_count to 0 when alloc_reserved_mem_array() fails. | ||||
| CVE-2026-74353 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: always resume_all after suspend_all Need to restore any good queues even if the suspend_all failed for some. Always run remove_queue as that will schedule a GPU reset is removing the queue fails. v2: move resume_all after remove | ||||
| CVE-2026-74358 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix fast commit wait/wake bit mapping on 64-bit On 64-bit, ext4 dynamic inode states live in the upper half of i_flags, and ext4_test_inode_state() applies the corresponding +32 offset. The fast-commit wait and wake paths open-coded the wait key with the raw EXT4_STATE_* value. Add small helpers for the state wait word and bit, and use them for the FC_COMMITTING and FC_FLUSHING_DATA waits so the wait key follows the same mapping as the state helpers. | ||||
| CVE-2026-74342 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: kernfs: link kn to its parent before the LSM init hook After commit 12e9e3cd03b5 ("simpe_xattr: use per-sb cache"), kernfs_xattr_set() and kernfs_xattr_get() compute the cache via kernfs_root(kn) before any other check. kernfs_root(kn) walks kn->__parent first and falls back to kn->dir.root, both of which are NULL on a freshly kmem_cache_zalloc()'d kn. kn->__parent was being set in kernfs_new_node() after __kernfs_new_node() returned, and kn->dir.root is set even later by kernfs_create_dir_ns() / kernfs_create_empty_dir(). The LSM kernfs_init_security hook is invoked from inside __kernfs_new_node(), before either field has been initialized. selinux_kernfs_init_security() ends with kernfs_xattr_set(kn, XATTR_NAME_SELINUX, ...). kernfs_root(kn) then returns NULL, and &((struct kernfs_root *)NULL)->xa_cache evaluates to offsetof(struct kernfs_root, xa_cache) which faults: BUG: kernel NULL pointer dereference, address: 00000000000000e0 RIP: 0010:simple_xattr_set+0x27/0x8b0 Call Trace: kernfs_xattr_set+0x63/0xb0 selinux_kernfs_init_security+0x13b/0x270 security_kernfs_init_security+0x36/0xc0 __kernfs_new_node+0x182/0x290 kernfs_new_node+0x80/0xc0 kernfs_create_dir_ns+0x2b/0xa0 cgroup_create+0x116/0x380 cgroup_mkdir+0x7c/0x1a0 Reproduces deterministically at PID 1 (systemd) on an SELinux-enabled distro. The first cgroup mkdir under /sys/fs/cgroup with a labelled parent panics the kernel. The LSM hook's contract is that the kn_dir argument is the parent of the new kn, so kn->__parent should already point at kn_dir when the hook runs. Move kernfs_get(parent) and rcu_assign_pointer of kn->__parent from kernfs_new_node() into __kernfs_new_node() right before the security hook, and unwind the parent reference on the err_out4 path. kernfs_root(kn) then takes its parent branch during the hook and returns parent->dir.root, which is the correct root. This also closes the same-shape latent bug in kernfs_xattr_get() (which today is hidden only by kernfs_iattrs_noalloc() returning NULL on a fresh kn). | ||||
| CVE-2026-74360 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Reject exclusive maps for bpf_map_elem iterators Exclusive maps (aka excl_prog_hash) are meant to be reachable only from the single program whose hash matches. This is enforced by check_map_prog_compatibility() when the map is referenced from a program such as signed BPF loaders. A bpf_map_elem iterator, however, binds its target map at attach time in bpf_iter_attach_map() instead of referencing it from the program, so the exclusivity check is never reached. On top of that, the iterator exposes the map value as a writable buffer. | ||||
| CVE-2026-74362 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext2: fix ignored return value of generic_write_sync() Fix ext2_dio_write_iter() to propagate the error returned by generic_write_sync() instead of silently discarding it, which could cause write(2) to return success to userspace on O_SYNC/O_DSYNC files even when the sync failed. The correct pattern, already used in ext2_dax_write_iter() in the same file and in ext4, xfs, f2fs among others, is: if (ret > 0) ret = generic_write_sync(iocb, ret); Found by Linux Verification Center (linuxtesting.org) with SVACE. [JK: Reflect also filemap_write_and_wait() return value] | ||||
| CVE-2026-74381 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Allow entries in BO caches to be freed When a buffer object is pinned via host1x_bo_pin() with a cache, the resulting mapping is kept in the cache so it can be reused on subsequent pins. Each mapping held a reference to the underlying host1x_bo (taken in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached, the bo itself could not be freed. However, the only way to remove the cached mapping was through the free path of the buffer object. This meant that if a bo got cached, it could never get freed again. Resolve the circularity by holding a weak reference to the bo from the cache side. This is done by having the .pin callbacks not bump the bo's refcount -- instead the common Host1x bo code does so, except for the cache reference. Also move the remove-cache-mapping-on-free code into a common function inside Host1x code. This is only called from the TegraDRM GEM buffers since those are the only ones that can be cached at the moment. | ||||
| CVE-2026-74370 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: liveupdate: fix TOCTOU race in luo_session_retrieve() Extend the scope of the rwsem_read lock in luo_session_retrieve() to overlap with the acquisition of the session mutex. This prevents a concurrent thread from releasing and freeing the session between the lookup and the mutex lock. | ||||
| CVE-2026-74372 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path In raid1_write_request(), each per-mirror loop iteration begins by incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a badblock within the requested range, the code jumps to err_handle without dropping the reference taken for the current mirror. err_handle's cleanup loop will only decrements for k < i and r1_bio->bios[k] is non-NULL. The current slot is therefore skipped, leaving its nr_pending reference leaked permanently. The reference prevents the rdev from ever being removed, since raid1_remove_conf() refuses to remove an rdev with nr_pending > 0. Fix this by calling rdev_dec_pending() before jumping to err_handle. | ||||
| CVE-2026-74383 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools nvme_setup_descriptor_pools() indexes dev->descriptor_pools[] using the numa_node forwarded from hctx->numa_node by its single caller, nvme_init_hctx_common(). On a non-NUMA kernel hctx->numa_node is NUMA_NO_NODE (-1). Because the parameter was declared 'unsigned', the value becomes UINT_MAX and the index walks off the array (sized to nr_node_ids), faulting during nvme_alloc_ns() and leaving the namespace without a /dev node. Reproduces on any NVMe controller probed by a CONFIG_NUMA=n kernel: BUG: unable to handle page fault for address: ffff889101603d38 RIP: 0010:nvme_init_hctx_common+0x5a/0x190 [nvme] Call Trace: nvme_init_hctx+0x10/0x20 [nvme] nvme_alloc_ns+0x9e/0xa10 [nvme_core] nvme_scan_ns+0x301/0x3b0 [nvme_core] nvme_scan_ns_async+0x23/0x30 [nvme_core] Switch the parameter to int and fall back to node 0 when it is NUMA_NO_NODE; node 0 is always present. | ||||
| CVE-2026-74369 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: liveupdate: fix u-a-f in luo_file_unpreserve_files() and luo_file_finish() In luo_file_unpreserve_files() and luo_file_finish(), reorder module_put() and xa_erase() to ensure the file handler module remains pinned while its operations are being accessed. Specifically, luo_get_id() dereferences fh->ops->get_id, so the module reference must be held until after xa_erase() (which calls luo_get_id) completes. For luo_file_finish(), this requires moving the module_put() call out of the luo_file_finish_one() helper and into the main loop of luo_file_finish() itself. | ||||
| CVE-2026-74392 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm: limit target bio polling to one shot dm_poll_bio() is the ->poll_bio() callback for a stacked dm device. The caller only knows about the dm queue, so it may decide to do a spinning poll if it thinks a single queue is being polled. Passing those flags unchanged to the mapped clone lets blk_mq_poll() spin on a target queue from inside dm_poll_bio(). With io_uring IOPOLL on a dm-stripe target this can keep a task in dm_poll_bio() -> bio_poll() -> blk_mq_poll() long enough to trigger an RCU CPU stall, before io_uring gets back to io_iopoll_check() and its need_resched() check. Keep dm's ->poll_bio() bounded by forcing one-shot polling for target bios. The caller can invoke dm_poll_bio() again if it wants to keep polling, and it also gets a chance to reap completions or reschedule between passes. | ||||
| CVE-2026-74393 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/syncobj: Fix memory leak in drm_syncobj_find_fence() Commit 18226ba52159 ("drm/syncobj: reject invalid flags in drm_syncobj_find_fence") forgot to take into account the fact that drm_syncobj_find() takes a reference to syncobj and returns early without dropping the reference, leading to memory leaks. Reported by: Sam Spencer <sam.spencer@arm.com> | ||||
| CVE-2026-74419 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Adjust size for copy_to_user() The amount of data returned to user space should be limited by the buffer size provided by the application. If the buffer is smaller than the data size, return only the portion that fits instead of failing. | ||||
| CVE-2026-74423 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix leak when pinning ubuf pages When pin_user_pages_fast() returns fewer pages than requested, the pages that were successfully pinned are not released, leading to a leak. Fix this by unpinning any partially pinned pages before returning failure. | ||||
| CVE-2026-74420 | 1 Linux | 1 Linux Kernel | 2026-08-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges VMAs marked with VM_IO or VM_PFNMAP are not backed by struct page objects, which GPUSVM requires in order to operate correctly. In particular, get_pages() relies on hmm_range_fault() to resolve struct pages for the target range. Attempting to create an SVM range on such VMAs results in repeated get_pages() failures and can lead to an infinite loop inside a driver’s page‑fault handler. Prevent this by rejecting ranges on VM_IO or VM_PFNMAP VMAs and returning -EIO. | ||||