Answer in brief
CVE-2022-49990 records a High severity (CVSS 7.8) vulnerability in s390: fix double free of GS and RI CBs on fork() failure. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.0:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.0:rc2:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <25a95303b9e513cd2978aacc385d06e6fec23d07 || >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <cacd522e6652fbc2dc0cc6ae11c4e30782fef14b || >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <297ae7e87a87a001dd3dfeac1cb26a42fd929708 || >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <8195e065abf3df84eb0ad2987e76a40f21d1791c || >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <fbdc482d43eda40a70de4b0155843d5472f6de62 || >=8d9047f8b967ce6181fd824ae922978e1b055cc0 <13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9 || 9e51ee1b76efc7b5e9404010793a39fde0e03cb7 || 232b47b3c88af1da737cd7760f247c4ed58168cf || b8e212c599082896a180a18a0c9bd529526590be || >=4.4.105 <4.5 || >=4.9.68 <4.10 || >=4.14.5 <4.15 | 25a95303b9e513cd2978aacc385d06e6fec23d07, cacd522e6652fbc2dc0cc6ae11c4e30782fef14b, 297ae7e87a87a001dd3dfeac1cb26a42fd929708, 8195e065abf3df84eb0ad2987e76a40f21d1791c, fbdc482d43eda40a70de4b0155843d5472f6de62, 13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9, 4.5, 4.10, 4.15 |
| Linux/Linuxgeneric | 4.15 | Not reported |
Published upstream
Jun 18, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: s390: fix double free of GS and RI CBs on fork() failure The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task. This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied.
Quoted source text, attributed separately from HOL analysis.