CVE-2025-38067: rseq: Fix segfault on registration when rseq_cs is non-zero
In the Linux kernel, the following vulnerability has been resolved:
rseq: Fix segfault on registration when rseqcs is non-zero
The rseqcs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseqcs field doesn't point to a valid struct rseqcs.
The correct solution to this would be to fail the rseq registration when the rseqcs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseqcs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseqcs does point to a valid struct rseqcs.
What we can do is clear the rseqcs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2025-38067?
CVE-2025-38067 is classified as a moderate severity vulnerability in the Linux kernel due to its impact on system stability.
How do I fix CVE-2025-38067?
To fix CVE-2025-38067, update to the latest version of the Linux kernel where the vulnerability has been patched.
What systems are affected by CVE-2025-38067?
CVE-2025-38067 affects various versions of the Linux kernel that utilize the rseq feature.
Can CVE-2025-38067 cause system crashes?
Yes, CVE-2025-38067 can potentially cause segmentation faults leading to system crashes during the registration process.
Is user action required to trigger CVE-2025-38067?
User-space applications that improperly set the rseq_cs field prior to registration can trigger CVE-2025-38067.