CVE-2026-98551 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fill branch entries with a single assignment
perf_clear_branch_entry_bitfields() clears the bitfields of struct perf_branch_entry one by one and leaves from/to alone, since callers overwrite those straight away. The list has to be kept in sync with the struct by hand and has already fallen behind: new_type and priv were added to perf_branch_entry and never added here.
Only BRBE writes those two, and neither for every record. brbe_set_perf_entry_type() leaves new_type alone for a branch type it does not recognise, and priv is not set for source-only records. arm_pmuv3.c allocates the per-CPU branch stack with kmalloc(), so such a record reaches userspace with whatever the slot held: uninitialised kmalloc() data on the first pass over the buffer, the previous record's values after that. Nothing under arch/x86/events/ writes either field, so only arm64 is affected.
Assign the whole entry at each site instead. Everything not named is then zero, and there is no list to keep in sync. The bitfields add up to exactly 64 bits, so the struct has no padding to leave undefined.
perf_clear_branch_entry_bitfields() has no callers left, so remove it. perf_entry_from_brbe_regset() assigns an empty literal instead, since it fills from/to conditionally. PERF_BR_SPEC_NA is 0, so dropping the explicit spec assignment changes nothing.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's performance monitoring subsystem stems from improper initialization of data structures within the perf branch entry handling logic. Specifically, the function perf_clear_branch_entry_bitfields was designed to clear specific bit fields of the struct perf_branch_entry structure one by one while intentionally leaving the from and to address fields untouched under the assumption that callers would overwrite them immediately. This approach relied on a manually maintained list of fields to be cleared, which had fallen out of synchronization with the actual definition of the struct. When new members such as new_type and priv were added to perf_branch_entry, they were not included in this clearing mechanism, creating a gap in data sanitization that allowed uninitialized memory contents to persist into user-facing records.
The operational impact is most severe on ARM64 architectures utilizing the Branch Record Buffer Extension BRBE features because other architecture implementations like x86 do write these specific fields before use. On affected systems, when arm_pmuv3.c allocates per-CPU branch stack buffers using kmalloc, it does not zero out the memory beforehand. Consequently, if a record is generated that does not explicitly set new_type or priv, those fields retain whatever values were previously stored in that memory slot. This results in information leakage where uninitialized kernel heap data from prior operations can be exposed to user-space applications through performance monitoring events. The risk includes potential exposure of sensitive internal state or previous process data depending on the allocation patterns and timing of buffer reuse.
From a technical remediation perspective, the issue was resolved by replacing the manual bit-field clearing logic with direct assignment of the entire structure entry at each relevant site within the kernel codebase. This ensures that all fields including new_type and priv are explicitly initialized to zero unless otherwise specified, eliminating reliance on external synchronization lists and preventing uninitialized memory exposure. The function perf_clear_branch_entry_bitfields was subsequently removed as it became redundant after these changes. Additionally, in cases where conditional filling occurs such as in perf_entry_from_brbe_regset an empty literal assignment is used instead of relying on implicit zeroing which maintains correctness while simplifying the code path and reducing maintenance overhead associated with keeping field lists synchronized.
This vulnerability aligns with CWE-20 Improper Input Validation regarding failure to properly sanitize data before exposure and more specifically CWE-913 Improvement of Centralized Control of Unmanaged Resources for Memory Management failures leading to information disclosure via uninitialized memory states. In terms of the MITRE ATT&CK framework this behavior relates to T1074 Data Staged where attackers might leverage such leaks to stage or exfiltrate data though in this context it primarily represents a passive information leakage vector rather than an active exploitation technique unless combined with other vulnerabilities. Mitigation strategies involve applying kernel updates that include the fix for perf branch entry initialization ensuring all architectures properly zero out unused fields before exposing them through performance counters and verifying that memory allocation routines used for critical buffers enforce strict zeroing policies to prevent residual data retention across buffer cycles.