Total
1904 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-57917 | 2025-01-23 | 5.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: topology: Keep the cpumask unchanged when printing cpumap During fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The call trace shows that kvasprintf() reported this warning during the printing of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent. If the core_cpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify core_cpumask while printing. To fix this issue, cache the cpumask into a temporary variable before calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged during the printing process. | ||||
| CVE-2024-38137 | 1 Microsoft | 8 Windows 10 21h2, Windows 10 22h2, Windows 11 21h2 and 5 more | 2025-01-23 | 7 High |
| Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability | ||||
| CVE-2024-38136 | 1 Microsoft | 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more | 2025-01-23 | 7 High |
| Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability | ||||
| CVE-2024-38191 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2025-01-23 | 7.8 High |
| Kernel Streaming Service Driver Elevation of Privilege Vulnerability | ||||
| CVE-2024-26242 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-01-23 | 7 High |
| Windows Telephony Server Elevation of Privilege Vulnerability | ||||
| CVE-2024-26236 | 1 Microsoft | 1 Windows Server 2022 23h2 | 2025-01-23 | 7 High |
| Windows Update Stack Elevation of Privilege Vulnerability | ||||
| CVE-2024-26243 | 1 Microsoft | 7 Windows 10 21h2, Windows 10 22h2, Windows 11 21h2 and 4 more | 2025-01-23 | 7 High |
| Windows USB Print Driver Elevation of Privilege Vulnerability | ||||
| CVE-2023-28308 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2025-01-23 | 6.6 Medium |
| Windows DNS Server Remote Code Execution Vulnerability | ||||
| CVE-2023-28307 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2025-01-23 | 6.6 Medium |
| Windows DNS Server Remote Code Execution Vulnerability | ||||
| CVE-2023-28306 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2025-01-23 | 6.6 Medium |
| Windows DNS Server Remote Code Execution Vulnerability | ||||
| CVE-2023-28278 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2025-01-23 | 6.6 Medium |
| Windows DNS Server Remote Code Execution Vulnerability | ||||
| CVE-2023-28273 | 1 Microsoft | 9 Windows 10 1607, Windows 10 1809, Windows 10 20h2 and 6 more | 2025-01-23 | 7 High |
| Windows Clip Service Elevation of Privilege Vulnerability | ||||
| CVE-2023-28232 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-01-23 | 7.5 High |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | ||||
| CVE-2023-28305 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2025-01-23 | 6.6 Medium |
| Windows DNS Server Remote Code Execution Vulnerability | ||||
| CVE-2010-5181 | 2 Gfi, Microsoft | 2 Vipre Antivirus, Windows Xp | 2025-01-21 | 7 High |
| Race condition in VIPRE Antivirus Premium 4.0.3272 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute | ||||
| CVE-2010-5169 | 2 Emisoft, Microsoft | 2 Online Armor, Windows Xp | 2025-01-21 | 7 High |
| Race condition in Online Armor Premium 4.0.0.35 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute | ||||
| CVE-2010-5159 | 2 Drweb, Microsoft | 2 Web Security Space, Windows Xp | 2025-01-21 | 7 High |
| Race condition in Dr.Web Security Space Pro 6.0.0.03100 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute | ||||
| CVE-2010-0021 | 1 Microsoft | 6 Windows 2000, Windows 2003 Server, Windows 7 and 3 more | 2025-01-21 | 5.9 Medium |
| Multiple race conditions in the SMB implementation in the Server service in Microsoft Windows Vista Gold, SP1, and SP2, Windows Server 2008 Gold, SP2, and R2, and Windows 7 allow remote attackers to cause a denial of service (system hang) via a crafted (1) SMBv1 or (2) SMBv2 Negotiate packet, aka "SMB Memory Corruption Vulnerability." | ||||
| CVE-2025-21651 | 2025-01-20 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq.. | ||||
| CVE-2024-56709 | 2025-01-20 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: io_uring: check if iowq is killed before queuing task work can be executed after the task has gone through io_uring termination, whether it's the final task_work run or the fallback path. In this case, task work will find ->io_wq being already killed and null'ed, which is a problem if it then tries to forward the request to io_queue_iowq(). Make io_queue_iowq() fail requests in this case. Note that it also checks PF_KTHREAD, because the user can first close a DEFER_TASKRUN ring and shortly after kill the task, in which case ->iowq check would race. | ||||