---
id: "CVE-2026-99238"
kind: "vulnerability"
aliases: ["CVE-2026-99238"]
title: "Linux kernel: tracing instance removal can race module loads, freeing memory"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: [{"name": "linux-kernel", "fixed": [], "affected": "kernels containing commit 5f3719f697c3 and not the fix; exact version range unknown", "ecosystem": "linux"}]
ecosystems: []
tags: ["ftrace", "infrastructure", "linux-kernel", "servers", "tracing"]
not_affected_if: ["unknown"]
published_at: "2026-11-02T16:17:49+00:00"
first_seen_at: "2026-11-02T16:24:06+00:00"
updated_at: "2026-11-02T16:27:33+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99238", "first_seen_at": "2026-11-02T16:24:06+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-02T16:27:33+00:00"}]
---

# Linux kernel: tracing instance removal can race module loads, freeing memory

Linux kernel trace_module_record() walks the list of trace instances from the module notifier without holding trace_types_lock. A concurrent rmdir of an instance can free it, so a module load or unload can use freed memory. The upstream fix adds the missing lock. It is queued in the tracing tree and has no confirmed release version yet. NVD scores it 7.8 with a local, low-privilege vector.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- linux:linux-kernel affected kernels containing commit 5f3719f697c3 and not the fix; exact version range unknown fixed ?

## How to check

- Run `uname -r` and compare against your distribution's advisory for CVE-2026-99238; no fixed version is published upstream yet.
- Only kernels containing commit 5f3719f697c3 ('tracing: Update modules to persistent instances when loaded') have the bug. Check whether your kernel source or changelog has it, and whether kernel/trace/trace.c trace_module_record() takes trace_types_lock.
- Also check whether tracefs instances are used: `ls /sys/kernel/tracing/instances` (the race needs an instance being removed with rmdir while a module loads or unloads).

## Fix

Upstream patch 'tracing: Hold trace_types_lock when updating modules in persistent instances' is queued in the tracing for-next tree (Cc stable). No released kernel version is confirmed yet; install your distribution's kernel update once it lists CVE-2026-99238.

## Timeline

- 2026-11-02T16:24:06+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99238
- 2026-11-02T16:27:33+00:00 analyst — Read the maintainer patch (Carlier 2026-10-16; Rostedt queued it in tracing for-next 'Updates for 7.4' on 2026-10-20, Cc stable). Bug introduced by 5f3719f697c3; the fix is a 2-line guard(mutex)(&trace_types_lock) in trace_module_record(). No released kernel version or stable backport range found, so fixed versions stay unknown. Unprivileged trigger is not stated by the sources; the CVSS vector is local, low privileges.

## Documents

- [describes] [PATCH] tracing: Hold trace_types_lock when updating modules in persistent instances (original report) https://lkml.iu.edu/2610.2/00137.html
- [fix] [for-next][PATCH 2/6] tracing: Hold trace_types_lock when updating modules in persistent instances (Rostedt) https://lkml.iu.edu/2610.2/10517.html

## From the sources

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

tracing: Hold trace_types_lock when updating modules in persistent instances

trace_module_record() walks ftrace_trace_arrays from the module notifier
without trace_types_lock. A concurrent rmdir of an instance removes it
from the list and frees it under that lock, so a module load or unload
can walk into a freed trace_array.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_