Total
31934 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-21430 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2024-11-29 | N/A | 6.4 MEDIUM |
| Windows USB Attached SCSI (UAS) Protocol Remote Code Execution Vulnerability | |||||
| CVE-2024-21429 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2024-11-29 | N/A | N/A |
| Windows USB Hub Driver Remote Code Execution Vulnerability | |||||
| CVE-2024-21423 | 1 Microsoft | 1 Edge Chromium | 2024-11-29 | N/A | N/A |
| Microsoft Edge (Chromium-based) Information Disclosure Vulnerability | |||||
| CVE-2024-26192 | 1 Microsoft | 1 Edge Chromium | 2024-11-29 | N/A | N/A |
| Microsoft Edge (Chromium-based) Information Disclosure Vulnerability | |||||
| CVE-2024-26188 | 1 Microsoft | 1 Edge | 2024-11-29 | N/A | N/A |
| Microsoft Edge (Chromium-based) Spoofing Vulnerability | |||||
| CVE-2024-20671 | 1 Microsoft | 1 Windows Defender Antimalware Platform | 2024-11-29 | N/A | N/A |
| Microsoft Defender Security Feature Bypass Vulnerability | |||||
| CVE-2024-26167 | 1 Microsoft | 1 Edge | 2024-11-29 | N/A | N/A |
| Microsoft Edge for Android Spoofing Vulnerability | |||||
| CVE-2024-50182 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ | |||||
| CVE-2024-50179 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference. | |||||
| CVE-2024-50194 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | |||||
| CVE-2024-50193 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. | |||||
| CVE-2024-50192 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. | |||||
| CVE-2024-29988 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2024-11-29 | N/A | N/A |
| SmartScreen Prompt Security Feature Bypass Vulnerability | |||||
| CVE-2024-26169 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2024-11-29 | N/A | N/A |
| Windows Error Reporting Service Elevation of Privilege Vulnerability | |||||
| CVE-2024-21410 | 1 Microsoft | 1 Exchange Server | 2024-11-29 | N/A | N/A |
| Microsoft Exchange Server Elevation of Privilege Vulnerability | |||||
| CVE-2024-21351 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2024-11-29 | N/A | N/A |
| Windows SmartScreen Security Feature Bypass Vulnerability | |||||
| CVE-2024-21412 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2024-11-29 | N/A | N/A |
| Internet Shortcut Files Security Feature Bypass Vulnerability | |||||
| CVE-2023-41061 | 1 Apple | 3 Ipados, Iphone Os, Watchos | 2024-11-29 | N/A | 7.8 HIGH |
| A validation issue was addressed with improved logic. This issue is fixed in watchOS 9.6.2, iOS 16.6.1 and iPadOS 16.6.1. A maliciously crafted attachment may result in arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. | |||||
| CVE-2024-20947 | 1 Oracle | 1 Common Applications | 2024-11-29 | N/A | N/A |
| Vulnerability in the Oracle Common Applications product of Oracle E-Business Suite (component: CRM User Management Framework). Supported versions that are affected are 12.2.3-12.2.13. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Common Applications. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Common Applications, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Common Applications accessible data as well as unauthorized read access to a subset of Oracle Common Applications accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N). | |||||
| CVE-2024-20939 | 1 Oracle | 1 Customer Relationship Management Technical Foundation | 2024-11-29 | N/A | N/A |
| Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Admin Console). Supported versions that are affected are 12.2.3-12.2.13. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle CRM Technical Foundation. CVSS 3.1 Base Score 4.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L). | |||||