CVE-2022-50094: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions
In the Linux kernel, the following vulnerability has been resolved:
spmi: trace: fix stack-out-of-bound access in SPMI tracing functions
trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of "len + 1". This leads to one extra
byte being read beyond the end of the specified buffer. Fix
this out-of-bound memory access by using a length of "len"
instead.
Here is a KASAN log showing the issue:
BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
dump_backtrace+0x0/0x3e8
show_stack+0x2c/0x3c
dump_stack_lvl+0xdc/0x11c
print_address_description+0x74/0x384
kasan_report+0x188/0x268
kasan_check_range+0x270/0x2b0
memcpy+0x90/0xe8
trace_event_raw_event_spmi_read_end+0x1d0/0x234
spmi_read_cmd+0x294/0x3ac
spmi_ext_register_readl+0x84/0x9c
regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
_regmap_raw_read+0x40c/0x754
regmap_raw_read+0x3a0/0x514
regmap_bulk_read+0x418/0x494
adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
...
__arm64_sys_read+0x4c/0x60
invoke_syscall+0x80/0x218
el0_svc_common+0xec/0x1c8
...
addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]
this frame has 1 object:
[32, 33) 'status'
Memory state around the buggy address:
ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00
^
ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00
==================================================================
Security readout for executives and security teams
Plain-English summary
CVE-2022-50094 is a Linux kernel bug in SPMI tracing. When affected tracing paths handle certain SPMI read or write buffers, the kernel copies one byte past the supplied buffer. The public record shows a KASAN-detected out-of-bounds read, but no CVSS score or active exploitation evidence.
Executive priority
Treat as a routine kernel update unless you operate affected embedded, mobile, or hardware-control Linux systems using SPMI. There is no provided evidence of active exploitation, but kernel memory safety defects should not remain untracked.
Technical view
The bug is in trace_spmi_write_begin() and trace_spmi_read_end(), which used memcpy() with len + 1 instead of len. This causes a one-byte stack out-of-bounds read in SPMI trace event handling. Kernel stable commits correct the copy length.
Likely exposure
Exposure is limited to Linux kernels containing the vulnerable SPMI trace code and deployed on systems where SPMI paths are present. The bundle lists Linux kernel versions and multiple stable fixes, but does not provide distribution package mappings.
Exploitation context
The source bundle marks KEV as false and provides no cited evidence of exploitation in the wild. The available evidence is a KASAN crash report showing a local kernel out-of-bounds read during SPMI-related thermal or ADC activity.
Researcher notes
The public evidence supports a one-byte out-of-bounds read, not a write. The record does not establish privilege escalation, remote reachability, or practical exploitability. Validate exposure by source commit presence and downstream backports rather than version strings alone.
Mitigation direction
Update to a kernel containing the referenced stable fix for your maintained branch.
Check your Linux distribution or device vendor advisory for the corrected package version.
Prioritize systems using SPMI-capable hardware or Qualcomm SPMI-related kernel drivers.
Track this as kernel maintenance if no exposed SPMI path exists.
Validation and detection
Inventory deployed kernel versions and compare against vendor-fixed releases.
Confirm whether SPMI, regmap_spmi, or Qualcomm SPMI ADC drivers are present.
Review kernel changelogs for the referenced SPMI tracing memcpy length fix.
Use vendor security scanners where distribution backport versions differ from upstream tags.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50094 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
10Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jun 18, 2025, 11:02 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.