Total
435 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-22394 | 2025-01-15 | 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-42444 | 2025-01-14 | 7.5 High | ||
| APTIOV contains a vulnerability in BIOS where an attacker may cause a TOCTOU Race Condition by local means. Successful exploitation of this vulnerability may lead to execution of arbitrary code on the target device. | ||||
| CVE-2023-52478 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-10 | 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-41787 | 1 Ibm | 1 Engineering Requirements Management Doors | 2025-01-10 | 9.8 Critical |
| IBM Engineering Requirements Management DOORS Next 7.0.2 and 7.0.3 could allow a remote attacker to bypass security restrictions, caused by a race condition. By sending a specially crafted request, an attacker could exploit this vulnerability to remotely execute code. | ||||
| CVE-2024-30084 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2025-01-09 | 7 High |
| Windows Kernel-Mode Driver Elevation of Privilege Vulnerability | ||||
| CVE-2024-43452 | 1 Microsoft | 11 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 8 more | 2025-01-09 | 7.5 High |
| Windows Registry Elevation of Privilege Vulnerability | ||||
| CVE-2024-49998 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up). | ||||
| CVE-2024-27114 | 2 So Planning, Soplanning | 2 Simple Online Planning, Soplanning | 2025-01-09 | 9.8 Critical |
| A unauthenticated Remote Code Execution (RCE) vulnerability is found in the SO Planning online planning tool. If the public view setting is enabled, a attacker can upload a PHP-file that will be available for execution for a few milliseconds before it is removed, leading to execution of code on the underlying system. The vulnerability has been remediated in version 1.52.02. | ||||
| CVE-2024-42107 | 2 Linux, Redhat | 2 Linux Kernel, Rhel Eus | 2025-01-08 | 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 | 7.8 High |
| Windows Kernel Elevation of Privilege Vulnerability | ||||
| CVE-2022-43778 | 1 Hp | 774 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 771 more | 2025-01-06 | 7.8 High |
| Potential Time-of-Check to Time-of Use (TOCTOU) vulnerabilities have been identified in the HP BIOS for certain HP PC products which may allow arbitrary code execution, denial of service, and information disclosure. | ||||
| CVE-2022-43777 | 1 Hp | 774 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 771 more | 2025-01-06 | 7.8 High |
| Potential Time-of-Check to Time-of Use (TOCTOU) vulnerabilities have been identified in the HP BIOS for certain HP PC products which may allow arbitrary code execution, denial of service, and information disclosure. | ||||
| CVE-2022-27541 | 1 Hp | 774 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 771 more | 2025-01-03 | 7.8 High |
| Potential Time-of-Check to Time-of Use (TOCTOU) vulnerabilities have been identified in the HP BIOS for certain HP PC products which may allow arbitrary code execution, denial of service, and information disclosure. | ||||
| CVE-2022-27539 | 1 Hp | 774 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 771 more | 2025-01-03 | 7.8 High |
| Potential Time-of-Check to Time-of Use (TOCTOU) vulnerabilities have been identified in the HP BIOS for certain HP PC products which may allow arbitrary code execution, denial of service, and information disclosure. | ||||
| CVE-2022-31638 | 1 Hp | 806 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 803 more | 2025-01-03 | 7.8 High |
| Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure. | ||||
| CVE-2022-31637 | 1 Hp | 806 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 803 more | 2025-01-03 | 7.8 High |
| Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure. | ||||
| CVE-2022-31639 | 1 Hp | 806 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 803 more | 2025-01-03 | 7.8 High |
| Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure. | ||||
| CVE-2022-31636 | 1 Hp | 806 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 803 more | 2025-01-03 | 7.8 High |
| Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure. | ||||
| CVE-2022-31635 | 1 Hp | 806 Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc, Dragonfly Folio 13.5 Inch G3 2-in-1 Notebook Pc Firmware, Elite Dragonfly and 803 more | 2025-01-03 | 7.8 High |
| Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure. | ||||
| CVE-2024-56337 | 2025-01-03 | 9.8 Critical | ||
| Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97. The mitigation for CVE-2024-50379 was incomplete. Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat: - running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true) - running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false) - running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed) Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system. Tomcat will also set sun.io.useCanonCaches to false by default where it can. | ||||