Export limit exceeded: 26128 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26128 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23185 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: cancel mlo_scan_start_wk mlo_scan_start_wk is not canceled on disconnection. In fact, it is not canceled anywhere except in the restart cleanup, where we don't really have to. This can cause an init-after-queue issue: if, for example, the work was queued and then drv_change_interface got executed. This can also cause use-after-free: if the work is executed after the vif is freed. | ||||
| CVE-2026-23192 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: linkwatch: use __dev_put() in callers to prevent UAF After linkwatch_do_dev() calls __dev_put() to release the linkwatch reference, the device refcount may drop to 1. At this point, netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an empty list and returns without blocking), wait for the refcount to become 1 via netdev_wait_allrefs_any(), and then free the device via kobject_put(). This creates a use-after-free when __linkwatch_run_queue() tries to call netdev_unlock_ops() on the already-freed device. Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in netdev_run_todo() before kobject_put() would not work, because netdev_lock_ops() is conditional - it only locks when netdev_need_ops_lock() returns true. If the device doesn't require ops_lock, linkwatch won't hold any lock, and netdev_run_todo() acquiring the lock won't provide synchronization. Fix this by moving __dev_put() from linkwatch_do_dev() to its callers. The device reference logically pairs with de-listing the device, so it's reasonable for the caller that did the de-listing to release it. This allows placing __dev_put() after all device accesses are complete, preventing UAF. The bug can be reproduced by adding mdelay(2000) after linkwatch_do_dev() in __linkwatch_run_queue(), then running: ip tuntap add mode tun name tun_test ip link set tun_test up ip link set tun_test carrier off ip link set tun_test carrier on sleep 0.5 ip tuntap del mode tun name tun_test KASAN report: ================================================================== BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline] BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123 CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events_unbound linkwatch_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x156/0x4c9 mm/kasan/report.c:482 kasan_report+0xdf/0x1a0 mm/kasan/report.c:595 netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] netdev_unlock_ops include/net/netdev_lock.h:47 [inline] __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304 process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3421 kthread+0x3b3/0x730 kernel/kthread.c:463 ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> ================================================================== | ||||
| CVE-2026-23195 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: cgroup/dmem: avoid pool UAF An UAF issue was observed: BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150 Write of size 8 at addr ffff888106715440 by task insmod/527 CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11 Tainted: [O]=OOT_MODULE Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 kasan_report+0xca/0x100 kasan_check_range+0x39/0x1c0 page_counter_uncharge+0x65/0x150 dmem_cgroup_uncharge+0x1f/0x260 Allocated by task 527: Freed by task 0: The buggy address belongs to the object at ffff888106715400 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 64 bytes inside of freed 512-byte region [ffff888106715400, ffff888106715600) The buggy address belongs to the physical page: Memory state around the buggy address: ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb The issue occurs because a pool can still be held by a caller after its associated memory region is unregistered. The current implementation frees the pool even if users still hold references to it (e.g., before uncharge operations complete). This patch adds a reference counter to each pool, ensuring that a pool is only freed when its reference count drops to zero. | ||||
| CVE-2026-23204 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221 | ||||
| CVE-2026-23209 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken. Many thanks to valis for following up on this issue. | ||||
| CVE-2026-23210 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ice: Fix PTP NULL pointer dereference during VSI rebuild Fix race condition where PTP periodic work runs while VSI is being rebuilt, accessing NULL vsi->rx_rings. The sequence was: 1. ice_ptp_prepare_for_reset() cancels PTP work 2. ice_ptp_rebuild() immediately queues PTP work 3. VSI rebuild happens AFTER ice_ptp_rebuild() 4. PTP work runs and accesses NULL vsi->rx_rings Fix: Keep PTP work cancelled during rebuild, only queue it after VSI rebuild completes in ice_rebuild(). Added ice_ptp_queue_work() helper function to encapsulate the logic for queuing PTP work, ensuring it's only queued when PTP is supported and the state is ICE_PTP_READY. Error log: [ 121.392544] ice 0000:60:00.1: PTP reset successful [ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 121.392712] #PF: supervisor read access in kernel mode [ 121.392720] #PF: error_code(0x0000) - not-present page [ 121.392727] PGD 0 [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary) [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice] [ 121.393042] Call Trace: [ 121.393047] <TASK> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice] [ 121.393202] kthread_worker_fn+0xa2/0x260 [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice] [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10 [ 121.393371] kthread+0x10d/0x230 [ 121.393382] ? __pfx_kthread+0x10/0x10 [ 121.393393] ret_from_fork+0x273/0x2b0 [ 121.393407] ? __pfx_kthread+0x10/0x10 [ 121.393417] ret_from_fork_asm+0x1a/0x30 [ 121.393432] </TASK> | ||||
| CVE-2006-1624 | 1 Linux | 1 Linux Kernel | 2026-04-16 | N/A |
| The default configuration of syslogd in the Linux sysklogd package does not enable the -x (disable name lookups) option, which allows remote attackers to cause a denial of service (traffic amplification) via messages with spoofed source IP addresses. | ||||
| CVE-2001-0851 | 4 Caldera, Linux, Redhat and 1 more | 8 Openlinux, Openlinux Edesktop, Openlinux Eserver and 5 more | 2026-04-16 | N/A |
| Linux kernel 2.0, 2.2 and 2.4 with syncookies enabled allows remote attackers to bypass firewall rules by brute force guessing the cookie. | ||||
| CVE-2005-2873 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-04-16 | N/A |
| The ipt_recent kernel module (ipt_recent.c) in Linux kernel 2.6.12 and earlier does not properly perform certain time tests when the jiffies value is greater than LONG_MAX, which can cause ipt_recent netfilter rules to block too early, a different vulnerability than CVE-2005-2872. | ||||
| CVE-2003-0961 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Linux | 2026-04-16 | N/A |
| Integer overflow in the do_brk function for the brk system call in Linux kernel 2.4.22 and earlier allows local users to gain root privileges. | ||||
| CVE-2003-0986 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-04-16 | N/A |
| Various routines for the ppc64 architecture on Linux kernel 2.6 prior to 2.6.2 and 2.4 prior to 2.4.24 do not use the copy_from_user function when copying data from userspace to kernelspace, which crosses security boundaries and allows local users to cause a denial of service. | ||||
| CVE-2001-1396 | 2 Linux, Redhat | 2 Linux Kernel, Linux | 2026-04-16 | N/A |
| Unknown vulnerabilities in strnlen_user for Linux kernel before 2.2.19, with unknown impact. | ||||
| CVE-2006-1524 | 1 Linux | 1 Linux Kernel | 2026-04-16 | N/A |
| madvise_remove in Linux kernel 2.6.16 up to 2.6.16.6 does not follow file and mmap restrictions, which allows local users to bypass IPC permissions and replace portions of readonly tmpfs files with zeroes, aka the MADV_REMOVE vulnerability. NOTE: this description was originally written in a way that combined two separate issues. The mprotect issue now has a separate name, CVE-2006-2071. | ||||
| CVE-1999-0986 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Linux | 2026-04-16 | N/A |
| The ping command in Linux 2.0.3x allows local users to cause a denial of service by sending large packets with the -R (record route) option. | ||||
| CVE-1999-0590 | 3 Apple, Linux, Microsoft | 6 Macos, Linux Kernel, Windows 2000 and 3 more | 2026-04-16 | N/A |
| A system does not present an appropriate legal message or warning to a user who is accessing it. | ||||
| CVE-2004-0949 | 5 Linux, Redhat, Suse and 2 more | 8 Linux Kernel, Enterprise Linux, Enterprise Linux Desktop and 5 more | 2026-04-16 | N/A |
| The smb_recv_trans2 function call in the samba filesystem (smbfs) in Linux kernel 2.4 and 2.6 does not properly handle the re-assembly of fragmented packets correctly, which could allow remote samba servers to (1) read arbitrary kernel information or (2) raise a counter value to an arbitrary number by sending the first part of the fragmented packet multiple times. | ||||
| CVE-2004-0001 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-04-16 | N/A |
| Unknown vulnerability in the eflags checking in the 32-bit ptrace emulation for the Linux kernel on AMD64 systems allows local users to gain privileges. | ||||
| CVE-2006-1242 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-04-16 | N/A |
| The ip_push_pending_frames function in Linux 2.4.x and 2.6.x before 2.6.16 increments the IP ID field when sending a RST after receiving unsolicited TCP SYN-ACK packets, which allows remote attackers to conduct an Idle Scan (nmap -sI) attack, which bypasses intended protections against such attacks. | ||||
| CVE-1999-1285 | 1 Linux | 1 Linux Kernel | 2026-04-16 | N/A |
| Linux 2.1.132 and earlier allows local users to cause a denial of service (resource exhaustion) by reading a large buffer from a random device (e.g. /dev/urandom), which cannot be interrupted until the read has completed. | ||||
| CVE-2006-4145 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-04-16 | N/A |
| The Universal Disk Format (UDF) filesystem driver in Linux kernel 2.6.17 and earlier allows local users to cause a denial of service (hang and crash) via certain operations involving truncated files, as demonstrated via the dd command. | ||||