Answer in brief
CVE-2024-26706 records a High severity (CVSS 7.8) vulnerability in parisc: Fix random data corruption from exception handler. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d19f5e41b344a057bb2450024a807476f30978d2 <23027309b099ffc4efca5477009a11dccbdae592 || >=d19f5e41b344a057bb2450024a807476f30978d2 <fa69a8063f8b27f3c7434a0d4f464a76a62f24d2 || >=d19f5e41b344a057bb2450024a807476f30978d2 <ce31d79aa1f13a2345791f84935281a2c194e003 || >=d19f5e41b344a057bb2450024a807476f30978d2 <8b1d72395635af45410b66cc4c4ab37a12c4a831 || 09b931fcb87c8aad178475a7db1d4bfc939f7faa || 37e6234297379e0db25e39c2ca99776fea70026c || >=4.9.21 <4.10 || >=4.10.9 <4.11 | 23027309b099ffc4efca5477009a11dccbdae592, fa69a8063f8b27f3c7434a0d4f464a76a62f24d2, ce31d79aa1f13a2345791f84935281a2c194e003, 8b1d72395635af45410b66cc4c4ab37a12c4a831, 4.10, 4.11 |
| Linux/Linuxgeneric | 4.11 | Not reported |
Published upstream
Apr 3, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.