CVE-2022-49520: arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall
In the Linux kernel, the following vulnerability has been resolved:
arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall
If a compat process tries to execute an unknown system call above the
__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the
offending process. Information about the error is printed to dmesg in
compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->
arm64_show_signal().
arm64_show_signal() interprets a non-zero value for
current->thread.fault_code as an exception syndrome and displays the
message associated with the ESR_ELx.EC field (bits 31:26).
current->thread.fault_code is set in compat_arm_syscall() ->
arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx
value. This means that the ESR_ELx.EC field has the value that the user set
for the syscall number and the kernel can end up printing bogus exception
messages*. For example, for the syscall number 0x68000000, which evaluates
to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:
[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000]
[ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79
[ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)
[..]
which is misleading, as the bad compat syscall has nothing to do with
pointer authentication.
Stop arm64_show_signal() from printing exception syndrome information by
having compat_arm_syscall() set the ESR_ELx value to 0, as it has no
meaning for an invalid system call number. The example above now becomes:
[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000]
[ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80
[ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)
[..]
which although shows less information because the syscall number,
wrongfully advertised as the ESR value, is missing, it is better than
showing plainly wrong information. The syscall number can be easily
obtained with strace.
*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative
integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END
evaluates to true; the syscall will exit to userspace in this case with the
ENOSYS error code instead of arm64_notify_die() being called.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects arm64 systems running 32-bit compatibility processes. A bad system call can make the kernel print misleading exception details in logs. The source describes incorrect diagnostics, not data theft, code execution, or privilege escalation.
Executive priority
Treat as routine kernel hygiene, not an emergency. Prioritize where arm64 Linux systems are operationally critical or heavily monitored, because misleading kernel errors can slow incident response and troubleshooting.
Technical view
In arm64 compat syscall handling, an invalid syscall number was passed as current->thread.fault_code and later interpreted as an ESR_ELx exception syndrome. This could produce bogus dmesg exception messages. The fix sets the ESR value to 0 for invalid compat syscalls.
Likely exposure
Exposure appears limited to Linux arm64 systems with compat support for 32-bit processes, in affected kernel ranges listed by the CVE record, including 3.7 through fixed stable releases around 5.4.198, 5.10.121, 5.15.46, 5.17.14, and 5.18.3.
Exploitation context
No KEV listing or cited source indicates active exploitation. Triggering requires a local compat process issuing an invalid syscall number. The documented outcome is misleading kernel log output and diagnostic confusion.
Researcher notes
The issue is primarily correctness in fault reporting. The CVE sources do not provide CVSS, CWE, or evidence of security boundary impact. Avoid assuming broader exploitability without additional vendor analysis.
Mitigation direction
Identify arm64 Linux systems with 32-bit compat process support enabled.
Check whether your kernel includes one of the referenced stable fixes.
Update to a vendor-supported kernel containing the upstream fix.
If unsure, follow your Linux distribution’s kernel advisory guidance.
Validation and detection
Inventory kernel versions on arm64 hosts and appliances.
Confirm whether affected kernel branches are present.
Review vendor kernel changelogs for the referenced arm64 compat fix.
Verify the fix commit is present in custom kernel trees.
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-49520 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
7Source 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.
Feb 26, 2025, 02:13 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.