Export limit exceeded: 26181 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26181 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-99268 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99267 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99266 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99264 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99263 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99262 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99252 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99243 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-97618 | 1 Linux | 1 Linux Kernel | 2026-11-04 | 7.0 High |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-81010 | 1 Linux | 1 Linux Kernel | 2026-11-04 | 4.7 Medium |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-80811 | 1 Linux | 1 Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-81009 | 1 Linux | 1 Linux Kernel | 2026-11-04 | 4.7 Medium |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2024-36978 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2026-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur. | ||||
| CVE-2026-99265 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-99224 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: keys: Protect the type name while describing a key keyctl_describe_key() must keep the key type's name alive until kasprintf() has consumed it. The retained key reference keeps the key and its description alive, but does not pin the module providing its type. The name is passed to kasprintf() without holding key->sem. kvasprintf() uses the saved name pointer in two formatting passes, with a GFP_KERNEL allocation between them. With AF_RXRPC=m, a task that passes View permission before type retirement can overlap a privileged module unload in this order: 1. KEYCTL_DESCRIBE looks up the key, saves key->type->name in the kasprintf() arguments and completes the first formatting pass. 2. While the formatter is delayed before its second pass, af_rxrpc_exit() calls unregister_key_type(), which removes the type from the registry and waits for key_gc_keytype(). 3. The collector takes key->sem for writing, retypes the retained key to key_type_dead and completes retirement. Unregistration and module exit return, allowing free_module() to release the type and name. 4. The formatter resumes its second pass and reads the saved name from released module storage, which can fault in string(). Hold key->sem for reading across kasprintf(). The collector then cannot retype the key or complete retirement until both formatting passes have finished. If retirement wins the lock first, formatting uses the core key_type_dead name instead. Release the semaphore immediately after kasprintf(), including on allocation failure, before copying to userspace. Oops report as below: BUG: unable to handle page fault for address: fffffbfff8054794 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:string+0x23f/0x470 Call Trace: vsnprintf+0x330/0x1110 | ||||
| CVE-2026-99225 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: keys: Check the authorization payload in process keyring searches An authorization payload and its saved credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the descendant paused after validation, the paths can interleave as follows: 1. The descendant enters search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790 | ||||
| CVE-2026-99227 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: prevent cancel reference wrap io_waitid packs the cancellation state into bit 31 of ->refs and uses bits 30:0 as a 31-bit reference counter: #define IO_WAITID_CANCEL_FLAG BIT(31) #define IO_WAITID_REF_MASK GENMASK(30, 0) __io_waitid_cancel() marks a request canceled, then increments the low bits of ->refs to claim completion ownership. When another path owns the request, the increment remains even though cancellation returns false. The request remains discoverable by cancellation, so repeated failed attempts can wrap the 31-bit reference field to zero. A later cancellation can claim ownership and complete the request a second time. Use atomic_fetch_or() when setting the cancel flag and inspect the old flag value. The first cancel attempt continues to the existing ownership increment, preserving its wake and issuer handoff semantics. Later attempts see the cancel flag and return without incrementing the reference field. This makes repeated failed cancellation attempts idempotent while leaving the first-cancel state transitions unchanged. | ||||
| CVE-2026-99218 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: coredump: hold RCU while releasing parked threads coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop. | ||||
| CVE-2026-99219 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ftrace: Initialize modname and offset in print_rec() print_rec() leaves 'modname' and 'offset' uninitialized and kallsyms_lookup() only sets them on success. When the lookup fails like when a module is being loaded or unloaded, 'modname' holds a garbage value, passes the 'if (modname)' check, and is dereferenced by seq_printf(). Oops: general protection fault RIP: 0010:string+0x48/0xe0 Call Trace: vsnprintf+0x1f5/0x650 seq_printf+0x8e/0xb0 print_rec+0x6c/0xc0 t_show+0x4c/0x440 seq_read_iter+0x119/0x480 This can be triggered by reading available_filter_functions while a module is being loaded or unloaded. Initialize both variables so a failed lookup skips the module name. | ||||
| CVE-2026-99221 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-04 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: keys/trusted_keys: return immediately after TPM unseal failure trusted_tpm_unseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed. Return immediately when unseal fails to preserve the original error. | ||||