CVE-2026-97923

tracing: Free histogram the var ref when its initialization fails

N/A
Published: September 25, 2026 at 10:22 AM UTC
Updated: October 19, 2026 at 10:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.19.1005.0656fe2ba85e81d00e4447bf77b8da2be3c47acb2836717841a30d7845cdf9cb806ee0ff3bfa7135a
Vendor states this is fixed in 222abcbe7866fef04563b6eb89fb21f627dcbc77 (fixed)
Vendor states this is fixed in 352f84a381e7b4651b30366e93cb858f3fa9c91a (fixed)
Vendor states this is fixed in 4870f9071c9ea3c1423a07741b85a794db30d672 (fixed)
Vendor states this is fixed in 4924328d6991f25b65bb7c8ff5d56c2a9b254851 (fixed)
Vendor states this is fixed in 516001d53e6b2ea95a251ee2ef54a1a689a3fd58 (fixed)
Vendor states this is fixed in 608b7751926ec08fae6a1ac4e7308195da68c362 (fixed)
Vendor states this is fixed in 74375caa20fe5165807b4334c783d1790b01f02a (fixed)
Vendor states this is fixed in a69baeac38677270656e85753d93856a076dee57 (fixed)
Affected range stops below 4.20, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.0 (unaffected)
Vendor states this is fixed in 5.10.271 (unaffected)
Vendor states this is fixed in 5.15.222 (unaffected)
Vendor states this is fixed in 6.1.189 (unaffected)
Vendor states this is fixed in 6.12.111 (unaffected)
Vendor states this is fixed in 6.18.53 (unaffected)
Vendor states this is fixed in 6.6.158 (unaffected)
Vendor states this is fixed in 7.2.7 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc3 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card