Total
31745 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2024-49858 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. | |||||
CVE-2024-47667 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf | |||||
CVE-2024-47659 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 8.8 HIGH |
In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. | |||||
CVE-2024-47658 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. | |||||
CVE-2024-38197 | 1 Microsoft | 1 Teams | 2024-10-22 | N/A | 6.5 MEDIUM |
Microsoft Teams for iOS Spoofing Vulnerability | |||||
CVE-2024-38265 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-38261 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 7.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-38212 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43593 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43592 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43589 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43453 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43607 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-43608 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-9537 | 1 Sciencelogic | 1 Sl1 | 2024-10-22 | N/A | 9.8 CRITICAL |
ScienceLogic SL1 (formerly EM7) is affected by an unspecified vulnerability involving an unspecified third-party component packaged with SL1. The vulnerability is addressed in SL1 versions 12.1.3+, 12.2.3+, and 12.3+. Remediations have been made available for all SL1 versions back to version lines 10.1.x, 10.2.x, 11.1.x, 11.2.x, and 11.3.x. | |||||
CVE-2024-43611 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 8.8 HIGH |
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||
CVE-2024-7890 | 1 Citrix | 1 Workspace | 2024-10-22 | N/A | 7.3 HIGH |
Local privilege escalation allows a low-privileged user to gain SYSTEM privileges in Citrix Workspace app for Windows | |||||
CVE-2024-7889 | 1 Citrix | 1 Workspace | 2024-10-22 | N/A | 7.3 HIGH |
Local privilege escalation allows a low-privileged user to gain SYSTEM privileges in Citrix Workspace app for Windows | |||||
CVE-2024-38124 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-10-22 | N/A | 9.0 CRITICAL |
Windows Netlogon Elevation of Privilege Vulnerability | |||||
CVE-2024-38129 | 1 Microsoft | 1 Windows Server 2022 23h2 | 2024-10-22 | N/A | 6.6 MEDIUM |
Windows Kerberos Elevation of Privilege Vulnerability |