CVE-2023-52635 in Linux
Summary
by MITRE • 04/02/2024
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1].
while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done
It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted.
[1]
... .. -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
[2]
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][ C4] Mem abort info:
[ 9436.261666][ C4] ESR = 0x96000044
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][ C4] SET = 0, FnV = 0
[ 9436.261673][ C4] EA = 0, S1PTW = 0
[ 9436.261675][ C4] Data abort info:
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
[ 9436.261680][ C4] CM = 0, WnR = 1
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
...
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][ C4] sp : ffffffc010023dd0
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
---truncated---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/17/2025
The vulnerability CVE-2023-52635 resides within the Linux kernel's power management subsystem, specifically in the devfreq framework responsible for device frequency management. This issue manifests as a race condition during governor switching operations that leads to timer list corruption and subsequent kernel oops. The flaw occurs when rapid succession of governor changes triggers concurrent execution paths that manipulate the same timer structure from multiple contexts, resulting in inconsistent state management within the kernel's timer subsystem.
The technical root cause stems from inadequate synchronization between device monitoring start and stop operations within the devfreq driver. When a loop continuously switches governors between "simple_ondemand" and "performance" modes, the system experiences a scenario where timer cancellation and re-initialization occur simultaneously from different execution contexts. The kernel trace data reveals multiple timer_cancel operations followed by timer_start operations on the same timer instance, indicating that the timer structure is being manipulated concurrently. This race condition creates a scenario where the timer_list structure becomes corrupted, leading to invalid memory access patterns during timer expiration.
The operational impact of this vulnerability is significant as it can result in system instability and potential kernel crashes. The corruption of timer structures during concurrent governor switching operations causes the kernel to attempt accessing invalid memory addresses, as evidenced by the page fault at virtual address dead00000000012a. This memory access violation triggers a kernel oops condition that ultimately leads to system panic or reboot. The vulnerability is particularly concerning in embedded systems and mobile devices where devfreq governors are frequently adjusted based on workload demands, making the race condition more likely to occur in production environments.
Mitigation strategies for this vulnerability involve implementing proper synchronization mechanisms within the devfreq driver to ensure exclusive access to timer operations. The fix requires introducing a polling flag and devfreq lock to serialize access to timer queueing operations and prevent concurrent modifications to the same timer instance. This approach aligns with common practices for preventing race conditions in kernel-level code and follows the principles outlined in the Common Weakness Enumeration (CWE) category CWE-362 for concurrent execution using locks. The solution must ensure that timer_start and timer_cancel operations occur atomically, preventing the scenario where one execution path cancels a timer while another is in the process of starting or expiring it. Additionally, the fix should integrate with the existing kernel timer subsystem to maintain compatibility with existing power management functionality while providing the necessary thread safety guarantees.
This vulnerability demonstrates a classic example of improper locking in kernel space, where the lack of coordination between concurrent operations leads to memory corruption. The ATT&CK framework would classify this as a kernel exploit technique, specifically targeting operating system kernel vulnerabilities. The issue affects systems running Linux kernel versions where the devfreq subsystem has not been patched, particularly impacting mobile devices and embedded systems that rely heavily on dynamic frequency scaling for power management. The vulnerability highlights the importance of proper synchronization primitives in kernel development and serves as a reminder of the critical nature of race condition prevention in system-level software components.