Export limit exceeded: 378312 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (378312 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72197 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: if (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || used + esize > le32_to_cpu(hdr->total)) { goto dirty_vol; } Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [[email protected]: clang-formatted the changes] | ||||
| CVE-2026-72231 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is "ret == false". But the actual implementation is checking for "ret == true". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms. | ||||
| CVE-2026-72240 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. | ||||
| CVE-2026-72267 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist() | ||||
| CVE-2026-72300 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: validate vendor array size before parsing sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. Cast sizeof(*array) to int when validating the declared array size. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. | ||||
| CVE-2026-72316 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern. | ||||
| CVE-2026-72332 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo() amdxdna_hwctx_sync_debug_bo() invokes the hardware hwctx_sync_debug_bo() callback while holding xdna->dev_lock. The callback may call amdxdna_cmd_submit(), which in turn calls amdxdna_pm_resume_get(). If the device is suspended, amdxdna_pm_resume_get() may synchronously execute amdxdna_pm_resume(), which also acquires xdna->dev_lock, resulting in a deadlock. Avoid the deadlock by calling amdxdna_pm_resume_get() before holding xdna->dev_lock in both amdxdna_hwctx_sync_debug_bo() and amdxdna_drm_config_hwctx_ioctl() | ||||
| CVE-2026-72358 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: prevent invalid cursor access for purged BOs During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e) | ||||
| CVE-2026-72136 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. | ||||
| CVE-2026-72143 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Restore SST-PP control to all domains The SST-PP control offset is only restored to power domain 0 after resume. During suspend, control values are read and stored for all power domains. Use pd_info->sst_base instead of power_domain_info->sst_base, which only points to power domain 0 base address. | ||||
| CVE-2026-72144 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-laptop: fix missing cleanups in init error path dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill. | ||||
| CVE-2026-72145 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| 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-72150 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix uninitialized xprt_create_args structure The xprt_create_args structure is allocated on the stack without initialization in rpc_sysfs_xprt_switch_add_xprt_store(). While some fields are manually populated, critical fields like srcaddr, bc_xps, and flags contain uninitialized stack garbage. This can lead to: 1. Kernel panic when xs_setup_xprt() dereferences garbage srcaddr 2. Information leak if srcaddr points to sensitive stack data 3. Unpredictable behavior if flags has random bits set The fix is to zero-initialize the structure to ensure all unused fields are NULL/0, preventing the transport setup code from acting on garbage data. | ||||
| CVE-2026-72151 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt tpm_buf_append_salt() in drivers/char/tpm/tpm2-sessions.c calls crypto_kpp_generate_public_key() and crypto_kpp_compute_shared_secret() without installing a completion callback, discards both return values, and immediately frees the kpp_request via kpp_request_free(). When the resolved ecdh-nist-p256 KPP backend is asynchronous (atmel-ecc, HPRE, keembay-ocs), either operation returns -EINPROGRESS and the deferred completion worker dereferences the freed request. The path fires automatically from the hwrng_fillfn kernel thread via tpm_get_random -> tpm2_get_random -> tpm2_start_auth_session -> tpm_buf_append_salt on every entropy poll, without any userland action. Install crypto_req_done as the completion callback, wrap both KPP operations in crypto_wait_req(), and propagate errors to the caller. The wait is a no-op for synchronous backends. | ||||
| CVE-2026-72155 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: swp: Improve locking user experience In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to "nor->params->size - (ofs + len)" which is a positive number. This is wrong. An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic. | ||||
| CVE-2026-72158 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| 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-72160 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode(). | ||||
| CVE-2026-72162 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec [BUG] On-disk corruption setting l_next_free_rec to 0 in an inode's embedded extent list triggers a UBSAN panic on the next write to that file. [CAUSE] ocfs2_sum_rightmost_rec() computes i = le16_to_cpu(el->l_next_free_rec) - 1 and accesses el->l_recs[i] without validating i. When l_next_free_rec is 0, i becomes -1; when l_next_free_rec exceeds l_count, i falls past the end of the array. Either case violates the __counted_by_le(l_count) annotation on l_recs[] and triggers UBSAN. [FIX] Validate the inode's embedded extent list when the inode is read, in ocfs2_validate_inode_block(): l_count must be non-zero and no larger than the inode block can hold, and l_next_free_rec must not exceed l_count. A corrupt list is rejected at read time, before the b-tree code can index l_recs[] out of bounds. | ||||
| CVE-2026-72167 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent. | ||||
| CVE-2026-72169 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| 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(). | ||||