Back

MEDIUM

tracing: Have process_string() also allow arrays

Published Jan 21, 2025

Description

In order to catch a common bug where a TRACE_EVENT() TP_fast_assign() assigns an address of an allocated string to the ring buffer and then references it in TP_printk(), which can be executed hours later when the string is free, the function test_event_printk() runs on all events as they are registered to make sure there's no unwanted dereferencing.

It calls process_string() to handle cases in TP_printk() format that has "%s". It returns whether or not the string is safe. But it can have some false positives.

For instance, xe_bo_move() has:

TP_printk("move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s", __entry->move_lacks_source ? "yes" : "no", __entry->bo, __entry->size, xe_mem_type_to_name[__entry->old_placement], xe_mem_type_to_name[__entry->new_placement], __get_str(device_id))

Where the "%s" references into xe_mem_type_to_name[]. This is an array of pointers that should be safe for the event to access. Instead of flagging this as a bad reference, if a reference points to an array, where the record field is the index, consider it safe.

Affected products

Remediation

No remediation recorded yet.

Weaknesses (1)

References (12)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Jan 21, 2025
Updated May 11, 2026
Reserved Jan 19, 2025
NVD
Status Modified
Modified Jun 17, 2026
Red Hat
Severity Moderate
Public date Jan 21, 2025
ENISA EUVD
Assigner Linux
Published Jan 21, 2025
Updated May 11, 2026
Exploited since n/a
EUVD-2024-53833