Description

In the Linux kernel, the following vulnerability has been resolved: char: tlclk: fix use-after-free in tlclk_cleanup() This patch improves the module cleanup process in the tlclk driver to prevent potential use-after-free and race conditions. Currently, the file_operations structure does not specify the .owner field, which could allow the module to be unloaded while user-space processes are still interacting with the device. Additionally, the tlclk_cleanup() function frees the alarm_events memory before ensuring that blocked processes in the waitqueue are fully awakened and that the switchover_timer has completed. To address these cases, this patch: - Sets '.owner = THIS_MODULE' in tlclk_fops to safely defer module unloading while the device is in use. - Updates tlclk_cleanup() to explicitly wake up all blocked readers (wake_up_all), properly release hardware I/O regions, and safely delete the timer (timer_delete_sync) prior to freeing memory.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:46.320Z",
  "pubdate": "2026-08-28T08:16:46.320Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) condition within the Linux kernel tlclk character device driver, stemming from improper module cleanup and missing reference counting in the file_operations structure.\nThe vulnerability allows for potential race conditions during module unloading, which could be leveraged to trigger memory corruption or arbitrary code execution.\nThe affected system component is the tlclk driver, specifically the cleanup routine and the file_operations initialization.\nThe risk is categorized as high, as successful exploitation could lead to kernel-level memory corruption, system instability, or privilege escalation.\nExploitation requires an attacker to have local access to the system and the ability to interact with the device node while simultaneously triggering module removal, typically requiring local user privileges to open the character device.",
  "technicalDetails": "The vulnerability resides in the tlclk_cleanup() function and the insufficient configuration of the tlclk_fops structure. The lack of the .owner field in file_operations means the kernel does not maintain a reference count on the module when a user-space process maintains an open file descriptor to the device.\nThe root cause is a race condition during module unloading. When a user-space process holds a file descriptor for the tlclk device, the kernel does not prevent the driver module from being unloaded. If the module is removed, the driver's cleanup code proceeds to release resources, specifically the alarm_events memory, while other kernel threads or user-space processes might still be referencing those memory addresses via pending operations.\nThe attack flow begins when an attacker opens the tlclk device node. While the device is in use, the attacker initiates a module unload operation (e.g., via rmmod). Because the .owner field is missing, the kernel fails to increment the module's usage counter, allowing the cleanup sequence to execute.\nWithin tlclk_cleanup(), the driver prematurely frees the alarm_events buffer. If the system has blocked processes waiting on the device's waitqueue or an active switchover_timer, these entities may attempt to access the memory location previously occupied by alarm_events after it has been deallocated (a classic UAF pattern).\nFurthermore, the original implementation failed to ensure the switchover_timer was inactive and that all blocked readers were properly awakened before memory release. This increases the window of opportunity for a race condition where the timer callback or the woken reader attempts to interact with non-existent or stale memory.\nSuccessful exploitation results in kernel memory corruption. An attacker could potentially gain control over execution flow if they can influence the contents of the re-allocated memory block before the dangling pointer in the timer callback or waitqueue reader is dereferenced. The impact includes system crashes (kernel panic) or potential local privilege escalation to the kernel execution context."
}