Export limit exceeded: 380514 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (380514 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72179 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: riscv: cacheinfo: Fix node reference leak in populate_cache_leaves Currently, the while loop drops the reference to prev in each iteration. If the loop terminates early due to a break, the final of_node_put(np) correctly drops the reference to the current node. However, if the loop terminates naturally because np == NULL, calling of_node_put(np) is a no-op. This leaves the last valid node stored in prev without its reference dropped, resulting in a node reference leak. Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`. | ||||
| CVE-2026-72178 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: always put unsuccessfully committed target pids damon_commit_target() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damon_destroy_ctx() after damon_commit_ctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanup_target() callback will put the pids. The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damon_commit_ctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice. The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanup_target() ops callback, so it cannot put the pids via the damon_destroy_ctx(). As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damon_commit_target() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions. Fix by putting the pids in the commit operation in case of the failures. The issue was discovered [2] by Sashiko. | ||||
| CVE-2026-72177 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs() Patch series "mm/damon/sysfs-schemes: fix wrong directories put orders in error paths". Error paths of damon_sysfs_access_pattern_add_dirs() and damon_sysfs_scheme_add_dirs() functions put references to directories in wrong orders. As a result, uninitialized memory dereference and/or memory leak can happen. Fix those. This patch (of 2): In access_pattern_add_dirs(), error handling path puts references starting from setup failed directories. If the failure happpened from the initial allication in the setup functions, uninitialized memory dereference happen. The allocation failures will not commonly happen, but the consequence is quite bad. Fix the wrong reference put orders. The issue was discovered [1] by Sashiko. | ||||
| CVE-2026-72176 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error damon_sysfs_scheme_add_dirs() setup the tried_regions directory after the stats directory setup is completed. When the tried_regions directory setup is failed, the setup function ensures the reference for the tried regions directory is released. Hence the error path should put references on setup succeeded directory objects, starting from the stats directory. However, the error path is putting the tried_regions directory instead of the stats directory. As a direct result, the stats directory object is leaked. Worse yet, if the tried_regions directory setup failed from the initial allocation, the scheme->tried_regions field remains uninitialized. The following kobject_put(&scheme->tried_regions->kobj) call in the error path will dereference the uninitialized memory. The setup failures should not be common. But once it happens, the consequence is quite bad. Fix this issue by correctly putting the stats directory instead of the tried_regions directory. The issue was discovered [1] by Sashiko. | ||||
| CVE-2026-72174 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole() A PAGEMAP_SCAN ioctl requesting PM_SCAN_WP_MATCHING on a hugetlb VMA hangs the calling thread, unkillably, as soon as the scan reaches an unpopulated part of the range: do_pagemap_scan() walk_page_range() walk_hugetlb_range() hugetlb_vma_lock_read() # take the vma lock for read ... pagemap_scan_pte_hole() # ... ->pte_hole() for a hole uffd_wp_range() change_protection() hugetlb_change_protection() hugetlb_vma_lock_write() # ... and block taking it for write walk_hugetlb_range() holds the hugetlb vma lock for read across the whole walk. A present entry goes to ->hugetlb_entry(); an unpopulated one goes to ->pte_hole(), i.e. pagemap_scan_pte_hole(). To write-protect the hole that handler calls uffd_wp_range(), which on a hugetlb VMA reaches hugetlb_change_protection() and takes the same vma lock for write. The thread then blocks in down_write() waiting for the read lock it is itself holding. The populated path avoids this: pagemap_scan_hugetlb_entry() write-protects the entry inline under the page-table lock and never enters hugetlb_change_protection(). Do the same for holes. Fault in the page table and install the uffd-wp marker directly with make_uffd_wp_huge_pte() under the page-table lock, rather than routing through uffd_wp_range(). That is the same sequence hugetlb_change_protection() runs for an unpopulated entry, minus the vma write lock -- which is safe to skip because PMD sharing is disabled on uffd-wp VMAs (hugetlb_unshare_all_pmds() runs at registration), leaving nothing for that lock to serialise against. | ||||
| CVE-2026-72173 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: do not warn on seeing non-migration pmd entry Patch series "mm/hmm: A fix and a selftest", v3. Patch 1 fixes a stale warning present from the time when only migration softleaf entries were supported at the PMD level. Patch 2 adds some code into hmm-tests.c which exercises the pagemap path for PMD device-private entries. This patch (of 2): pagemap_pmd_range_thp() warns if a non-present PMD is not a migration entry. This became false once device-private entries at the PMD level were added. Therefore, remove the stale migration-only assertion. | ||||
| CVE-2026-72169 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES When using scratch_scale, the scratch sizes are rounded up to CMA_MIN_ALIGNMENT_BYTES since they will be released as MIGRATE_CMA. This is not done when using fixed scratch sizes via command line. This can result in user specifying a size which is not aligned, and thus kernel releasing a pageblock that is only partially scratch. Do the rounding up for both cases in scratch_size_update(). | ||||
| CVE-2026-72168 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info. | ||||
| CVE-2026-72166 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: <TASK> context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ||||
| CVE-2026-72163 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted. | ||||
| CVE-2026-72161 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: add journal NULL check in ocfs2_checkpoint_inode() During unmount, ocfs2_journal_shutdown() frees the journal and sets osb->journal to NULL. Later, when VFS evicts remaining cached inodes, ocfs2_evict_inode() -> ocfs2_clear_inode() -> ocfs2_checkpoint_inode() -> ocfs2_ci_fully_checkpointed() dereferences osb->journal, causing a NULL pointer dereference. Fix this by adding a NULL check for osb->journal in ocfs2_checkpoint_inode(). If the journal is NULL, it has already been fully flushed and destroyed during shutdown, so there is nothing to checkpoint. | ||||
| CVE-2026-72159 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode(). | ||||
| CVE-2026-72158 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fpga: dfl: add bounds check in dfh_get_param_size() dfh_get_param_size() can return a parameter size larger than the feature region because the loop bounds check is evaluated before incrementing size. If the EOP (End of Parameters) bit is set in the same iteration, the inflated size is returned without re-validation against max. This can cause create_feature_instance() to call memcpy_fromio() with a size exceeding the ioremap'd region when a malicious FPGA device provides crafted DFHv1 parameter headers. Add a bounds check after the size increment to ensure the accumulated size never exceeds the feature boundary. | ||||
| CVE-2026-72156 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header() mpf_ops_parse_header() reads header_size from the bitstream at MPF_HEADER_SIZE_OFFSET (24). When header_size is zero, the expression *(buf + header_size - 1) reads one byte before the buffer start. Since initial_header_size is set to 71 in mpf_ops, the fpga-mgr core guarantees the buffer is large enough to reach MPF_HEADER_SIZE_OFFSET. The only real gap is the zero header_size case, which cannot be resolved by providing a larger buffer, so return -EINVAL. | ||||
| CVE-2026-72153 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data. | ||||
| CVE-2026-72152 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat() wait_event_interruptible_timeout() evaluates its condition after setting the current task state to TASK_INTERRUPTIBLE. With CONFIG_DEBUG_ATOMIC_SLEEP this triggers a warning when the IRQ wait path is used: tpm_tis_status() tpm_tis_spi_read_bytes() tpm_tis_spi_transfer_full() spi_bus_lock() mutex_lock() Address this with the following measures: 1. Call wait_tpm_stat_cond() only while tasking is running. 2. Use wait_woken() to wait for changes. | ||||
| CVE-2026-72147 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device. | ||||
| CVE-2026-72145 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86/intel/tpmi: use cleanup helpers in mem_write() In mem_write(), the temporary array returned by parse_int_array_user() must be released on all exit paths. Convert the array variable to use cleanup.h scope-based cleanup so it is freed automatically on return. This also moves the array declaration next to parse_int_array_user() as required by cleanup.h usage guidelines. | ||||
| CVE-2026-72142 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. | ||||
| CVE-2026-72131 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Prevent shared tags across queues on Apple A11 On Apple A11, tags of pending commands must be unique across the admin and IO queues, else the firmware crashes with "duplicate tag error for tag N", with N being the tag. Apply the existing workaround for M1 of reserving two tags for the admin queue to A11. | ||||