CVE-2025-22035

{"id": "CVE-2025-22035", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "published": "2025-04-16T15:15:56.110", "references": [{"url": "https://git.kernel.org/stable/c/099ef3385800828b74933a96c117574637c3fb3a", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/42561fe62c3628ea3bc9623f64f047605e98857f", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/70be951bc01e4a0e10d443f3510bb17426f257fb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7f81f27b1093e4895e87b74143c59c055c3b1906", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/81a85b12132c8ffe98f5ddbdc185481790aeaa1b", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a2cce54c1748216535dda02e185d07a084be837e", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c85efe6e13743cac6ba4ccf144cb91f44c86231a", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/de7b309139f862a44379ecd96e93c9133c69f813", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f14752d66056d0c7bffe5092130409417d3baa70", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "description": [{"lang": "en", "value": "CWE-416"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix use-after-free in print_graph_function_flags during tracer switching\n\nKairui reported a UAF issue in print_graph_function_flags() during\nftrace stress testing [1]. This issue can be reproduced if puting a\n'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),\nand executing the following script:\n\n $ echo function_graph > current_tracer\n $ cat trace > /dev/null &\n $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point\n $ echo timerlat > current_tracer\n\nThe root cause lies in the two calls to print_graph_function_flags\nwithin print_trace_line during each s_show():\n\n * One through 'iter->trace->print_line()';\n * Another through 'event->funcs->trace()', which is hidden in\n print_trace_fmt() before print_trace_line returns.\n\nTracer switching only updates the former, while the latter continues\nto use the print_line function of the old tracer, which in the script\nabove is print_graph_function_flags.\n\nMoreover, when switching from the 'function_graph' tracer to the\n'timerlat' tracer, s_start only calls graph_trace_close of the\n'function_graph' tracer to free 'iter->private', but does not set\nit to NULL. This provides an opportunity for 'event->funcs->trace()'\nto use an invalid 'iter->private'.\n\nTo fix this issue, set 'iter->private' to NULL immediately after\nfreeing it in graph_trace_close(), ensuring that an invalid pointer\nis not passed to other tracers. Additionally, clean up the unnecessary\n'iter->private = NULL' during each 'cat trace' when using wakeup and\nirqsoff tracers.\n\n [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Fix use-after-free en print_graph_function_flags durante el cambio de tracer Kairui inform\u00f3 de un problema de UAF en print_graph_function_flags() durante las pruebas de estr\u00e9s de ftrace [1]. Este problema se puede reproducir si se pone un 'mdelay(10)' despu\u00e9s de 'mutex_unlock(&trace_types_lock)' en s_start() y se ejecuta el siguiente script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Asegurarse de que 'cat' alcance el punto 'mdelay(10)' $ echo timerlat > current_tracer La causa ra\u00edz se encuentra en las dos llamadas a print_graph_function_flags dentro de print_trace_line durante cada s_show(): * Una a trav\u00e9s de 'iter->trace->print_line()'; * Otra funci\u00f3n mediante 'event->funcs->trace()', que est\u00e1 oculta en print_trace_fmt() antes del retorno de print_trace_line. Al cambiar de trazador, solo se actualiza el primero, mientras que el segundo contin\u00faa usando la funci\u00f3n print_line del trazador anterior, que en el script anterior es print_graph_function_flags. Adem\u00e1s, al cambiar del trazador 'function_graph' al trazador 'timerlat', s_start solo llama a graph_trace_close del trazador 'function_graph' para liberar 'iter->private', pero no lo establece en NULL. Esto permite que 'event->funcs->trace()' use un 'iter->private' no v\u00e1lido. Para solucionar este problema, establezca 'iter->private' en NULL inmediatamente despu\u00e9s de liberarlo en graph_trace_close(), lo que garantiza que no se pase un puntero no v\u00e1lido a otros trazadores. Adem\u00e1s, limpie el 'iter->private = NULL' innecesario durante cada 'cat trace' al usar los trazadores wakeup e irqsoff. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/"}], "lastModified": "2025-04-21T15:15:58.903", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}