Total
31903 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-53051 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intel_hdcp_get_capability add a check to avoid kernel null pointer dereference. | |||||
| CVE-2024-46783 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: fix return value of tcp_bpf_sendmsg() When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case: 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES; Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]--- | |||||
| CVE-2024-46787 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels. | |||||
| CVE-2024-43447 | 1 Microsoft | 1 Windows Server 2022 | 2024-11-19 | N/A | 8.1 HIGH |
| Windows SMBv3 Server Remote Code Execution Vulnerability | |||||
| CVE-2024-38264 | 1 Microsoft | 5 Windows 11 22h2, Windows 11 23h2, Windows 11 24h2 and 2 more | 2024-11-19 | N/A | 5.9 MEDIUM |
| Microsoft Virtual Hard Disk (VHDX) Denial of Service Vulnerability | |||||
| CVE-2024-43449 | 1 Microsoft | 15 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 12 more | 2024-11-19 | N/A | 6.8 MEDIUM |
| Windows USB Video Class System Driver Elevation of Privilege Vulnerability | |||||
| CVE-2024-43450 | 1 Microsoft | 7 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 4 more | 2024-11-19 | N/A | 7.5 HIGH |
| Windows DNS Spoofing Vulnerability | |||||
| CVE-2024-43452 | 1 Microsoft | 11 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 8 more | 2024-11-19 | N/A | 7.5 HIGH |
| Windows Registry Elevation of Privilege Vulnerability | |||||
| CVE-2024-43459 | 1 Microsoft | 3 Sql Server 2016, Sql Server 2017, Sql Server 2019 | 2024-11-19 | N/A | 8.8 HIGH |
| SQL Server Native Client Remote Code Execution Vulnerability | |||||
| CVE-2024-43462 | 1 Microsoft | 3 Sql Server 2016, Sql Server 2017, Sql Server 2019 | 2024-11-19 | N/A | 8.8 HIGH |
| SQL Server Native Client Remote Code Execution Vulnerability | |||||
| CVE-2024-43498 | 3 Apple, Linux, Microsoft | 5 Macos, Linux Kernel, .net and 2 more | 2024-11-19 | N/A | 9.8 CRITICAL |
| .NET and Visual Studio Remote Code Execution Vulnerability | |||||
| CVE-2024-43499 | 3 Apple, Linux, Microsoft | 5 Macos, Linux Kernel, .net and 2 more | 2024-11-19 | N/A | 7.5 HIGH |
| .NET and Visual Studio Denial of Service Vulnerability | |||||
| CVE-2024-41167 | 1 Intel | 2 M10jnp2sb, M10jnp2sb Firmware | 2024-11-19 | N/A | 6.7 MEDIUM |
| Improper input validation in UEFI firmware in some Intel(R) Server Board M10JNP2SB Family may allow a privileged user to potentially enable escalation of privilege via local access. | |||||
| CVE-2024-48993 | 1 Microsoft | 3 Sql Server 2016, Sql Server 2017, Sql Server 2019 | 2024-11-19 | N/A | 8.8 HIGH |
| SQL Server Native Client Remote Code Execution Vulnerability | |||||
| CVE-2024-8979 | 1 Wpdeveloper | 1 Essential Addons For Elementor | 2024-11-19 | N/A | 5.7 MEDIUM |
| The Essential Addons for Elementor – Best Elementor Addon, Templates, Widgets, Kits & WooCommerce Builders plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 6.0.9 via the 'init_content_lostpassword_user_email_controls' function. This makes it possible for authenticated attackers, with Author-level access and above, to extract sensitive data including usernames and passwords of any user, including Administrators, as long as that user opens the email notification for a password change request and images are not blocked by the email client. | |||||
| CVE-2024-8978 | 1 Wpdeveloper | 1 Essential Addons For Elementor | 2024-11-19 | N/A | 5.7 MEDIUM |
| The Essential Addons for Elementor – Best Elementor Addon, Templates, Widgets, Kits & WooCommerce Builders plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 6.0.9 via the 'init_content_register_user_email_controls' function. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive data including usernames and passwords of any users who register via the Login | Register Form widget, as long as that user opens the email notification for successful registration. | |||||
| CVE-2024-50204 | 1 Linux | 1 Linux Kernel | 2024-11-19 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fs: don't try and remove empty rbtree node When copying a namespace we won't have added the new copy into the namespace rbtree until after the copy succeeded. Calling free_mnt_ns() will try to remove the copy from the rbtree which is invalid. Simply free the namespace skeleton directly. | |||||
| CVE-2024-50201 | 1 Linux | 1 Linux Kernel | 2024-11-19 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) | |||||
| CVE-2024-43530 | 1 Microsoft | 5 Windows 10 21h2, Windows 10 22h2, Windows 11 22h2 and 2 more | 2024-11-19 | N/A | 7.8 HIGH |
| Windows Update Stack Elevation of Privilege Vulnerability | |||||
| CVE-2024-43598 | 1 Microsoft | 1 Lightgbm | 2024-11-19 | N/A | 8.1 HIGH |
| LightGBM Remote Code Execution Vulnerability | |||||