CVE-2026-74636 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix race between update_event_fields and, event_define_fields
The following sequence may leads race between event_define_fields() and update_event_fields():
CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next;
Where access to the class->fields is not protected by the event_mutex in trace_event_update_all().
This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c
Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel tracing subsystem contains a concurrency vulnerability arising from an improper locking hierarchy during the dynamic registration of trace events when loading kernel modules. This race condition occurs specifically between the update_event_fields function and the event_define_fields function, triggered by concurrent module load operations on different CPU cores. The root cause lies in the inconsistent application of synchronization primitives across two critical code paths: one initiated through the standard module loading notifier chain which acquires the event_mutex before registering events, and another path within trace_event_update_all that attempts to update existing fields but fails to acquire this same mutex while holding a write lock on the trace_event_sem.
When CPU0 loads module A, it enters the trace_module_notify handler where it correctly locks the event_mutex prior calling __register_event and subsequently event_define_fields to populate field definitions for new trace points. Simultaneously, if CPU1 is loading module B, its notifier call chain triggers trace_event_update_all which acquires a write lock on trace_event_sem but neglects to acquire the event_mutex before iterating over existing class fields via list_for_each_entry. This creates a window where one thread modifies or reads field structures while another thread concurrently accesses those same data structures without mutual exclusion protection, leading to undefined behavior and potential memory corruption.
The operational impact of this vulnerability is severe, manifesting as an immediate kernel panic due to an invalid memory access at virtual address zero plus offset sixteen bytes within the update_event_fields function. The call trace confirms that the crash originates from accessing a null or corrupted pointer while iterating through class fields during the update process. This denial of service condition effectively crashes the entire system whenever two modules are loaded concurrently in quick succession, disrupting all tracing activities and potentially causing data loss for any active monitoring systems relying on kernel trace buffers.
From a classification perspective, this vulnerability aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically highlighting a race condition due to missing locks or incorrect lock ordering. In the context of the MITRE ATT&CK framework, this represents an exploitation vector that could potentially be leveraged for privilege escalation if an attacker can trigger concurrent module loads in a controlled manner, although the immediate effect is system instability rather than direct code execution. The vulnerability underscores the importance of maintaining strict locking hierarchies within kernel subsystems to prevent data structure corruption during high-concurrency operations.
The resolution involves modifying trace_event_update_all to acquire the event_mutex before acquiring or while holding the write lock on trace_event_sem, thereby ensuring that all accesses to class fields are properly serialized regardless of which code path initiates them. This fix restores consistency in synchronization primitives across both module registration and field update workflows. System administrators should apply kernel updates containing this patch immediately to prevent potential system crashes during routine maintenance involving multiple module loads. Additionally, developers working on tracing infrastructure must ensure that all shared data structures are protected by appropriate mutexes regardless of the entry point used for modification or inspection.