In the Linux kernel, the following vulnerability has been resolved: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups During memory error injection test on kernels >= v6.4, the kernel panics like below. However, this issue couldn\'t be reproduced on kernels <= v6.3. mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10: {__get_user_nocheck_4+0x6/0x20} mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86 mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490 mce: [Hardware Error]: Run the above through \'mcelog --ascii\' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The MCA code can recover from an in-kernel #MC if the fixup type is EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT the only thing that is raised for an in-kernel #MC is a panic. ex_handler_uaccess() would warn if users gave a non-canonical addresses (with bit 63 clear) to {get, put}_user(), which was unexpected. Therefore, commit b19b74bc99b1 (x86/mm: Rework address range check in get_user() and put_user()) replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user() fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic. Commit 6014bc27561f (x86-64: make access_ok() independent of LAM) added the check gp_fault_address_ok() right before the WARN_ONCE() in ex_handler_uaccess() to not warn about non-canonical user addresses due to LAM. With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user() exception fixups in order to be able to handle in-kernel MCEs correctly again. [ bp: Massage commit message. ]
Priority: --
CVSS v3: --
Component: linux
Publish Date: Apr 2, 2024
Related ID: --
CVSS v2: --
Modified Date: Apr 2, 2024
Find out more about CVE-2024-26674 from the MITRE-CVE dictionary and NIST NVD
Login may be required to access defects or downloads.
| Product Name |
Status |
Defect |
Fixed |
Downloads |
| Linux |
| Wind River Linux LTS 17 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux 8 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux 9 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux 7 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux LTS 21 |
Fixed |
-- |
10.21.20.22 |
-- |
| Wind River Linux LTS 22 |
Not Vulnerable |
-- |
-- |
-- |
| Wind River Linux LTS 18 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux LTS 19 |
Fixed |
-- |
10.19.45.30 |
-- |
| Wind River Linux CD release |
N/A |
-- |
-- |
-- |
| Wind River Linux 6 |
Requires LTSS |
-- |
-- |
-- |
| Wind River Linux LTS 23 |
Not Vulnerable |
-- |
-- |
-- |
| VxWorks |
| VxWorks 7 |
Not Vulnerable |
-- |
-- |
-- |
| VxWorks 6.9 |
Not Vulnerable |
-- |
-- |
-- |
| Helix Virtualization Platform Cert Edition |
| Helix Virtualization Platform Cert Edition |
Not Vulnerable |
-- |
-- |
-- |
| Product Name |
Status |
Defect |
Fixed |
Downloads |
Notes
Requires LTSS - customers must have active LTSS (Long Term Security Shield) Support to receive up-to-date information about vulnerabilities that may affect legacy software. Please contact your Wind River account team or see https://docs.windriver.com/bundle/Support_and_Maintenance_Supplemental_Terms_and_Conditions and https://support2.windriver.com/index.php?page=plc for more information.
