Total
2202 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-59193 | 1 Microsoft | 23 Services, Windows, Windows 10 and 20 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-58727 | 1 Microsoft | 20 Windows, Windows 10, Windows 10 21h2 and 17 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Connected Devices Platform Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-55328 | 1 Microsoft | 28 Hyper-v, Server, Windows and 25 more | 2026-01-02 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Hyper-V allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-53768 | 1 Microsoft | 19 Windows, Windows 10, Windows 10 1507 and 16 more | 2026-01-02 | 7.8 High |
| Use after free in Xbox allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-53150 | 1 Microsoft | 22 Windows, Windows 10, Windows 10 1809 and 19 more | 2026-01-02 | 7.8 High |
| Use after free in Windows Digital Media allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59282 | 1 Microsoft | 31 Iis, Windows, Windows 10 and 28 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Inbox COM Objects allows an unauthorized attacker to execute code locally. | ||||
| CVE-2025-59200 | 1 Microsoft | 21 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 18 more | 2026-01-02 | 7.7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Data Sharing Service Client allows an unauthorized attacker to perform spoofing locally. | ||||
| CVE-2025-59196 | 1 Microsoft | 26 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 23 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SSDP Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59195 | 1 Microsoft | 23 Graphics Component, Windows, Windows 10 and 20 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to deny service locally. | ||||
| CVE-2025-55687 | 1 Microsoft | 27 Windows, Windows 10, Windows 10 1507 and 24 more | 2026-01-02 | 7.4 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Resilient File System (ReFS) allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2025-62215 | 1 Microsoft | 19 Windows 10, Windows 10 1809, Windows 10 21h2 and 16 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Kernel allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-60723 | 1 Microsoft | 21 Directx, Windows, Windows 10 and 18 more | 2026-01-02 | 6.3 Medium |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows DirectX allows an authorized attacker to deny service over a network. | ||||
| CVE-2025-62219 | 1 Microsoft | 15 Windows, Windows 10, Windows 10 1607 and 12 more | 2026-01-02 | 7 High |
| Double free in Microsoft Wireless Provisioning System allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-62218 | 1 Microsoft | 15 Windows, Windows 10, Windows 10 1607 and 12 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Wireless Provisioning System allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-62217 | 1 Microsoft | 26 Windows, Windows 10, Windows 10 1607 and 23 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59508 | 1 Microsoft | 22 Windows, Windows 10, Windows 10 1607 and 19 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Speech allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59507 | 1 Microsoft | 22 Windows, Windows 10, Windows 10 1607 and 19 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Speech allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59506 | 1 Microsoft | 24 Windows, Windows 10, Windows 10 1607 and 21 more | 2026-01-02 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows DirectX allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-39905 | 1 Linux | 1 Linux Kernel | 2026-01-02 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred. | ||||
| CVE-2025-38232 | 1 Linux | 1 Linux Kernel | 2026-01-02 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs. | ||||