CVE-2024-26706
published 2024-04-03CVE-2024-26706: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.26%
17.0th percentile
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which register is used to hold the error
code. Using %0 or %1 in the inline assembly is not posssible as it will show
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
convert to an integer.
This patch takes another, better and more flexible approach:
We extend the __ex_table (which is out of the execution path) by one 32-word.
In this word we tell the compiler to insert the assembler instruction
"or %r0,%r0,%reg", where %reg references the register which the compiler
choosed for the error return code.
In case of an access failure, the fault handler finds the __ex_table entry and
can examine the opcode. The used register is encoded in the lowest 5 bits, and
the fault handler can then store -EFAULT into this register.
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
config option any longer.
Affected
21 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.82-1 (bookworm) | linux 6.1.82-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 4.10.9 < 4.11 | 4.11 |
| linux | linux | >= 4.9.21 < 4.10 | 4.10 |
| linux | linux | >= d19f5e41b344a057bb2450024a807476f30978d2 < 23027309b099ffc4efca5477009a11dccbdae592 | 23027309b099ffc4efca5477009a11dccbdae592 |
| linux | linux | >= d19f5e41b344a057bb2450024a807476f30978d2 < fa69a8063f8b27f3c7434a0d4f464a76a62f24d2 | fa69a8063f8b27f3c7434a0d4f464a76a62f24d2 |
| linux | linux | >= d19f5e41b344a057bb2450024a807476f30978d2 < ce31d79aa1f13a2345791f84935281a2c194e003 | ce31d79aa1f13a2345791f84935281a2c194e003 |
| linux | linux | >= d19f5e41b344a057bb2450024a807476f30978d2 < 8b1d72395635af45410b66cc4c4ab37a12c4a831 | 8b1d72395635af45410b66cc4c4ab37a12c4a831 |
| linux | linux_kernel | < 6.1.79 | 6.1.79 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.82-1 | 6.1.82-1 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 6.2 < 6.6.18 | 6.6.18 |
| linux | linux_kernel | >= 6.7 < 6.7.6 | 6.7.6 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 6.1.78/6.6.17/6.7.5 parisc emulate_ldd memory corruption (WID-SEC-2024-0773)
vuldb·2026-08-05·CVSS 5.5
CVE-2024-26706 [MEDIUM] Linux Kernel up to 6.1.78/6.6.17/6.7.5 parisc emulate_ldd memory corruption (WID-SEC-2024-0773)
A vulnerability was found in Linux Kernel up to 6.1.78/6.6.17/6.7.5 and classified as critical. Affected by this issue is the function emulate_ldd of the component parisc. Such manipulation leads to memory corruption.
This vulnerability is uniquely identified as CVE-2024-26706. The attack can only be initiated within the local network. No exploit exists.
It is suggested to upgrade the affected component.
OSV
CVE-2024-26706: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception ha
osv·2024-04-03·CVSS 5.5
CVE-2024-26706 [MEDIUM] CVE-2024-26706: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception ha
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inl
GHSA
GHSA-4fj7-85cf-9m8p: In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception
ghsa_unreviewed·2024-04-03
CVE-2024-26706 [MEDIUM] CWE-787 GHSA-4fj7-85cf-9m8p: In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which register is used to hold the error
code. Using %0 or %1 in the
Microsoft
parisc: Fix random data corruption from exception handler
vendor_msrc·2024-04-09·CVSS 5.5
CVE-2024-26706 [MEDIUM] CWE-787 parisc: Fix random data corruption from exception handler
parisc: Fix random data corruption from exception handler
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Red Hat
kernel: parisc: Fix random data corruption from exception handler
vendor_redhat·2024-04-03·CVSS 5.5
CVE-2024-26706 [MEDIUM] CWE-99 kernel: parisc: Fix random data corruption from exception handler
kernel: parisc: Fix random data corruption from exception handler
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which
Debian
CVE-2024-26706: linux - In the Linux kernel, the following vulnerability has been resolved: parisc: Fix...
vendor_debian·2024·CVSS 5.5
CVE-2024-26706 [MEDIUM] CVE-2024-26706: linux - In the Linux kernel, the following vulnerability has been resolved: parisc: Fix...
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inl
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2024-26706 kernel: parisc: Fix random data corruption from exception handler
bugzilla·2024-04-03·CVSS 5.5
CVE-2024-26706 [MEDIUM] CVE-2024-26706 kernel: parisc: Fix random data corruption from exception handler
CVE-2024-26706 kernel: parisc: Fix random data corruption from exception handler
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The Linux kernel CVE team has assigned CVE-2024-26706 to this issue.
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2024040341-CVE-2024-26706-844b@gregkh/T
Discussion:
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 2273171]
Microsoft
Uncovering a macOS App Sandbox escape vulnerability: A deep dive into CVE-2022-26706
blogs_microsoft·2022-07-13·CVSS 5.5
[MEDIUM] Uncovering a macOS App Sandbox escape vulnerability: A deep dive into CVE-2022-26706
Research
July 13, 2022
## Related posts
April 22, 2024
October 25, 2023
September 14, 2023
## Get started with Microsoft Security
Protect your people, data, and infrastructure with AI-powered, end-to-end security from Microsoft.
Connect with us on social
Careers
About Microsoft
Company news
Privacy at Microsoft
Investors
Diversity and inclusion
Accessibility
Sustainability
https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2
2024-04-03
Published