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

Project Subscriptions

Vendors Products
Linux Kernel Subscribe
Enterprise Linux Subscribe
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Thu, 20 Mar 2025 07:00:00 +0000

Type Values Removed Values Added
CPEs cpe:/a:redhat:enterprise_linux:9
cpe:/o:redhat:enterprise_linux:9

Fri, 10 Jan 2025 18:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-367
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.6:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.6:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.6:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.6:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.6:rc5:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
Metrics cvssV3_1

{'score': 6.0, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H'}

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}


Mon, 04 Nov 2024 15:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Tue, 24 Sep 2024 11:15:00 +0000

Type Values Removed Values Added
CPEs cpe:/o:redhat:enterprise_linux:8

Tue, 24 Sep 2024 06:45:00 +0000

Type Values Removed Values Added
First Time appeared Redhat
Redhat enterprise Linux
CPEs cpe:/a:redhat:enterprise_linux:8::nfv
Vendors & Products Redhat
Redhat enterprise Linux

Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-01-05T10:16:12.328Z

Reserved: 2024-02-20T12:30:33.298Z

Link: CVE-2023-52478

cve-icon Vulnrichment

Updated: 2024-08-02T23:03:19.785Z

cve-icon NVD

Status : Analyzed

Published: 2024-02-29T06:15:45.920

Modified: 2025-01-10T18:27:26.213

Link: CVE-2023-52478

cve-icon Redhat

Severity : Low

Publid Date: 2024-02-29T00:00:00Z

Links: CVE-2023-52478 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses