Answer in brief
CVE-2025-38434 records a High severity (CVSS 7.8) vulnerability in Revert "riscv: Define TASK_SIZE_MAX for __access_ok()". 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.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ad5643cf2f699989daa85d909403febd6712fccb <fe30c30bf3bb68d4a4d8c7c814769857b5c973e6 || >=ad5643cf2f699989daa85d909403febd6712fccb <f8b1898748dfeb4f9b67b6a6d661f354b9de3523 || >=ad5643cf2f699989daa85d909403febd6712fccb <890ba5be6335dbbbc99af14ea007befb5f83f174 | fe30c30bf3bb68d4a4d8c7c814769857b5c973e6, f8b1898748dfeb4f9b67b6a6d661f354b9de3523, 890ba5be6335dbbbc99af14ea007befb5f83f174 |
| Linux/Linuxgeneric | 6.10 | Not reported |
Published upstream
Jul 25, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()"). This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(), because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some computation. The reasoning was that all user addresses are less than LONG_MAX, and all kernel addresses are greater than LONG_MAX. Therefore access_ok() can filter kernel addresses. Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but access_ok() let them pass. That was thought to be okay, because they are not valid addresses at hardware level. Unfortunately, one case is missed: get_user_pages_fast() happily accepts addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses get_user_pages_fast(). This causes the problem reported by Robert [1]. Therefore, revert this commit. TASK_SIZE_MAX is changed to the default: TASK_SIZE. This unfortunately reduces performance, because TASK_SIZE is more expensive to compute compared to LONG_MAX. But correctness first, we can think about optimization later, if required.
Quoted source text, attributed separately from HOL analysis.