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.