CVE-2025-39728 in Linux
Summary
by MITRE • 04/18/2025
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix UBSAN panic in samsung_clk_init()
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability CVE-2025-39728 represents a critical null pointer dereference issue within the Samsung clock driver of the Linux kernel that manifests specifically when Unified Kernel Sanitizer (UBSAN) array bounds checking is enabled. This flaw occurs during the initialization process of Samsung clock domains and stems from improper ordering of variable initialization within the samsung_clk_init() function. The vulnerability is categorized under CWE-476 as a null pointer dereference, which represents a fundamental error in memory management where code attempts to access memory through a pointer that has not been properly initialized or has been set to NULL.
The technical root cause of this vulnerability lies in the sequence of operations within the samsung_clk_init() function where the code attempts to dereference the ctx->clk_data.hws array before properly setting the ctx->clk_data.num variable to nr_clks. This improper initialization order creates a scenario where the UBSAN framework detects an array bounds violation when trying to access memory locations beyond the allocated array boundaries. The panic message indicates that the kernel crashes with an array index out of bounds error at address 00000000f2005512, demonstrating that the system attempts to access memory at an invalid offset within the hardware clock array structure. This type of vulnerability falls under the ATT&CK technique T1068 for locally executing code with elevated privileges and represents a potential denial of service condition that could be exploited in kernel space.
The operational impact of this vulnerability extends beyond simple system instability as it affects the proper initialization of clock domains within Samsung-based ARM64 systems, particularly those using Exynos SoCs. When the kernel attempts to register clock management units during system boot or runtime, the improper initialization sequence causes immediate system crashes, preventing normal operation of clock subsystems that are critical for system timing and power management. This vulnerability is particularly concerning in embedded systems and mobile devices where clock management is essential for proper hardware operation and battery efficiency. The crash occurs during the exynos_arm64_register_cmu function call chain, indicating that any system utilizing Samsung's Exynos-based clock management units would be susceptible to this issue when UBSAN is enabled in kernel configuration.
Mitigation strategies for this vulnerability require immediate kernel updates that restructure the initialization sequence to ensure that ctx->clk_data.num is set before ctx->clk_data.hws is accessed. The fix involves moving the assignment of nr_clks to ctx->clk_data.num prior to any operations that reference the hardware clock array. System administrators should prioritize applying kernel patches that address this specific ordering issue, as the vulnerability can be triggered during normal system boot processes or when clock management units are dynamically registered. Additionally, organizations should consider disabling UBSAN array bounds checking in production environments where this vulnerability exists, though this represents a temporary workaround rather than a permanent solution. The fix aligns with kernel security best practices for preventing initialization order bugs and maintaining proper memory allocation sequences in kernel modules, particularly those dealing with hardware resource management and clock domain initialization.