Export limit exceeded: 382130 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (382130 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-74642 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases. | ||||
| CVE-2026-74647 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. | ||||
| CVE-2026-74660 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger. | ||||
| CVE-2026-74720 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent. | ||||
| CVE-2026-74722 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write(). | ||||
| CVE-2026-74725 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: enic: fix tx_hang_reset use-after-free on device removal enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work. | ||||
| CVE-2026-74726 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision. | ||||
| CVE-2026-74731 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Skip sub-disable teardown for never-linked sub-schedulers A sub-scheduler enable can fail before scx_link_sched() links the sched into the hierarchy, e.g. when the parent is already being disabled, and cleanup still runs the full scx_sub_disable(). That is racy against root disable: drain_descendants() is the only ordering between a sub's disable-time task walk and root disable's all-task teardown, and an unlinked sub is invisible to it. Root's teardown can thus run between the never-linked sub's drain and its walk, exiting every task to no scheduler. The walk then trips the membership WARN and re-homes the exited tasks onto the dying hierarchy, a use-after-free. Skip the cgroup ownership reset and the task walk if @sch was never linked, indicated by the empty ->sibling as unlinking only happens later in the same function. The membership WARN remains valid: a linked sub is always waited on by an ancestor's drain. | ||||
| CVE-2026-74732 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check for tg ops in dce110_set_avmute Some older DCE timing generators do not implement is_tg_enabled in their ops table. Calling it unconditionally when waiting for AV mute frames causes a NULL pointer dereference on Southern Islands dGPUs when turning the display off over HDMI. Check that tg and the required ops exist before waiting for frames. (cherry picked from commit 2686a0c0aaa07bec2e24131835cf27b5fd4935a5) | ||||
| CVE-2026-74606 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec() eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child. | ||||
| CVE-2026-74670 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference. | ||||
| CVE-2026-74676 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization. | ||||
| CVE-2026-74678 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the "drop" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function. | ||||
| CVE-2026-74597 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip6ip6_err() ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack. | ||||
| CVE-2026-74598 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow. | ||||
| CVE-2026-74617 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dibs: initialise dibs->lock in dibs_dev_alloc() dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler. | ||||
| CVE-2026-74686 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: rqspinlock: Reset tail when preserving queue on deadlock Currently, the destruction of the waiter queue is suppressed for rqspinlock in cases where a deadlock is detected. Deadlock checks happen relatively frequently (on entry for AA, within 1ms for ABBA), and waiter threads may not be involved in locking scenarios involving deadlocks. Thus, it is useful to not flush the queue and let other waiters take a stab at acquiring the lock after we detect a deadlock and exit. However, we need to follow the same logic as what we did previously for the waitq_timeout label: reset the tail, and if we cannot, signal the next waiter appropriately. In case of deadlocks, this signal would just mark the MCS node as unlocked, and in case of timeouts, it would signal RES_TIMEOUT_VAL. The difference thus is in the value propagated, which decides whether the queue remains active or gets flushed. Not doing the tail reset, and waiting for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely. This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be: CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock. Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives. Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch. | ||||
| CVE-2026-74690 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: s390/ism: Fix UAF of sba and ieq during ism_dev_exit() A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures. No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures. | ||||
| CVE-2026-74692 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock. | ||||
| CVE-2026-74696 | 1 Linux | 1 Linux Kernel | 2026-08-22 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen. | ||||