CVE-2022-49001
published 2024-10-21CVE-2022-49001: In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow…
PriorityP433high7CVSS 3.1
AVLACHPRLUINSUCHIHAH
EPSS
0.19%
8.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack overflow, riscv firstly switches
to the so called shadow stack, then use this shadow stack to call the
get_overflow_stack() to get the overflow stack. However, there's
a race here if two or more harts use the same shadow stack at the same
time.
To solve this race, we introduce spin_shadow_stack atomic var, which
will be swap between its own address and 0 in atomic way, when the
var is set, it means the shadow_stack is being used; when the var
is cleared, it means the shadow_stack isn't being used.
[Palmer: Add AQ to the swap, and also some comments.]
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.12-1 (bookworm) | linux 6.0.12-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 31da94c25aea835ceac00575a9fd206c5a833fed < ac00301adb19df54f2eae1efc4bad7447c0156ce | ac00301adb19df54f2eae1efc4bad7447c0156ce |
| linux | linux | >= 31da94c25aea835ceac00575a9fd206c5a833fed < 879fabc5a95401d9bce357e4b1d24ae4a360a81f | 879fabc5a95401d9bce357e4b1d24ae4a360a81f |
| linux | linux | >= 31da94c25aea835ceac00575a9fd206c5a833fed < 7e1864332fbc1b993659eab7974da9fe8bf8c128 | 7e1864332fbc1b993659eab7974da9fe8bf8c128 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.12-1 | 6.0.12-1 |
| linux | linux_kernel | >= 0 < 6.0.12-1 | 6.0.12-1 |
| linux | linux_kernel | >= 0 < 6.0.12-1 | 6.0.12-1 |
| linux | linux_kernel | >= 5.14 < 5.15.82 | 5.15.82 |
| linux | linux_kernel | >= 5.16 < 6.0.12 | 6.0.12 |
CVSS provenance
nvdv3.17.0HIGHCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.0HIGH
vendor_debian7.0HIGH
vendor_redhat7.0HIGH
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-5gxq-g22h-vg26: In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack ov
ghsa_unreviewed·2024-10-21
CVE-2022-49001 [HIGH] CWE-362 GHSA-5gxq-g22h-vg26: In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack ov
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack overflow, riscv firstly switches
to the so called shadow stack, then use this shadow stack to call the
get_overflow_stack() to get the overflow stack. However, there's
a race here if two or more harts use the same shadow stack at the same
time.
To solve this race, we introduce spin_shadow_stack atomic var, which
will be swap between its own address and 0 in atomic way, when the
var is set, it means the shadow_stack is being used; when the var
is cleared, it means the shadow_stack isn't being used.
[Palmer: Add AQ to the swap, and also some comments.]
OSV
CVE-2022-49001: In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack over
osv·2024-10-21·CVSS 7.0
CVE-2022-49001 [HIGH] CVE-2022-49001: In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack over
In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.]
Red Hat
kernel: riscv: fix race when vmap stack overflow
vendor_redhat·2024-10-21·CVSS 7.0
CVE-2022-49001 [HIGH] CWE-362 kernel: riscv: fix race when vmap stack overflow
kernel: riscv: fix race when vmap stack overflow
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix race when vmap stack overflow
Currently, when detecting vmap stack overflow, riscv firstly switches
to the so called shadow stack, then use this shadow stack to call the
get_overflow_stack() to get the overflow stack. However, there's
a race here if two or more harts use the same shadow stack at the same
time.
To solve this race, we introduce spin_shadow_stack atomic var, which
will be swap between its own address and 0 in atomic way, when the
var is set, it means the shadow_stack is being used; when the var
is cleared, it means the shadow_stack isn't being used.
[Palmer: Add AQ to the swap, and also some comments.]
Package: kernel (Red Hat Enterprise Linux 6) -
Debian
CVE-2022-49001: linux - In the Linux kernel, the following vulnerability has been resolved: riscv: fix ...
vendor_debian·2022·CVSS 7.0
CVE-2022-49001 [HIGH] CVE-2022-49001: linux - In the Linux kernel, the following vulnerability has been resolved: riscv: fix ...
In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.]
Scope: local
bookworm: resolved (fixed in 6.0.12-1)
bullseye: resolved
forky: resolved (fixed in
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-10-21
Published