{"id":"CVE-2024-26706","summary":"parisc: Fix random data corruption from exception handler","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix random data corruption from exception handler\n\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\n\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \"%r\" prefix), which the GNU assembler can not\nconvert to an integer.\n\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\"or %r0,%r0,%reg\", where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\n\nSince we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT\nconfig option any longer.","modified":"2026-04-02T10:05:37.133429Z","published":"2024-04-03T14:55:09.529Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26706.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592"},{"type":"WEB","url":"https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831"},{"type":"WEB","url":"https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003"},{"type":"WEB","url":"https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26706.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26706"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"d19f5e41b344a057bb2450024a807476f30978d2"},{"fixed":"23027309b099ffc4efca5477009a11dccbdae592"},{"fixed":"fa69a8063f8b27f3c7434a0d4f464a76a62f24d2"},{"fixed":"ce31d79aa1f13a2345791f84935281a2c194e003"},{"fixed":"8b1d72395635af45410b66cc4c4ab37a12c4a831"}]},{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"0"},{"last_affected":"09b931fcb87c8aad178475a7db1d4bfc939f7faa"},{"last_affected":"37e6234297379e0db25e39c2ca99776fea70026c"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26706.json"}}],"schema_version":"1.7.5"}