CVE-2026-64082: riscv: Fix register corruption from uninitialized cregs on error

Published Jul 19, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix register corruption from uninitialized cregs on error

compatriscvgprset() calls cregstoregs() unconditionally, even when userregsetcopyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's ptregs, corrupting its register state and potentially leaking kernel stack contents.

compatrestoresigcontext() has the same issue: it calls cregstoregs() even when copyfromuser() fails, leading to the same corruption of the signal-returning task's register state on error.

Only call cregstoregs() when the user copy succeeds.

Affected Software

5 affected components
Linux Linux kernel
Linux Linux kernel>=5.19<7.0.11
Linux Linux kernel=7.1-rc1
Linux Linux kernel=7.1-rc2
Linux Linux kernel=7.1-rc3

Event History

Jul 19, 2026
CVE Published
via MITRE·03:39 PM
Data Sourced
via MITRE·03:39 PM
DescriptionSeverity
Data Sourced
via NVD·04:17 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What access does an attacker need to trigger this issue?

The CVSS vector indicates local access with low privileges and no user interaction required. Exploitation involves causing a user-space copy operation to fail in affected RISC-V compatibility register-setting or signal-return paths.

2

What is the impact if the issue is triggered?

A failed copy can cause uninitialized kernel stack data to be written into a task's register state. This can corrupt registers and may leak kernel stack contents, with potential effects on confidentiality, integrity, and availability.

3

Which systems should be prioritized for remediation?

Prioritize Linux kernel systems running on RISC-V that use the affected compatibility register-setting or signal-return code paths, particularly where unprivileged local users can execute code. The provided data does not identify affected kernel version ranges.

4

What should be done if patching cannot happen immediately?

Restrict untrusted local access where feasible, since exploitation requires local low-privileged access. Apply the available kernel patch as soon as operationally possible.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203