Export limit exceeded: 30000 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (3461 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-117877 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the Layout: Text and Fonts component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117906 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the CSS Parsing and Computation component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117919 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117920 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: HTML Parser component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117925 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117930 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: Bindings (WebIDL) component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117936 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117964 1 Mozilla 2 Firefox, Thunderbird 2026-10-30 6.1 Medium
Use-after-free in the Panning and Zooming component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117987 1 Mozilla 1 Firefox 2026-10-30 6.1 Medium
Use-after-free in the Graphics component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-118006 1 Mozilla 1 Firefox 2026-10-30 N/A
Privilege escalation due to use-after-free in the WebRTC: Signaling component. This vulnerability was fixed in Firefox 159 and Thunderbird 159.
CVE-2026-117896 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-117875 1 Mozilla 1 Firefox 2026-10-30 7.5 High
Use-after-free in the Layout: Scrolling and Overflow component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6.
CVE-2026-98921 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_do_mkdir() debug print ovl_do_mkdir() prints the input dentry with %pd after vfs_mkdir(). Since commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure."), vfs_mkdir() calls end_creating() on the input dentry on failure and may replace it on success, so the post-call %pd can use-after-free the dentry when CONFIG_OVERLAY_FS_DEBUG is enabled. Print the dentry before the call and only the result afterward.
CVE-2026-98942 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Build the cid tables privately and publish them with RCU The cid tables are visible to the cid kfuncs while being modified: the first enable publishes the global pointers before filling them, ops.init_cids() overrides rewrite them in place, and re-enables rebuild them in place. A racing TRACING or SYSCALL program can read unfilled entries, including uninitialized memory in the kmalloc'd tables, or torn topo updates. Tie the tables' lifetimes to the root sched instead: each root enable builds a fresh set privately and publishes the per-table __rcu globals once the layout is final, and root disable unpublishes and RCU-frees the set. A non-NULL global is now always a fully built table which stays valid for the reader's RCU read section, and lookups stay two loads. Kfuncs treat NULL as no-mapping, also after the scheduler exits instead of reporting the stale last mapping. The cid kfuncs are available whether the root scheduler is cid-form or cpu-form, the latter to allow gradual migration to cids. Every root therefore builds and publishes a default mapping. Every reader must either be gated on scheduler liveness or NULL-check inside an RCU read section. Fix the two kfuncs that were neither: scx_bpf_this_cid() read the table with no RCU or preemption protection and scx_bpf_task_cid() relied on KF_RCU, which doesn't put a sleepable program in an RCU read section. The hotplug callbacks are instead serialized by retiring the tables inside the cpus_read_lock() section that clears scx_root. v2: Document why every root builds the tables (desc + cid.c comment).
CVE-2026-98946 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Disable the V3D interrupt across runtime suspend vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq(). During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOMEM is still able to schedule vc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it. Therefore, fix the spurious interrupts by disabling the interrupt line across the PM transition. To preserve the enable/disable balance, move vc4_irq_install() and request the IRQ line disabled before the first runtime resume.
CVE-2026-98982 1 Linux 2 Linux, Linux Kernel 2026-10-29 7.8 High
In the Linux kernel, the following vulnerability has been resolved: namespace: don't let a pseudo dentry become the root of a mount d_alloc_pseudo() hands out dentries for pipes, sockets and other files that are never anyone's child or parent. They carry DCACHE_NORCU and dentry_free() frees them right away because no lockless path walk can ever reach them. That holds as long as such a dentry isn't the root of a mount. But bind mounting /proc/self/fd/<fd> of such a file does exactly that. Most callers of alloc_file_pseudo() put their files on kernel-internal mounts and may_copy_tree() refuses those. bpf_token_create() doesn't. It places the token file on the bpffs mount the caller handed it and that mount is in the caller's mount namespace so the clone goes through: mount --bind /proc/self/fd/<token> <file> open_tree(tokfd, "", AT_EMPTY_PATH | OPEN_TREE_CLONE) + move_mount() __follow_mount_rcu() then loads ->mnt_root of that mount, reads d_seq and d_flags of the dentry and only then checks mount_lock. The dentry can be gone by then. The final mntput() of an unmounted parent unhooks a child that stayed attached to it under mount_lock alone. When the child's holder does the final put right after that the root is dput() and freed immediately while a walker that found the mount hashed still looks at it. Refuse to clone a mount with a DCACHE_NORCU dentry as its root. Nothing sensible can be done with a bind mount of a bpf token anyway.
CVE-2026-98932 1 Linux 2 Linux, Linux Kernel 2026-10-29 7.4 High
In the Linux kernel, the following vulnerability has been resolved: EDAC/altera: Fix use-after-free in error paths In both altr_edac_a10_device_add() and altr_portb_setup(), the error path freed the dci structure before releasing the devres group. Since the managed single and double bit IRQ handlers use altdev(dci->pvt_info) as their data, an IRQ firing between freeing dci and unregistering the IRQs could dereference the freed memory. Release the devres group first so the managed IRQs are unregistered before the dci structure is freed.
CVE-2026-98945 1 Linux 2 Linux, Linux Kernel 2026-10-29 7.8 High
In the Linux kernel, the following vulnerability has been resolved: HID: steam: Rearrange teardown sequence This fixes a narrow window during the teardown sequence where callbacks could still be scheduled during cleanup that would then have a dangling pointer to the now-freed steam struct. This also puts work canceling for rumble and mode switch in steam_unregister, as that shouldn't persist while the client hdev is open.
CVE-2026-98972 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode() After seeing the patch [1] to guard is_in_v2_mode() with RCU, it makes me realize that is_in_v2_mode() may be called in a context where a new cgroup filesystem is being rebound with stale cpuset_cgrp_subsys.root pointer. Avoid this potential UaF situation by adding a new cpuset_v2_mode flag which is set when the cpuset_v2_mode mount option is used. This flag is written into only when cpuset_bind() is being called with a stable cpuset_cgrp_subsys.root value. The is_in_v2_mode() helper is modified to read the new cpuset_v2_mode flag instead of accessing cpuset_cgrp_subsys.root directly. [1] https://lore.kernel.org/lkml/20260929084124.626693-2-arighi@nvidia.com
CVE-2026-98986 1 Linux 2 Linux, Linux Kernel 2026-10-29 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: namespace: remove the fsnotify marks of a mount namespace in process context mnt_ns_release() drops the last passive reference of a mount namespace and removes its fanotify marks via fsnotify_mntns_delete(). That takes the mutex of every group with a mark on the namespace and the spinlock of the connector. Fine from process context. But mnt_ns_tree_remove() hands the reference the namespace was allocated with to call_rcu() and so the marks are removed from the RCU softirq: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3 __mutex_lock+0x113/0x24b0 fsnotify_destroy_marks+0x11b/0x3d0 mnt_ns_release_rcu+0x57/0xa0 rcu_core+0x6b6/0x1e40 and lockdep complains about the connector lock being taken from softirq context. A fanotify group with a FAN_MARK_MNTNS mark on the mount namespace of another task is all that's needed. Root in a user namespace can do that for a mount namespace it owns. The task exits and the namespace is freed with the mark still on it. Remove the marks in free_mnt_ns() before the namespace is handed to RCU. That runs in process context once the last active reference is gone. A mark is added through a file descriptor to the namespace which holds an active reference so no mark can show up after that.