CVE-2025-37747 Affecting kernel-syms package, versions <6.4.0-150700.53.3.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES157-KERNELSYMS-10357039
  • published14 Jun 2025
  • disclosed13 Jun 2025

Introduced: 13 Jun 2025

NewCVE-2025-37747  (opens in a new tab)

How to fix?

Upgrade SLES:15.7 kernel-syms to version 6.4.0-150700.53.3.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-syms package and not the kernel-syms package as distributed by SLES. See How to fix? for SLES:15.7 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

perf: Fix hang while freeing sigtrap event

Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed:

perf_event_overflow() task_work_add(perf_pending_task)

fput() task_work_add(____fput())

task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event()

Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event().

Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg:

T1 T2

fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> fput() fput() task_work_add(____fput()) task_work_add(____fput())

task_work_run()                                        task_work_run()
    ____fput()                                             ____fput()
        perf_release()                                         perf_release()
            perf_event_release_kernel()                            perf_event_release_kernel()
                _free_event()                                          _free_event()
                    perf_pending_task_sync()                               perf_pending_task_sync()
                        rcuwait_wait_event()                                   rcuwait_wait_event()

Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed.

Some adjustments are necessary to make it work:

  • A child event might dereference its parent upon freeing. Care must be taken to release the parent last.

  • Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job.

CVSS Base Scores

version 3.1