CVE-2022-48762
published 2024-06-20CVE-2022-48762: In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In…
PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.19%
9.0th percentile
In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MTE-enabled QEMU image we are hitting the following crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0xf4 el1_abort+0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_sys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.7-1 (bookworm) | linux 5.16.7-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 753b32368705c396000f95f33c3b7018474e33ad < 47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb | 47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb |
| linux | linux | >= 753b32368705c396000f95f33c3b7018474e33ad < 3758a6c74e08bdc15ccccd6872a6ad37d165239a | 3758a6c74e08bdc15ccccd6872a6ad37d165239a |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.16.7-1 | 5.16.7-1 |
| linux | linux_kernel | >= 0 < 5.16.7-1 | 5.16.7-1 |
| linux | linux_kernel | >= 0 < 5.16.7-1 | 5.16.7-1 |
| linux | linux_kernel | >= 5.16 < 5.16.5 | 5.16.5 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv6.2MEDIUM
vendor_debian6.2MEDIUM
vendor_redhat6.2MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-vj7w-cq55-7h2m: In the Linux kernel, the following vulnerability has been resolved:
arm64: extable: fix load_unaligned_zeropad() reg indices
In ex_handler_load_unal
ghsa_unreviewed·2024-06-20
CVE-2022-48762 [MEDIUM] CWE-476 GHSA-vj7w-cq55-7h2m: In the Linux kernel, the following vulnerability has been resolved:
arm64: extable: fix load_unaligned_zeropad() reg indices
In ex_handler_load_unal
In the Linux kernel, the following vulnerability has been resolved:
arm64: extable: fix load_unaligned_zeropad() reg indices
In ex_handler_load_unaligned_zeropad() we erroneously extract the data and
addr register indices from ex->type rather than ex->data. As ex->type will
contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
* We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is
extracted from bits [9:5]. Thus, we may attempt to dereference an
arbitrary address as X0 may hold an arbitrary value.
* We'll always treat X4 as the data register, since EX_DATA_REG_DATA is
extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary
behaviour within load_unaligned_zeropad() and its caller.
Fix this by extracting both values from ex->data as originally intended.
On a
OSV
CVE-2022-48762: In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unalig
osv·2024-06-20·CVSS 6.2
CVE-2022-48762 [MEDIUM] CVE-2022-48762: In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unalig
In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MT
Red Hat
kernel: arm64: extable: fix load_unaligned_zeropad() reg indices
vendor_redhat·2024-06-20·CVSS 6.2
CVE-2022-48762 [MEDIUM] CWE-476 kernel: arm64: extable: fix load_unaligned_zeropad() reg indices
kernel: arm64: extable: fix load_unaligned_zeropad() reg indices
In the Linux kernel, the following vulnerability has been resolved:
arm64: extable: fix load_unaligned_zeropad() reg indices
In ex_handler_load_unaligned_zeropad() we erroneously extract the data and
addr register indices from ex->type rather than ex->data. As ex->type will
contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
* We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is
extracted from bits [9:5]. Thus, we may attempt to dereference an
arbitrary address as X0 may hold an arbitrary value.
* We'll always treat X4 as the data register, since EX_DATA_REG_DATA is
extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary
behaviour within load_unaligned_zeropad() and its caller.
Fix this by ext
Debian
CVE-2022-48762: linux - In the Linux kernel, the following vulnerability has been resolved: arm64: exta...
vendor_debian·2022·CVSS 6.2
CVE-2022-48762 [MEDIUM] CVE-2022-48762: linux - In the Linux kernel, the following vulnerability has been resolved: arm64: exta...
In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MT
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-06-20
Published