← Back to CVE intelligence
CVE intelligence

CVE-2025-22035

Vulnerability intelligence

Published Apr 16, 2025Sources checked Oct 9, 2026
7.8HIGHCVSS out of 10
What this means

Review the available evidence

CVE-2025-22035 and is rated High severity with a CVSS score of 7.8. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Microsoft Security Response Center guidance

Vendor revision: Aug 12, 2026

CBL-Mariner Releases

Vendor-listed releases

  • 5.15.180.1-1
  • 6.6.92.2-1
CISA KEVNot listedBased on the latest collected catalog
EPSS0.3%Estimated 30-day exploitation probability
Ransomware useNot markedCISA KEV ransomware field
Threat actors0Source-linked actor relationships
Overview

What is CVE-2025-22035?

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

tracing: Fix use-after-free in print_graph_function_flags during tracer switching

Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script:

$ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer

The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show():

* One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.

Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags.

Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.

To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.

[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

Source: NVD