{"id":"CVE-2025-38434","state":"PUBLISHED","title":"Revert \"riscv: Define TASK_SIZE_MAX for __access_ok()\"","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"riscv: Define TASK_SIZE_MAX for __access_ok()\"\n\nThis reverts commit ad5643cf2f69 (\"riscv: Define TASK_SIZE_MAX for\n__access_ok()\").\n\nThis commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),\nbecause the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some\ncomputation.\n\nThe reasoning was that all user addresses are less than LONG_MAX, and all\nkernel addresses are greater than LONG_MAX. Therefore access_ok() can\nfilter kernel addresses.\n\nAddresses between TASK_SIZE and LONG_MAX are not valid user addresses, but\naccess_ok() let them pass. That was thought to be okay, because they are\nnot valid addresses at hardware level.\n\nUnfortunately, one case is missed: get_user_pages_fast() happily accepts\naddresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses\nget_user_pages_fast(). This causes the problem reported by Robert [1].\n\nTherefore, revert this commit. TASK_SIZE_MAX is changed to the default:\nTASK_SIZE.\n\nThis unfortunately reduces performance, because TASK_SIZE is more expensive\nto compute compared to LONG_MAX. But correctness first, we can think about\noptimization later, if required.","publishedAt":"2025-07-25T14:32:08.089Z","updatedAt":"2026-08-05T12:01:51.423Z","severity":{"score":7.8,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"fe30c30bf3bb68d4a4d8c7c814769857b5c973e6","versionType":"git"},{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"f8b1898748dfeb4f9b67b6a6d661f354b9de3523","versionType":"git"},{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"890ba5be6335dbbbc99af14ea007befb5f83f174","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/riscv/include/asm/pgtable.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.10","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.10","versionType":"semver"},{"version":"6.12.36","status":"unaffected","lessThanOrEqual":"6.12.*","versionType":"semver"},{"version":"6.15.5","status":"unaffected","lessThanOrEqual":"6.15.*","versionType":"semver"},{"version":"6.16","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/riscv/include/asm/pgtable.h"]}],"references":["https://git.kernel.org/stable/c/fe30c30bf3bb68d4a4d8c7c814769857b5c973e6","https://git.kernel.org/stable/c/f8b1898748dfeb4f9b67b6a6d661f354b9de3523","https://git.kernel.org/stable/c/890ba5be6335dbbbc99af14ea007befb5f83f174"],"weaknesses":[],"ingestedAt":"2026-10-29T20:09:09.358Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2025/38xxx/CVE-2025-38434.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-38434","state":"PUBLISHED","datePublished":"2025-07-25T14:32:08.089Z","dateUpdated":"2026-08-05T12:01:51.423Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2025-04-16T04:51:24.015Z"},"containers":{"cna":{"title":"Revert \"riscv: Define TASK_SIZE_MAX for __access_ok()\"","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"riscv: Define TASK_SIZE_MAX for __access_ok()\"\n\nThis reverts commit ad5643cf2f69 (\"riscv: Define TASK_SIZE_MAX for\n__access_ok()\").\n\nThis commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),\nbecause the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some\ncomputation.\n\nThe reasoning was that all user addresses are less than LONG_MAX, and all\nkernel addresses are greater than LONG_MAX. Therefore access_ok() can\nfilter kernel addresses.\n\nAddresses between TASK_SIZE and LONG_MAX are not valid user addresses, but\naccess_ok() let them pass. That was thought to be okay, because they are\nnot valid addresses at hardware level.\n\nUnfortunately, one case is missed: get_user_pages_fast() happily accepts\naddresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses\nget_user_pages_fast(). This causes the problem reported by Robert [1].\n\nTherefore, revert this commit. TASK_SIZE_MAX is changed to the default:\nTASK_SIZE.\n\nThis unfortunately reduces performance, because TASK_SIZE is more expensive\nto compute compared to LONG_MAX. But correctness first, we can think about\noptimization later, if required."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"fe30c30bf3bb68d4a4d8c7c814769857b5c973e6","versionType":"git"},{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"f8b1898748dfeb4f9b67b6a6d661f354b9de3523","versionType":"git"},{"version":"ad5643cf2f699989daa85d909403febd6712fccb","status":"affected","lessThan":"890ba5be6335dbbbc99af14ea007befb5f83f174","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/riscv/include/asm/pgtable.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.10","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.10","versionType":"semver"},{"version":"6.12.36","status":"unaffected","lessThanOrEqual":"6.12.*","versionType":"semver"},{"version":"6.15.5","status":"unaffected","lessThanOrEqual":"6.15.*","versionType":"semver"},{"version":"6.16","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/riscv/include/asm/pgtable.h"]}],"references":[{"url":"https://git.kernel.org/stable/c/fe30c30bf3bb68d4a4d8c7c814769857b5c973e6"},{"url":"https://git.kernel.org/stable/c/f8b1898748dfeb4f9b67b6a6d661f354b9de3523"},{"url":"https://git.kernel.org/stable/c/890ba5be6335dbbbc99af14ea007befb5f83f174"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The bug is reached only through local syscalls (futex(), read()/write() with user iovecs, io_uring fixed-buffer registration) in which the attacker supplies a crafted userspace virtual address; there is no network path to the vulnerable get_user_pages_fast() check.\nAC:L - Exploitation is fully deterministic — the attacker simply passes an address in [TASK_SIZE, LONG_MAX] to a gup_fast user; there is no race and no attacker-uncontrolled condition on an affected RISC-V 64-bit kernel.\nPR:L - Any unprivileged local user can invoke the affected syscalls (futex, read/write, io_uring); no capabilities or elevated privileges are required.\nUI:N - The attacker triggers the flaw entirely through their own syscalls with no action required from any other user.\nS:U - The vulnerability and its impact are both contained within the OS kernel's security authority; this is a standard in-kernel memory-safety boundary bug, not a VM/sandbox escape.\nC:H - The flaw lets an unprivileged user pin present kernel PTEs (the generic pte_access_permitted() does not check _PAGE_USER) and read arbitrary kernel memory out via write()-style transfers, a full kernel-memory disclosure primitive.\nI:H - Using FOLL_WRITE paths (e.g. read() into the crafted buffer) the same walk pins writable kernel pages, allowing attacker-controlled data to be written into kernel memory — an arbitrary kernel write enabling privilege escalation.\nA:H - Walking into the kernel half of the page tables and corrupting or dereferencing kernel structures can trivially oops/panic the kernel."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-08-05T12:01:51.423Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.10","versionEndExcluding":"6.12.36"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.10","versionEndExcluding":"6.15.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.10","versionEndExcluding":"6.16"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}}}}}