CVE-2022-49520

Source
https://nvd.nist.gov/vuln/detail/CVE-2022-49520
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49520.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-49520
Related
Published
2025-02-26T07:01:28Z
Modified
2025-02-26T19:03:23.514073Z
Summary
[none]
Details

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 _ARMNRCOMPATEND number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() -> arm64show_signal().

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 (ESRELxEC_FPAC) the kernel prints this error:

[ 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 ESR_ELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes:

[ 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 arm64notify_die() being called.

References

Affected packages

Debian:11 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.127-1

Affected versions

5.*

5.10.46-4
5.10.46-5
5.10.70-1~bpo10+1
5.10.70-1
5.10.84-1
5.10.92-1~bpo10+1
5.10.92-1
5.10.92-2
5.10.103-1~bpo10+1
5.10.103-1
5.10.106-1
5.10.113-1
5.10.120-1~bpo10+1
5.10.120-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.18.5-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.18.5-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}