parisc: Revise __get_user() to probe user read access
Because of the way read access support is implemented, read access
interruptions are only triggered at privilege levels 2 and 3. The
kernel executes at privilege level 0, so __get_user() never triggers
a read access interruption (code 26). Thus, it is currently possible
for user code to access a read protected address via a system call.
Fix this by probing read access rights at privilege level 3 (PRIV_USER)
and setting __gu_err to -EFAULT (-14) if access isn't allowed.
Note the cmpiclr instruction does a 32-bit compare because COND macro
doesn't work inside asm.
Metrics
Affected Vendors & Products
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|---|
|
Linux
Subscribe
|
Linux Kernel
Subscribe
|
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4328-1 | linux-6.1 security update |
 Debian DSA |
DSA-6008-1 | linux security update |
| Debian DSA |
DSA-6009-1 | linux security update |
 EUVD |
EUVD-2025-31511 | In the Linux kernel, the following vulnerability has been resolved: parisc: Revise __get_user() to probe user read access Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm. |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sat, 06 Sep 2025 09:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| Vendors & Products |
Linux
Linux linux Kernel |
Sat, 06 Sep 2025 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Fri, 05 Sep 2025 17:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: parisc: Revise __get_user() to probe user read access Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm. | |
| Title | parisc: Revise __get_user() to probe user read access | |
| References |
|
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T17:42:43.013Z
Reserved: 2025-04-16T07:20:57.117Z
Link: CVE-2025-39716
Vulnrichment
No data.
NVD
Status : Awaiting Analysis
Published: 2025-09-05T18:15:49.123
Modified: 2025-11-03T18:16:44.140
Link: CVE-2025-39716
Redhat
OpenCVE Enrichment
Updated: 2025-09-06T09:01:35Z
No weakness.