Export limit exceeded: 412866 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (412866 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97412 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: pds_core: quiesce DMA before freeing resources pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it. | ||||
| CVE-2026-93828 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: exfat: fix handling of damaged volume in exfat_create_upcase_table() When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely. If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only. | ||||
| CVE-2026-93817 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: perf: Fix addr_filter_ranges lifetime Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed. | ||||
| CVE-2026-93804 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: ibss: wait for in-flight TX on disconnect While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues. Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race. | ||||
| CVE-2026-93801 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: smb/client: zero-initialize stack-allocated cifs_open_info_data Stack-allocated cifs_open_info_data may contain random data. This can make some fields have wrong value if they are not set later. | ||||
| CVE-2026-93796 | 1 Linux | 2 Kernel, Linux Kernel | 2026-10-21 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: null RX pointers after free When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free(). The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe. | ||||
| CVE-2026-93793 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: validate TX_CMD response layout TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload. For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications. | ||||
| CVE-2026-93285 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: embed f2fs_gc_kthread in f2fs_sb_info Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store - remount|shutdown - f2fs_stop_gc_thread - access sbi->gc_thread - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task | ||||
| CVE-2026-93282 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix maximum allowed access checks The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group. As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone. The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask. When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant. For regular files, include FILE_EXECUTE in maximal access when the client requested GENERIC_EXECUTE and the DACL grants the complete file-read set. Keep a direct FILE_EXECUTE request subject to the explicit DACL bit. This matches the POSIX file ACL mapping without broadening specific execute requests. Do not replace rights from an applicable NT ACE with a POSIX ACL entry. The POSIX ACL is only a fallback when no user, Everyone, or Authenticated Users ACE applies; otherwise it can incorrectly broaden the stored DACL. This fixes smb2.maximum_allowed.maximum_allowed. | ||||
| CVE-2026-93272 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators. | ||||
| CVE-2026-93260 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 7.4 High |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: propagate IPI init errors to prevent use-after-free When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free. | ||||
| CVE-2026-93251 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ACPI: bus: Introduce acpi_bus_get_primary_device() The function used for obtaining the first "physical" device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last reference to the "physical" device may be dropped then before the pointer to it is returned to the caller. If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for addressing this problem, introduce a new function for getting the first "physical" device associated with the given ACPI one (the "primary physical device") that will also reference count the device in question before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the physical node list lookup code. No intentional functional impact. | ||||
| CVE-2026-93244 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: simpledrm: Improve stride validation Validate the computed stride against the maximum value INT_MAX. | ||||
| CVE-2026-93243 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: properly account locked pages secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream. | ||||
| CVE-2026-93240 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: memcg: make the v1 soft limit knob inert The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. | ||||
| CVE-2026-93231 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: lockd: fix swapped arguments in nlmsvc_match_ip() When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: match(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"): return rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); [ cel: fix the misleading typedef parameter names too ] | ||||
| CVE-2026-93230 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier Gigantic bootmem HugeTLB pages are currently initialized from hugetlb_init(), but page_alloc_init_late() runs earlier and walks pageblocks to determine zone contiguity. If a bootmem HugeTLB region is marked noinit, set_zone_contiguous() can observe still-uninitialized struct pages through __pageblock_pfn_to_page(). This may not trigger an immediate failure, but it can make set_zone_contiguous() compute the wrong zone contiguity state. If extra poisoned-page checks are added in this path, such as PF_POISONED_CHECK() in page_zone_id(), it can also trigger an early boot panic. Initialize gigantic bootmem HugeTLB struct pages from page_alloc_init_late(), before zone contiguity is evaluated, so later page allocator setup only sees valid struct page state. This also makes the initialization order more natural, as struct pages should be initialized before later code inspects them. | ||||
| CVE-2026-93228 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: svcrdma: Reject Write/Reply chunks with segcount 0 A peer can send a Write or Reply chunk whose segcount field is zero. xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero passes the range check, and xdr_inline_decode(stream, 0) returns the current (non-NULL) cursor without advancing. The function returns true and pcl_alloc_write() then links a struct svc_rdma_chunk with ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl. An earlier patch in this series made pcl_for_each_segment() safe for ch_segcount == 0, so this no longer drives the memory walk it used to. Rejecting the malformed frame at the decode boundary is still worthwhile as defense in depth: it keeps degenerate zero-segment chunks off the parsed chunk lists entirely, so any future consumer that walks ch_segments directly cannot observe one, and it makes the zero-floor easy to backport to trees where the macro change is more intrusive. RFC 8166 has no meaning for a Write/Reply chunk that describes no remote buffer, so no legitimate client is affected. xdr_check_reply_chunk() funnels Reply chunks through xdr_check_write_chunk() and inherits the same rejection. pcl_alloc_write() also links each chunk onto the parsed chunk list before filling its segment array. If a future change weakens the segcount-0 rejection, an incomplete chunk is visible to consumers during the fill loop. Reorder so that list_add_tail() follows the segment fill loop, ensuring only fully-populated chunks appear on the list. | ||||
| CVE-2026-93221 | 1 Linux | 1 Linux Kernel | 2026-10-21 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: convert nfsd_net boolean flags to unsigned long flags word nfsd_net contains several boolean fields that are accessed from concurrent contexts without serialization. In particular, nfsd4_end_grace() guards its drain path with a plain bool: if (nn->grace_ended) return; nn->grace_ended = true; The read and the write are independent, and nothing in struct nfsd_net serializes them. At least two contexts can reach this code with no lock held: laundromat path laundry_wq kworker nfs4_laundromat() nfsd4_end_grace() RECLAIM_COMPLETE path nfsd compound kthread nfsd4_reclaim_complete() inc_reclaim_complete() nfsd4_end_grace() Both callers can observe grace_ended == false on different CPUs, both store true, and both proceed into nfsd4_record_grace_done(), which invokes the active client_tracking_ops->grace_done callback. For tracking ops that drain reclaim_str_hashtbl (legacy_tracking_ops via nfsd4_recdir_purge_old, and the cld v1+ ops via nfsd4_cld_grace_done), grace_done calls nfs4_release_reclaim(), which walks every bucket of reclaim_str_hashtbl with no lock and calls nfs4_remove_reclaim_record() (list_del + kfree) on each entry. Two concurrent walkers corrupt the list and double-free every nfs4_client_reclaim. A concurrent nfsd4_find_reclaim_client() iterating the same bucket reads through freed memory. A third call site exists in nfs4_state_start_net() on the skip_grace startup path, but it runs under nfsd_mutex before any client has connected and before the laundromat's first delayed work fires, so it cannot race with the two callers above. Replace the scattered boolean fields in nfsd_net with a single unsigned long flags word and an enum nfsd_net_flag for the bit positions. The grace_ended race is fixed by using test_and_set_bit(), which is atomic on all architectures. The remaining flags (grace_end_forced, in_grace, somebody_reclaimed, track_reclaim_completes, nfsd_net_up, lockd_up) are converted to use test_bit/set_bit/clear_bit for consistency. This avoids sub-word cmpxchg issues on architectures like Hexagon that only support word-sized atomic operations. | ||||
| CVE-2026-93216 | 1 Linux | 1 Linux Kernel | 2026-10-21 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm/page_owner: use memcg_data snapshot to avoid TOCTOU in print_page_owner_memcg() print_page_owner_memcg() reads page->memcg_data via READ_ONCE() at the start to guard against tail pages and NULL data. However, it later re-reads page->memcg_data locklessly in two places: 1: page_memcg_check(page) 2: PageMemcgKmem(page) (via folio_memcg_kmem(), which includes VM_BUG_ON assertions for tail pages and MEMCG_DATA_OBJEXTS) If the page is concurrently freed and reallocated as a THP tail page or slab page between these calls, the VM_BUG_ON assertions can trigger on CONFIG_DEBUG_VM=y builds, crashing the kernel. Fix both TOCTOU issues by using the memcg_data snapshot throughout. | ||||