Total
620 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-20623 | 3 Google, Mediatek, Yoctoproject | 37 Android, Mt6580, Mt6735 and 34 more | 2025-03-06 | N/A | 6.4 MEDIUM |
| In ion, there is a possible escalation of privilege due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07559778; Issue ID: ALPS07559778. | |||||
| CVE-2024-53028 | 2025-03-03 | N/A | 7.8 HIGH | ||
| Memory corruption may occur while processing message from frontend during allocation. | |||||
| CVE-2023-0778 | 2 Podman Project, Redhat | 2 Podman, Enterprise Linux | 2025-02-24 | N/A | 6.8 MEDIUM |
| A Time-of-check Time-of-use (TOCTOU) flaw was found in podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system. | |||||
| CVE-2025-24036 | 1 Microsoft | 1 Autoupdate | 2025-02-14 | N/A | 7.0 HIGH |
| Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability | |||||
| CVE-2024-38418 | 1 Qualcomm | 124 C-v2x 9150, C-v2x 9150 Firmware, Csrb31024 and 121 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while parsing the memory map info in IOCTL calls. | |||||
| CVE-2024-45560 | 1 Qualcomm | 74 Aqt1000, Aqt1000 Firmware, Fastconnect 6200 and 71 more | 2025-02-05 | N/A | 7.8 HIGH |
| Memory corruption while taking a snapshot with hardware encoder due to unvalidated userspace buffer. | |||||
| CVE-2022-21198 | 1 Intel | 894 Celeron 1000m, Celeron 1000m Firmware, Celeron 1005m and 891 more | 2025-02-04 | N/A | 7.9 HIGH |
| Time-of-check time-of-use race condition in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. | |||||
| CVE-2024-53289 | 1 Dell | 1 Thinos | 2025-02-04 | N/A | 7.8 HIGH |
| Dell ThinOS version 2408 contains a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges. | |||||
| CVE-2025-22394 | 1 Dell | 1 Display Manager | 2025-02-04 | N/A | 6.7 MEDIUM |
| Dell Display Manager, versions prior to 2.3.2.18, contain a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to code execution and possibly privilege escalation. | |||||
| CVE-2024-27134 | 1 Lfprojects | 1 Mlflow | 2025-02-03 | N/A | 7.0 HIGH |
| Excessive directory permissions in MLflow leads to local privilege escalation when using spark_udf. This behavior can be exploited by a local attacker to gain elevated permissions by using a ToCToU attack. The issue is only relevant when the spark_udf() MLflow API is called. | |||||
| CVE-2022-38730 | 1 Docker | 1 Desktop | 2025-01-31 | N/A | 6.3 MEDIUM |
| Docker Desktop for Windows before 4.6 allows attackers to overwrite any file through the windowscontainers/start dockerBackendV2 API by controlling the data-root field inside the DaemonJSON field in the WindowsContainerStartRequest class. This allows exploiting a symlink vulnerability in ..\dataRoot\network\files\local-kv.db because of a TOCTOU race condition. | |||||
| CVE-2024-0163 | 1 Dell | 116 Emc Xc Core Xc450, Emc Xc Core Xc450 Firmware, Emc Xc Core Xc650 and 113 more | 2025-01-31 | N/A | 5.3 MEDIUM |
| Dell PowerEdge Server BIOS and Dell Precision Rack BIOS contain a TOCTOU race condition vulnerability. A local low privileged attacker could potentially exploit this vulnerability to gain access to otherwise unauthorized resources. | |||||
| CVE-2021-46792 | 1 Amd | 110 Athlon Gold 3150g, Athlon Gold 3150g Firmware, Athlon Gold 3150ge and 107 more | 2025-01-28 | N/A | 5.9 MEDIUM |
| Time-of-check Time-of-use (TOCTOU) in the BIOS2PSP command may allow an attacker with a malicious BIOS to create a race condition causing the ASP bootloader to perform out-of-bounds SRAM reads upon an S3 resume event potentially leading to a denial of service. | |||||
| CVE-2021-26356 | 1 Amd | 196 Epyc 7001, Epyc 7001 Firmware, Epyc 7002 and 193 more | 2025-01-28 | N/A | 7.4 HIGH |
| A TOCTOU in ASP bootloader may allow an attacker to tamper with the SPI ROM following data read to memory potentially resulting in S3 data corruption and information disclosure. | |||||
| CVE-2024-28137 | 1 Phoenixcontact | 8 Charx Sec-3000, Charx Sec-3000 Firmware, Charx Sec-3050 and 5 more | 2025-01-23 | N/A | 7.8 HIGH |
| A local attacker with low privileges can perform a privilege escalation with an init script due to a TOCTOU vulnerability. | |||||
| CVE-2023-25394 | 1 Getvideostream | 1 Videostream | 2025-01-23 | N/A | 7.0 HIGH |
| Videostream macOS app 0.5.0 and 0.4.3 has a Race Condition. The Updater privileged script attempts to update Videostream every 5 hours. | |||||
| CVE-2024-29066 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2025-01-16 | N/A | 7.2 HIGH |
| Windows Distributed File System (DFS) Remote Code Execution Vulnerability | |||||
| CVE-2023-52478 | 1 Linux | 1 Linux Kernel | 2025-01-10 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- | |||||
| CVE-2024-42107 | 1 Linux | 1 Linux Kernel | 2025-01-08 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ice: Don't process extts if PTP is disabled The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic. Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs. To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready. | |||||
| CVE-2024-26218 | 1 Microsoft | 9 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 6 more | 2025-01-08 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||