Total
672 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2006-2374 | 1 Microsoft | 3 Windows 2000, Windows 2003 Server, Windows Xp | 2026-04-16 | 2.1 LOW | 5.5 MEDIUM |
| The Server Message Block (SMB) driver (MRXSMB.SYS) in Microsoft Windows 2000 SP4, XP SP1 and SP2, and Server 2003 SP1 and earlier allows local users to cause a denial of service (hang) by calling the MrxSmbCscIoctlCloseForCopyChunk with the file handle of the shadow device, which results in a deadlock, aka the "SMB Invalid Handle Vulnerability." | |||||
| CVE-2002-1914 | 1 Dump Project | 1 Dump | 2026-04-16 | 2.1 LOW | 5.5 MEDIUM |
| dump 0.4 b10 through b29 allows local users to cause a denial of service (execution prevention) by using flock() to lock the /etc/dumpdates file. | |||||
| CVE-2006-2275 | 2 Canonical, Lksctp | 2 Ubuntu Linux, Stream Control Transmission Protocol | 2026-04-16 | 5.0 MEDIUM | 7.5 HIGH |
| Linux SCTP (lksctp) before 2.6.17 allows remote attackers to cause a denial of service (deadlock) via a large number of small messages to a receiver application that cannot process the messages quickly enough, which leads to "spillover of the receive buffer." | |||||
| CVE-2004-0174 | 1 Apache | 1 Http Server | 2026-04-16 | 5.0 MEDIUM | 7.5 HIGH |
| Apache 1.4.x before 1.3.30, and 2.0.x before 2.0.49, when using multiple listening sockets on certain platforms, allows remote attackers to cause a denial of service (blocked new connections) via a "short-lived connection on a rarely-accessed listening socket." | |||||
| CVE-2005-2456 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-04-16 | 2.1 LOW | 5.5 MEDIUM |
| Array index overflow in the xfrm_sk_policy_insert function in xfrm_user.c in Linux kernel 2.6 allows local users to cause a denial of service (oops or deadlock) and possibly execute arbitrary code via a p->dir value that is larger than XFRM_POLICY_OUT, which is used as an index in the sock->sk_policy array. | |||||
| CVE-2000-0338 | 1 Concurrent Versions Software Project | 1 Concurrent Versions Software | 2026-04-16 | 5.0 MEDIUM | 5.5 MEDIUM |
| Concurrent Versions Software (CVS) uses predictable temporary file names for locking, which allows local users to cause a denial of service by creating the lock directory before it is created for use by a legitimate CVS user. | |||||
| CVE-2005-3847 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-04-16 | 4.0 MEDIUM | 5.5 MEDIUM |
| The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump. | |||||
| CVE-2001-0682 | 2 Checkpoint, Zonelabs | 2 Zonealarm Pro, Zonealarm | 2026-04-16 | 2.1 LOW | 5.5 MEDIUM |
| ZoneAlarm and ZoneAlarm Pro allows a local attacker to cause a denial of service by running a trojan to initialize a ZoneAlarm mutex object which prevents ZoneAlarm from starting. | |||||
| CVE-2002-0051 | 1 Microsoft | 1 Windows 2000 | 2026-04-16 | 4.6 MEDIUM | 7.8 HIGH |
| Windows 2000 allows local users to prevent the application of new group policy settings by opening Group Policy files with exclusive-read access. | |||||
| CVE-2002-1850 | 1 Apache | 1 Http Server | 2026-04-16 | 5.0 MEDIUM | 7.5 HIGH |
| mod_cgi in Apache 2.0.39 and 2.0.40 allows local users and possibly remote attackers to cause a denial of service (hang and memory consumption) by causing a CGI script to send a large amount of data to stderr, which results in a read/write deadlock between httpd and the CGI script. | |||||
| CVE-2025-1221 | 2026-04-15 | N/A | N/A | ||
| A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host system (CPCd) due to heavy Zigbee traffic, resulting in a Denial of Service (DoS) attack, Only hard reset will bring the device to normal operation | |||||
| CVE-2025-10151 | 2026-04-15 | N/A | N/A | ||
| Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects smartLink HW-PN: from 1.02 through 1.03 smartLink HW-DP: 1.31 | |||||
| CVE-2025-20044 | 2026-04-15 | N/A | 4.1 MEDIUM | ||
| Improper locking for some Intel(R) TDX Module firmware before version 1.5.13 may allow a privileged user to potentially enable escalation of privilege via local access. | |||||
| CVE-2025-49178 | 2026-04-15 | N/A | 5.5 MEDIUM | ||
| A flaw was found in the X server's request handling. Non-zero 'bytes to ignore' in a client's request can cause the server to skip processing another client's request, potentially leading to a denial of service. | |||||
| CVE-2025-20047 | 2026-04-15 | N/A | 5.7 MEDIUM | ||
| Improper locking in the Intel(R) Integrated Connectivity I/O interface (CNVi) for some Intel(R) Core™ Ultra Processors may allow an unauthenticated user to potentially enable escalation of privilege via physical access. | |||||
| CVE-2024-47736 | 1 Linux | 1 Linux Kernel | 2026-04-11 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference. | |||||
| CVE-2024-57994 | 1 Linux | 1 Linux Kernel | 2026-04-06 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple() Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage. syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1] As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH. Rename helpers to better reflect they are safe against BH only. - ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh() [1] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 | |||||
| CVE-2023-53519 | 1 Linux | 1 Linux Kernel | 2026-04-06 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: add lock to protect parameter num_rdy Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready. kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c | |||||
| CVE-2025-43510 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2026-04-03 | N/A | 7.8 HIGH |
| A memory corruption issue was addressed with improved lock state checking. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2, iOS 26.1 and iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1, tvOS 26.1, visionOS 26.1, watchOS 26.1. A malicious application may cause unexpected changes in memory shared between processes. | |||||
| CVE-2026-23103 | 1 Linux | 1 Linux Kernel | 2026-04-03 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths. | |||||