Total
33260 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-46789 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following warning always occurs,This is because the following call stack occurred: mem_pool_alloc kmem_cache_alloc_noprof slab_alloc_node kfence_alloc Once the kfence allocation is successful,slab->obj_exts will not be empty, because it has already been assigned a value in kfence_init_pool. Since in the prepare_slab_obj_exts_hook function,we perform a check for s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function will not be called as a result.Therefore,ref->ct remains NULL. However,when we call mem_pool_free,since obj_ext is not empty, it eventually leads to the alloc_tag_sub scenario being invoked. This is where the warning occurs. So we should add corresponding checks in the alloc_tagging_slab_free_hook. For __GFP_NO_OBJ_EXT case,I didn't see the specific case where it's using kfence,so I won't add the corresponding check in alloc_tagging_slab_free_hook for now. [ 3.734349] ------------[ cut here ]------------ [ 3.734807] alloc_tag was not set [ 3.735129] WARNING: CPU: 4 PID: 40 at ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574 [ 3.735866] Modules linked in: autofs4 [ 3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Tainted: G W 6.11.0-rc3-dirty #1 [ 3.736969] Tainted: [W]=WARN [ 3.737258] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [ 3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.738501] pc : kmem_cache_free+0x444/0x574 [ 3.738951] lr : kmem_cache_free+0x444/0x574 [ 3.739361] sp : ffff80008357bb60 [ 3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000 [ 3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700 [ 3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000 [ 3.741630] x20: fffffd7ff8253360 x19: 00000000000000a8 x18: ffffffffffffffff [ 3.742274] x17: ffff800ab327f000 x16: ffff800083398000 x15: ffff800081756df0 [ 3.742919] x14: 0000000000000000 x13: 205d344320202020 x12: 5b5d373038343337 [ 3.743560] x11: ffff80008357b650 x10: 000000000000005d x9 : 00000000ffffffd0 [ 3.744231] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008237bad0 x6 : c0000000ffff7fff [ 3.744907] x5 : ffff80008237ba78 x4 : ffff8000820bbad0 x3 : 0000000000000001 [ 3.745580] x2 : 68d66547c09f7800 x1 : 68d66547c09f7800 x0 : 0000000000000000 [ 3.746255] Call trace: [ 3.746530] kmem_cache_free+0x444/0x574 [ 3.746931] mem_pool_free+0x44/0xf4 [ 3.747306] free_object_rcu+0xc8/0xdc [ 3.747693] rcu_do_batch+0x234/0x8a4 [ 3.748075] rcu_core+0x230/0x3e4 [ 3.748424] rcu_core_si+0x14/0x1c [ 3.748780] handle_softirqs+0x134/0x378 [ 3.749189] run_ksoftirqd+0x70/0x9c [ 3.749560] smpboot_thread_fn+0x148/0x22c [ 3.749978] kthread+0x10c/0x118 [ 3.750323] ret_from_fork+0x10/0x20 [ 3.750696] ---[ end trace 0000000000000000 ]--- | |||||
| CVE-2024-46825 | 1 Linux | 1 Linux Kernel | 2024-11-20 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON(). | |||||
| 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 | 7.5 HIGH |
| 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 | 8.0 HIGH |
| 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-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 | |||||
| CVE-2024-43602 | 1 Microsoft | 1 Azure Cyclecloud | 2024-11-19 | N/A | 9.9 CRITICAL |
| Azure CycleCloud Remote Code Execution Vulnerability | |||||
| CVE-2024-43624 | 1 Microsoft | 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more | 2024-11-19 | N/A | 8.8 HIGH |
| Windows Hyper-V Shared Virtual Disk Elevation of Privilege Vulnerability | |||||