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 ESRELx for a bad syscall
If a compat process tries to execute an unknown system call above the ARMNRCOMPATEND number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() -> arm64showsignal().
arm64showsignal() interprets a non-zero value for current->thread.faultcode as an exception syndrome and displays the message associated with the ESRELx.EC field (bits 31:26). current->thread.faultcode is set in compatarmsyscall() -> arm64notifydie() with the bad syscall number instead of a valid ESRELx value. This means that the ESRELx.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 ESRELx.EC value of 0x1A (ESRELxECFPAC) 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 arm64showsignal() from printing exception syndrome information by having compatarmsyscall() set the ESRELx 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 0x80000000 is interpreted as a negative integer in compatarmsyscal() and the condition scno < ARMNRCOMPATEND evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64notifydie() being called.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in 5.18.0-rc1 #79 - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in 5.18.0-rc1-00005-g7e08006d4102 #80 - Configuration
Apply the fix so arm64_show_signal() stops printing exception syndrome information when handling a bad compat syscall number (do not treat the syscall number as ESR_ELx for a bad syscall).
arm64_show_signal() Stop printing exception syndrome information for bad compat syscalls = disabled - Configuration
Apply the change so arm64_notify_die() handles the bad syscall number without passing it as ESR_ELx; arm64_show_signal() must not interpret the syscall number as ESR_ELx fields (including ESR_ELx.EC).
arm64_notify_die() arm64_notify_die() used for bad compat syscalls = correct_behavior - Compensating control
If affected systems are running and producing misleading dmesg output, use dmesg log review to identify and isolate offending compat processes generating unhandled exceptions for bad compat syscalls (e.g., the 'bad compat syscall(2)' lines) until the kernel fix is applied.
Event History
Frequently Asked Questions
Which systems and users are exposed?
The issue affects the Linux kernel on arm64 when a compat process is involved. The CVSS vector indicates local access and low privileges are required; no user interaction is required.
What action is required to trigger the issue?
A compat process must attempt an unknown system call with a number above __ARM_NR_COMPAT_END. The supplied syscall number is then incorrectly treated as an exception-syndrome value when the kernel reports the failure.
How can I identify evidence of the issue?
Check dmesg for a bad compat syscall report accompanied by an implausible or bogus unhandled-exception message. The example shows an ESR value of 0x68000000 and an exception label of ERET/ERETAA/ERETAB followed by an “Oops - bad compat syscall” message.
Are fixes available?
The vulnerability is described as resolved, and three stable Linux kernel commit references are provided: efd183d988b416fcdf6f7c298a17ced4859ca77d, ad97425d23af3c3b8d4f6a2bb666cb485087c007, and 621916afe8cd4f322eb12759b64a2f938d4e551d.