CVE-2025-39767

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Sep 11, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug on certain hardware can make the system freeze for many seconds while loading big device drivers, and the fix simply makes that loading step much faster.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Denial Of Service
Component: OS kernel
Class: Denial of service
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

O(n^2) algorithm in module_frob_arch_sections() for counting PLT/GOT relocations on LoongArch causes excessive CPU hold time during init_module when CONFIG_KASAN and CONFIG_PREEMPT_VOLUNTARY are enabled, triggering RCU stalls.

Why it matters to the business

Kernel module loads for large drivers can stall CPUs long enough to prevent normal boot or operation, reducing system availability on affected LoongArch deployments; the low EPSS indicates limited external exploit risk but the DoS effect is reproducible with normal driver loading.

How an attack unfolds

Trigger loading of a module containing thousands of relocations (for example amdgpu); the unsorted relocation scan repeatedly rescans the list inside count_max_entries(), holding the CPU until the RCU grace period expires and a self-detected stall is logged.

How to fix it

Update the Linux kernel to commit 5189c0b7c251363a4dd7678ed11b054c54f36f6f or later; the change sorts the relocation list by info and addend so duplicate checks become O(1) per entry and overall complexity drops to O(n log n).

How to confirm the fix worked

Confirm the running kernel contains commit 5189c0b7c251363a4dd7678ed11b054c54f36f6f; re-measure module load times for amdgpu or radeon before and after the update to verify the reduction from ~1.4 s to ~45 ms.

Typical attack path

Load a kernel module with a large number of relocations on LoongArch
module_frob_arch_sections calls count_max_entries on an unsorted RELA list
Duplicate checks perform O(n) work per entry resulting in quadratic runtime
CPU remains inside the module loader for seconds to minutes
RCU scheduler detects stall and logs the backtrace through kasan_mem_to_shadow and hrtimer paths

How to detect it

Inspect kernel logs for RCU self-detected stall messages that list module_frob_arch_sections and kasan_mem_to_shadow in the call trace; correlate with init_module or insmod activity on LoongArch systems.

What your security team should do

Prioritize patching LoongArch systems that enable KASAN or voluntary preemption and load large modules
Apply the referenced commit or the corresponding stable backport immediately
Monitor module load times during boot or driver initialization as a regression test

The record

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Optimize module load time by optimizing PLT/GOT counting When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows: rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158 After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock. When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity. To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations. After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace". Using the default configuration to test some modules, the results are as follows: Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098 With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098

Affected packages

Ecosystem	Package	Introduced	Fixed
Debian:12	linux	0	No fix
Debian:13	linux	0	No fix
Debian:14	linux	0	No fix
Debian:14	linux	0	6.16.5-1
Linux	Kernel	5.19.0	6.6.103