Total
145 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-36759 | 1 Microsoft | 2 Visual Studio 2019, Visual Studio 2022 | 2025-01-01 | 6.7 Medium |
| Visual Studio Elevation of Privilege Vulnerability | ||||
| CVE-2023-29360 | 1 Microsoft | 9 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 6 more | 2025-01-01 | 8.4 High |
| Microsoft Streaming Service Elevation of Privilege Vulnerability | ||||
| CVE-2023-23394 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-01-01 | 5.5 Medium |
| Client Server Run-Time Subsystem (CSRSS) Information Disclosure Vulnerability | ||||
| CVE-2023-21768 | 1 Microsoft | 2 Windows 11, Windows Server 2022 | 2025-01-01 | 7.8 High |
| Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability | ||||
| CVE-2023-21677 | 1 Microsoft | 11 Windows 10 1607, Windows 10 1809, Windows 10 20h2 and 8 more | 2025-01-01 | 7.5 High |
| Windows Internet Key Exchange (IKE) Extension Denial of Service Vulnerability | ||||
| CVE-2024-37339 | 1 Microsoft | 5 Sql 2016 Azure Connect Feature Pack, Sql Server 2016, Sql Server 2017 and 2 more | 2024-12-31 | 8.8 High |
| Microsoft SQL Server Native Scoring Remote Code Execution Vulnerability | ||||
| CVE-2024-37340 | 1 Microsoft | 5 Sql 2016 Azure Connect Feature Pack, Sql Server 2016, Sql Server 2017 and 2 more | 2024-12-31 | 8.8 High |
| Microsoft SQL Server Native Scoring Remote Code Execution Vulnerability | ||||
| CVE-2024-30090 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2024-12-31 | 7 High |
| Microsoft Streaming Service Elevation of Privilege Vulnerability | ||||
| CVE-2024-35250 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2024-12-31 | 7.8 High |
| Windows Kernel-Mode Driver Elevation of Privilege Vulnerability | ||||
| CVE-2024-21346 | 1 Microsoft | 4 Windows 11 21h2, Windows 11 22h2, Windows 11 23h2 and 1 more | 2024-12-31 | 7.8 High |
| Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2024-21338 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2024-12-31 | 7.8 High |
| Windows Kernel Elevation of Privilege Vulnerability | ||||
| CVE-2024-20664 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2024-12-31 | 6.5 Medium |
| Microsoft Message Queuing Information Disclosure Vulnerability | ||||
| CVE-2024-20663 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2024-12-31 | 6.5 Medium |
| Windows Message Queuing Client (MSMQC) Information Disclosure | ||||
| CVE-2024-20682 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2024-12-31 | 7.8 High |
| Windows Cryptographic Services Remote Code Execution Vulnerability | ||||
| CVE-2024-20680 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2024-12-31 | 6.5 Medium |
| Windows Message Queuing Client (MSMQC) Information Disclosure | ||||
| CVE-2024-42072 | 1 Linux | 1 Linux Kernel | 2024-12-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix may_goto with negative offset. Zac's syzbot crafted a bpf prog that exposed two bugs in may_goto. The 1st bug is the way may_goto is patched. When offset is negative it should be patched differently. The 2nd bug is in the verifier: when current state may_goto_depth is equal to visited state may_goto_depth it means there is an actual infinite loop. It's not correct to prune exploration of the program at this point. Note, that this check doesn't limit the program to only one may_goto insn, since 2nd and any further may_goto will increment may_goto_depth only in the queued state pushed for future exploration. The current state will have may_goto_depth == 0 regardless of number of may_goto insns and the verifier has to explore the program until bpf_exit. | ||||
| CVE-2024-40978 | 1 Redhat | 3 Enterprise Linux, Rhel E4s, Rhel Eus | 2024-12-19 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix crash while reading debugfs attribute The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d | ||||
| CVE-2024-36929 | 1 Redhat | 5 Enterprise Linux, Rhel Aus, Rhel E4s and 2 more | 2024-12-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: core: reject skb_copy(_expand) for fraglist GSO skbs SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment. | ||||
| CVE-2024-26807 | 2024-12-19 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver. | ||||
| CVE-2024-26799 | 2024-12-19 | 6.2 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch] | ||||