The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade Rocky-Linux:8
kernel-rt-debug-devel
to version 0:4.18.0-553.22.1.rt7.363.el8_10 or higher.
This issue was patched in RLSA-2024:7001
.
Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug-devel
package and not the kernel-rt-debug-devel
package as distributed by Rocky-Linux
.
See How to fix?
for Rocky-Linux:8
relevant fixed versions and status.
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):
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:
Updating the name to the HIDPP name (harmless race):
if (hidpp->name == hdev->name) { ... hidpp->name = new_name; }
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);
}
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:
This causes a use after free scenario on USB disconnect of the receiver:
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---