CVE-2024-26674: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups
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:<ffffffff821b9776> {__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. ]
Security readout for executives and security teams
Plain-English summary
CVE-2024-26674 is a Linux kernel reliability flaw where certain user-memory access fixups can turn a recoverable machine-check condition into a kernel panic. The public sources describe crashes during memory error injection on kernels from the 6.4 era onward. This is primarily an availability risk, not a documented data theft or remote code execution issue.
Executive priority
Treat this as a maintenance-priority availability issue. It is not listed as exploited, but unpatched affected kernels may panic under hardware memory error conditions, which matters for critical servers and high-availability services.
Technical view
The regression replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for get_user() and put_user() fixups. That changed exception handling from EX_TYPE_UACCESS to EX_TYPE_DEFAULT, causing in-kernel machine checks during user access to panic instead of using recoverable uaccess handling. The fix reverts those fixups to _ASM_EXTABLE_UA().
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or downstream builds carrying the regressing x86 get_user()/put_user() change. The provided metadata indicates Linux kernel 6.4-era branches and stable fixes, but distribution backport status must be verified separately.
Exploitation context
The sources describe reproduction through memory error injection and do not report active exploitation. KEV is false. No public source in the bundle supports remote exploitation, privilege escalation, or weaponized use.
Researcher notes
Evidence is specific to x86 uaccess exception table handling and machine-check recovery. The bundle does not provide CVSS, CWE, exploitability details, or distribution-specific package fixes. Validate exposure through kernel version, downstream patch state, and crash telemetry.
Mitigation direction
Upgrade to a kernel containing the referenced stable fix or a distribution backport.
Check your Linux vendor advisory for exact package names and fixed versions.
Prioritize systems where kernel panic has high business impact.
Schedule reboot requirements into maintenance planning after kernel update.
Validation and detection
Inventory Linux kernel versions across production and staging systems.
Map running kernels to vendor advisories or the referenced stable commits.
Confirm patched hosts are running the updated kernel after reboot.
Review kernel crash logs for machine-check panics in user-access paths.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-26674 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.