Information Exposure Affecting kernel-64kb-devel package, versions <6.4.0-150600.23.30.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES156-KERNEL64KBDEVEL-8512341
- published14 Dec 2024
- disclosed13 Dec 2024
Introduced: 13 Dec 2024
NewCVE-2024-50102 (opens in a new tab)How to fix?
Upgrade SLES:15.6 kernel-64kb-devel to version 6.4.0-150600.23.30.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64kb-devel package and not the kernel-64kb-devel package as distributed by SLES.
See How to fix? for SLES:15.6 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.