Export limit exceeded: 403607 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (403607 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98211 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: Fix use-after-free in busy-timeout work ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() never cancels it. The work can subsequently dereference the devm-allocated mmci_host after it has been released. Mask the controller interrupts and disable the delayed work during removal. This drains any queued instance and stops an IRQ handler that is still in progress from queueing the work again once it has been disabled. This issue was found by an in-house static analysis tool. | ||||
| CVE-2026-98212 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: hsq: Fix use-after-free in retry work mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq. Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work. This issue was found by an in-house static analysis tool. | ||||
| CVE-2026-98214 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: selinux: recheck intermediate backing files on mprotect() mprotect() can be used to bypass the SELinux checks that mmap() performs against the intermediate layers of a stacked filesystem. mmap() checks every backing layer as the request descends through the stack. mprotect() only has the lowest backing file in vma->vm_file, so it rechecks the top-level user and the lowest mounter, but skips the mounters of every layer in between. With two nested overlayfs mounts and a policy denying mounter_t -> middle_file_t:file { execute }, a direct mmap(PROT_EXEC) is denied: avc: denied { execute } for pid=71 comm="nested_exec" path="/payload" dev="overlay" ino=9 scontext=user_u:base_r:mounter_t tcontext=user_u:object_r:middle_file_t tclass=file permissive=0 while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds. Preserve each intermediate path, mounter SID and file-description SID in the backing-file security blob, copying the saved entries when another backing layer is opened. Allocate the array only for nested backing files, and release it and the path references in the backing_file_free hook. During mprotect(), recheck fd { use } and the requested inode permissions for every saved mounter, and include the intermediate layers in the execmod checks. Policy for nested stacking may then need to grant intermediate mounters what a direct mmap() already requires, and execmod on intermediate labels for binaries using text relocations. Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy, on a mainline tree containing commit f2381b546e7e ("fs: fix user path of nested backing files"). [PM: subject tweak] | ||||
| CVE-2026-98219 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Close the pre-enable ops error claim window scx_alloc_and_add_sched() publishes ops->priv before scx_root_enable_workfn() switches the state to SCX_ENABLING. An error claimed via scx_bpf_error_bstr() from an associated BPF program in that window is consumed by scx_disable_workfn(), which takes the pre-enable shortcut in scx_root_disable(). The shortcut returns without any teardown and restores SCX_DISABLED with an unconditional scx_set_enable_state() xchg racing the enable workfn's own transition. The enable then completes with the claim consumed: the scheduler stays up but can never be disabled again, and bpf_scx_unreg() frees it while still in use, resulting in a use-after-free. Both WARN_ON_ONCE()s fire back to back: WARNING: kernel/sched/ext/ext.c:7522 at scx_root_enable_workfn+0xeec/0x1be0, CPU#3: scx_enable_help/276 WARNING: kernel/sched/ext/ext.c:6398 at scx_root_disable+0xb50/0xdb8, CPU#0: sched_ext_helpe/664 scx_root_enable_workfn() switches to SCX_ENABLING before the scheduler allocation, so ops->priv is never visible while SCX_DISABLED. The allocation failure path restores SCX_DISABLED. | ||||
| CVE-2026-98224 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/vma: correctly unaccount on mmap_prepare() failure __mmap_setup() accounts memory for relevant mappings via: security_vm_enough_memory_mm() -> __vm_enough_memory() -> vm_acct_memory() If __mmap_setup() fails, this indicates that this accounting did not take place, and thus it's appropriate for __mmap_region() to jump to abort_munmap. However if call_mmap_prepare() fails, it also jumps there and any accounted memory is not correctly unaccounted. Fix this by handling each error separately. | ||||
| CVE-2026-98234 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope. Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500. | ||||
| CVE-2026-98253 | 1 Linux | 1 Linux Kernel | 2026-10-09 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Serialize join and leave on copy_to_user failure rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit. ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees. Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join. | ||||
| CVE-2026-20535 | 2 Mediatek, Mediatek, Inc. | 25 Mt6878, Mt6878 Firmware, Mt6881 and 22 more | 2026-10-09 | 6.7 Medium |
| In aidl, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11185216; Issue ID: MSV-9039. | ||||
| CVE-2026-20536 | 2 Mediatek, Mediatek, Inc. | 27 Mt6878, Mt6878 Firmware, Mt6881 and 24 more | 2026-10-09 | 6.7 Medium |
| In aidl, there is a possible memory corruption due to use after free. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11242428; Issue ID: MSV-9038. | ||||
| CVE-2026-106405 | 1 Google | 2 Android, Chrome | 2026-10-09 | 6 Medium |
| Race condition in CustomTabs in Google Chrome on on Android prior to 155.0.8059.39 allowed a local attacker to bypass web origin policy via a co-installed app. (Chromium security severity: Medium) | ||||
| CVE-2026-106407 | 1 Google | 1 Chrome | 2026-10-09 | 6.5 Medium |
| Incorrect authorization in GetUserMedia in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106408 | 2 Apple, Google | 2 Iphone Os, Chrome | 2026-10-09 | 6.5 Medium |
| Protection mechanism failure in Mobile in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-78406 | 1 Ibm | 4 Security Verify Access, Security Verify Access Container, Verify Identity Access and 1 more | 2026-10-09 | 9.8 Critical |
| IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote unauthenticated attacker to execute arbitrary code on the system due to the deserialization of untrusted data. | ||||
| CVE-2026-19498 | 1 Ibm | 4 Security Verify Access, Security Verify Access Container, Verify Identity Access and 1 more | 2026-10-09 | 5.9 Medium |
| IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote attacker to cause a denial of service due to uncontrolled recursion. | ||||
| CVE-2026-12109 | 1 Ibm | 4 Security Verify Access, Security Verify Access Container, Verify Identity Access and 1 more | 2026-10-09 | 5.5 Medium |
| IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow an attacker with administrative privileges and access to the local management interface to execute arbitrary code due to an unbounded write to a fixed-size stack buffer. | ||||
| CVE-2026-104115 | 2026-10-09 | N/A | ||
| A stack-based buffer overflow in the illumos reparse point daemon (reparsed) allows a local user to crash the daemon. get_fs_locations() in usr/src/cmd/fs.d/nfs/rp_basic/libnfs_basic.c, part of the nfs-basic reparse plugin, copies the host and path components of a reparse string into a fixed 1024-byte stack buffer without checking their length. The reparsed door at /var/run/reparsed_door is readable by all users and the door server does not check the caller's credentials, so an unprivileged local user can send an nfs-basic request with an overlong host or path component to overflow the buffer. On systems built with stack protection, which is the default, this causes reparsed to abort; repeated requests place the svc:/system/filesystem/reparse service into maintenance. The service is disabled by default. The flaw has existed since 2009 (illumos-gate commit 2f172c55), and affects any illumos distribution prior to illumos-gate commit 6a2df4aa. | ||||
| CVE-2026-82335 | 1 Ibm | 1 Guardium Data Protection | 2026-10-09 | 8.1 High |
| IBM Guardium Data Protection 12.0, 12.1, 12.2 is vulnerable to a heap-based buffer overflow in the MongoDB protocol parser. A remote attacker could send a specially crafted MongoDB SCRAM username containing an excessive length and cause memory corruption, potentially resulting in denial of service or arbitrary code execution. | ||||
| CVE-2026-82344 | 1 Ibm | 1 Guardium Data Protection | 2026-10-09 | 8.1 High |
| IBM Guardium Data Protection 12.0, 12.1 is vulnerable to a heap-based buffer overflow in the S-TAP TrafficTap TDS login reassembly functionality. An unauthenticated remote attacker can send crafted TDS login fragments that exceed the fixed-size reassembly buffer, potentially resulting in denial of service or arbitrary code execution on the affected system. | ||||
| CVE-2026-104112 | 2026-10-09 | N/A | ||
| A missing release of resources in the illumos name service cache daemon (nscd) allows a local user to exhaust kernel memory. The nscd door server procedure, switcher() in usr/src/cmd/nscd/nscd_frontend.c, does not close file descriptors that are passed with a door call but not used by the request, and the main nscd door at /var/run/name_service_door accepts passed descriptors from any user in its zone. Because nscd also runs with an unlimited file descriptor limit, an unprivileged local user, including one in a non-global zone, can repeatedly pass a descriptor to its zone's nscd in a door_call() loop, causing the file descriptor table of nscd to grow without bound in kernel memory. This causes a denial of service of nscd and can render processes in all zones on the host unresponsive. The flaw has existed since 2006 (illumos-gate commit cb5caa98), and affects any illumos distribution prior to illumos-gate commit af810a72. | ||||
| CVE-2026-104114 | 2026-10-09 | N/A | ||
| A NULL pointer dereference in the illumos Network Auto-Magic daemon (nwamd) allows a local user to crash the daemon. nwamd_door_switch() in usr/src/cmd/cmd-inet/lib/nwamd/door_if.c writes to the caller's request structure before checking that a request was supplied, and before checking the caller's credentials. Because the nwamd door at /etc/svc/volatile/nwam/nwam_door is accessible to all local users, an unprivileged user can issue a door_call() with no argument data to crash nwamd; repeated calls place the svc:/network/physical:nwam service into maintenance, stopping automatic network configuration. nwamd runs only when svc:/network/physical:nwam is enabled, which is not the default. The flaw has existed since 2010 (illumos-gate commit 6ba597c5), and affects any illumos distribution prior to illumos-gate commit 0f1064d9. | ||||