CVE-2025-38378 in Linux
Sumário
de VulDB • 29/06/2026
Based on the KASAN report and the description provided, here is an analysis of the bug and the proposed fix for the `appletb` keyboard driver in the Linux kernel.
### Problem Analysis
1. **The Bug**: A use-after-free (UAF) vulnerability exists in the `appletb_kbd_probe()` function. 2. **Root Cause**: When `probe()` fails after a timer has been initialized but before it is properly cleaned up, the failure path does not disarm/delete the timer. Consequently: * The memory allocated for the device structure (including the timer) may be freed during cleanup or by subsequent operations. * However, the hardware timer remains active in the background. * When the timer fires later (`__pfx_run_timer_softirq` -> `hrtimer_run_queues`), it accesses memory that has already been freed (via `devres_release_group` during probe failure cleanup). 3. **Secondary Issue**: In `appletb_kbd_remove()`, `timer_delete_sync()` is called unconditionally, even if the backlight device was never successfully created or initialized. This can lead to operations on uninitialized data structures.
### Solution Strategy
1. **Fix Probe Failure Paths**: Ensure that any timer started during `probe()` is properly deleted using `timer_delete_sync()` before returning an error code from any failure path within `appletb_kbd_probe()`. 2. **Guard Remove Function**: Add a check in `appletb_kbd_remove()` to ensure the backlight device (and associated resources) are valid before attempting to delete the timer.
### Code Fix Example
Below is an illustrative patch based on typical kernel driver patterns for this issue:
```c // In appletb_kbd_probe() static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id *id) {
// ... existing code ...
/* Initialize timer */ setup_timer(&kbd->backlight_poll_timer, backlight_work_func, (unsigned long)kbd);
// ... other initialization steps that might fail ...
if (some_condition_fails()) {
dev_err(&hdev->dev, "Failed to initialize something\n"); /* FIX: Delete the timer before returning error */ timer_delete_sync(&kbd->backlight_poll_timer); return -ENOMEM; // or appropriate error code }
if (another_condition_fails()) {
dev_err(&hdev->dev, "Failed to register something\n"); /* FIX: Delete the timer before returning error */ timer_delete_sync(&kbd->backlight_poll_timer); return -ENODEV; // or appropriate error code }
/* If we reach here, probe succeeded. Timer is active and managed by driver lifecycle. */ // ... rest of successful probe ... }
// In appletb_kbd_remove() static void appletb_kbd_remove(struct hid_device *hdev) {
struct appletb_kbd *kbd = hid_get_drvdata(hdev);
/* FIX: Only delete timer if backlight device was successfully created */ if (kbd->backlight_dev) {
timer_delete_sync(&kbd->backlight_poll_timer); // ... other cleanup code for backlight ... backlight_device_unregister(kbd->backlight_dev); }
/* Free any other resources allocated during probe that didn't depend on success */ } ```
### Key Points of the Fix
1. **`timer_delete_sync()`**: This function is critical because it not only deletes the timer but also waits for any currently executing handler to finish. This prevents race conditions where a timer might be deleted while its callback is still running, which could lead to another UAF or corruption scenario. 2. **Consistency in Failure Paths**: Every `goto` label or direct return from an error path after the timer has been set up must include `timer_delete_sync()`. This ensures no dangling timers remain if initialization fails partway through. 3. **Conditional Removal**: Checking for `kbd->backlight_dev` (or a similar flag indicating successful partial init) in `remove()` prevents accessing invalid pointers or calling cleanup functions on uninitialized structures, which could cause crashes during module unload or device removal after a failed probe.
This fix addresses both the immediate UAF issue reported by KASAN and improves robustness against potential issues during driver teardown.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.