A serious security vulnerability, CVE-2024-56739, was recently discovered and patched in the Linux kernel. This issue affects how the kernel interacts with real-time clocks (RTC). If attackers manage to exploit this bug, it can cause the system to freeze (softlockup) or crash—a critical risk for any production server. In this post, I’ll explain how this bug works, show code snippets, cover how it was fixed, provide simple attack scenarios, and reference the original source.
The Vulnerable Component: rtc_timer_do_work()
The Linux kernel provides support for real-time clocks—the small hardware chips keeping date and time even when your PC is turned off. The kernel uses rtc_timer_do_work() to handle timer events for the RTC.
The function looks like this (truncated for clarity)
int rtc_timer_do_work(struct rtc_device *rtc)
{
struct rtc_time tm;
int err;
// Call to read RTC time into the struct rtc_time variable
err = __rtc_read_time(rtc, &tm);
/*
* ... more code ...
* If __rtc_read_time() fails, 'tm' might have garbage!
*/
ktime_t now = rtc_tm_to_ktime(&tm);
// Uses 'now' for scheduling timer events
}
Issue: The code calls __rtc_read_time() to fill in tm.
- What can go wrong? If __rtc_read_time() fails (returns an error), nothing checks for the error. The tm struct and thus now might have garbage values.
- Danger: When this corrupt value gets used (with rtc_tm_to_ktime()) to schedule RTC timers, it could result in a hugley incorrect time value (KTIME_MAX).
- Exploit effect: For kernels with periodic timers set up, this miscalculation triggers recurring expiry events—possibly saturating the event queue indefinitely. The system is busy serving fake timer events, and normal operations freeze (“kernel softlockup”).
The Fix
Linus Torvalds and collaborators fixed the code by *checking* the return value of __rtc_read_time() before using tm or passing it to anything else.
Fixed Code Example
int rtc_timer_do_work(struct rtc_device *rtc)
{
struct rtc_time tm;
int err;
err = __rtc_read_time(rtc, &tm);
if (err < ) {
// Log and skip the RTC timer processing
dev_warn(rtc->dev, "Failed to read RTC time: %d\n", err);
return err;
}
ktime_t now = rtc_tm_to_ktime(&tm);
// now safe to proceed
}
With this check, if reading the RTC somehow fails—due to hardware error or misconfiguration—the timer code is skipped, and no corrupted date/time values end up in the timer logic.
Attack Scenario
- Who needs access? Typically, only kernel or privileged code could trigger this. However, if an attacker can manipulate I2C/SPI-connected RTC hardware, or cause it to return error states (e.g., by physical attacks or fuzzing with a faulty RTC chip), they could indirectly exploit this bug.
- What could result? An unprivileged user may not directly cause this on a default Linux system, but faulty hardware, VM environments with buggy emulated RTCs, or crafty attackers with direct hardware access can trigger it.
- System Impact: If triggered, the machine will be overwhelmed by non-stop timer events, and may become unresponsive (kernel softlockup). This is worse on servers or embedded devices that rely on stable RTC handling.
Original Patch:
rtc: check if __rtc_read_time was successful in rtc_timer_do_work() - kernel/git/torvalds/linux.git
Linux Kernel Security Tracker:
Workqueue and Softlockup Explanation:
Kernel.org: Soft Lockups Explained
How to Protect Your Systems
- Update your Linux kernel to include the fix—at least version 6.7+ or your vendor’s backported patches.
- Monitor kernel logs for RTC timer errors and softlockup messages, especially on hardware with suspect RTC chips.
- Security best practices: Never allow untrusted peripherals or poorly emulated RTCs on critical systems.
Takeaway
CVE-2024-56739 is a logic bug that could freeze the Linux kernel via invalid RTC timer processing. The lesson? Always check the results of hardware reads, and don't trust uninitialized data structures, especially in kernel code.
Timeline
Published on: 12/29/2024 12:15:07 UTC
Last modified on: 01/07/2025 21:21:31 UTC