Skip to main content

CVE-2023-52478: Vulnerability in Linux Linux

High
VulnerabilityCVE-2023-52478cvecve-2023-52478
Published: Thu Feb 29 2024 (02/29/2024, 05:43:10 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

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---

AI-Powered Analysis

AILast updated: 07/01/2025, 09:27:42 UTC

Technical Analysis

CVE-2023-52478 is a vulnerability in the Linux kernel's Logitech HID++ driver (logitech-hidpp), specifically affecting the handling of USB receiver disconnect events. The root cause is a time-of-check to time-of-use (TOCTOU) race condition in the function hidpp_connect_event(), which can be invoked concurrently from multiple threads: one running from probe() and others from a workqueue triggered by device-connected packets. This concurrency leads to four distinct race conditions, with the most critical involving the initialization and registration of the power_supply class device representing the battery. Due to the race, two power_supply devices may be registered for the same battery, sharing a descriptor structure whose properties pointer is overwritten by the second registration. Upon USB receiver disconnect, the kernel unregisters these devices sequentially, freeing the memory pointed to by the shared descriptor's properties pointer. However, the first unregistration still references this now-freed memory when sending a remove uevent to userspace, causing a use-after-free scenario. This results in kernel crashes and page faults, as evidenced by kernel backtraces involving power_supply_uevent(). The vulnerability arises from improper synchronization and shared resource management in the driver, leading to memory corruption and system instability. While the races involving protocol retrieval and device name updates are benign, the battery power_supply registration race is severe. The issue affects Linux kernel versions identified by the commit hash 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and has been publicly disclosed without known exploits in the wild. No CVSS score is assigned yet, and no official patch links are provided in the data, but the vulnerability is acknowledged and published by the Linux project.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions with Logitech HID++ devices connected via USB receivers. The impact includes potential kernel crashes leading to denial of service (DoS) conditions, which can disrupt critical services and operations. In environments where Linux is used for servers, workstations, or embedded systems interfacing with Logitech peripherals, unexpected system instability could cause operational downtime, data loss, or interruptions in business processes. Although the vulnerability does not directly enable privilege escalation or remote code execution, the kernel crash and use-after-free could be leveraged in complex attack chains or targeted attacks against high-value assets. Organizations in sectors such as finance, healthcare, manufacturing, and government that rely on Linux infrastructure and Logitech hardware may experience increased risk. Additionally, the instability could complicate incident response and system reliability, especially in environments with limited physical access or automated recovery mechanisms. The lack of known exploits reduces immediate threat but does not eliminate the risk of future weaponization, making timely mitigation essential.

Mitigation Recommendations

1. Update the Linux kernel to a version that includes the fix for CVE-2023-52478 as soon as it becomes available from trusted Linux distribution vendors or the upstream Linux kernel. Monitor vendor advisories for patches addressing this specific HID++ race condition. 2. As a temporary workaround, consider disconnecting Logitech USB receivers or avoiding the use of affected Logitech HID++ devices on critical systems until patches are applied. 3. Implement kernel crash monitoring and automated recovery mechanisms to minimize downtime if the vulnerability is triggered. 4. For environments with custom kernel builds, apply the relevant patches from the Linux kernel source tree that fix the TOCTOU races in hidpp_connect_event(), ensuring proper synchronization and resource management. 5. Conduct thorough testing of Logitech device interactions post-patch to confirm resolution and prevent regressions. 6. Employ strict USB device control policies to limit unauthorized or unnecessary USB device connections, reducing exposure. 7. Maintain up-to-date system backups and incident response plans to recover quickly from potential crashes or instability caused by this vulnerability.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-02-20T12:30:33.298Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9831c4522896dcbe7aa0

Added to database: 5/21/2025, 9:09:05 AM

Last enriched: 7/1/2025, 9:27:42 AM

Last updated: 8/8/2025, 7:56:38 PM

Views: 14

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats