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

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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 (CVE-2025-39767)

The remote Debian 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6008 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6008-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     September 22, 2025                    https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2025-21751 CVE-2025-22103 CVE-2025-22113 CVE-2025-22124                      CVE-2025-22125 CVE-2025-23133 CVE-2025-38272 CVE-2025-38306                      CVE-2025-38453 CVE-2025-38502 CVE-2025-38556 CVE-2025-38676                      CVE-2025-38677 CVE-2025-38730 CVE-2025-38732 CVE-2025-38733                      CVE-2025-38734 CVE-2025-38735 CVE-2025-38736 CVE-2025-38737                      CVE-2025-39673 CVE-2025-39675 CVE-2025-39676 CVE-2025-39679                      CVE-2025-39681 CVE-2025-39682 CVE-2025-39683 CVE-2025-39684                      CVE-2025-39685 CVE-2025-39686 CVE-2025-39687 CVE-2025-39689                      CVE-2025-39691 CVE-2025-39692 CVE-2025-39693 CVE-2025-39694                      CVE-2025-39695 CVE-2025-39697 CVE-2025-39698 CVE-2025-39700                      CVE-2025-39701 CVE-2025-39702 CVE-2025-39703 CVE-2025-39705                      CVE-2025-39706 CVE-2025-39707 CVE-2025-39709 CVE-2025-39710                      CVE-2025-39711 CVE-2025-39712 CVE-2025-39713 CVE-2025-39714                      CVE-2025-39715 CVE-2025-39716 CVE-2025-39718 CVE-2025-39719                      CVE-2025-39720 CVE-2025-39721 CVE-2025-39722 CVE-2025-39723                      CVE-2025-39724 CVE-2025-39759 CVE-2025-39765 CVE-2025-39766                      CVE-2025-39767 CVE-2025-39770 CVE-2025-39772 CVE-2025-39773                      CVE-2025-39776 CVE-2025-39779 CVE-2025-39780 CVE-2025-39781                      CVE-2025-39782 CVE-2025-39783 CVE-2025-39787 CVE-2025-39788                      CVE-2025-39790 CVE-2025-39791 CVE-2025-39800 CVE-2025-39801                      CVE-2025-39805 CVE-2025-39806 CVE-2025-39807 CVE-2025-39808                      CVE-2025-39810 CVE-2025-39811 CVE-2025-39812 CVE-2025-39813                      CVE-2025-39815 CVE-2025-39817 CVE-2025-39819 CVE-2025-39823                      CVE-2025-39824 CVE-2025-39825 CVE-2025-39826 CVE-2025-39827                      CVE-2025-39828 CVE-2025-39829 CVE-2025-39831 CVE-2025-39832                      CVE-2025-39835 CVE-2025-39836 CVE-2025-39838 CVE-2025-39839                      CVE-2025-39841 CVE-2025-39842 CVE-2025-39843 CVE-2025-39844                      CVE-2025-39845 CVE-2025-39846 CVE-2025-39847 CVE-2025-39848                      CVE-2025-39849 CVE-2025-39850 CVE-2025-39851 CVE-2025-39852                      CVE-2025-39853 CVE-2025-39854 CVE-2025-39857 CVE-2025-39860                      CVE-2025-39861 CVE-2025-39863 CVE-2025-39864 CVE-2025-39865                      CVE-2025-39866 CVE-2025-40300

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the stable distribution (trixie), these problems have been fixed in     version 6.12.48-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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     (CVE-2025-39767)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
465706	Echo: linux: security update to 6.12.48-1	Tenable Cloud Security	Echo Local Security Checks	Local	medium
465706	Echo: linux: security update to 6.12.48-1	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
265710	Debian dsa-6008 : ata-modules-6.12.31-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
264756	Linux Distros Unpatched Vulnerability : CVE-2025-39767	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2025-39767

medium

Tenable Plugins

medium

medium

high

medium