CVE-2024-42096
Description
From CVE.org
In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 5.1 | 5.5 | N/A |
| Attack Vector | Local | Local | N/A |
| Attack Complexity | Low | Low | N/A |
| Privileges Required | High | Low | N/A |
| User Interaction | None | None | N/A |
| Scope | Unchanged | Unchanged | N/A |
| Confidentiality | Low | None | N/A |
| Integrity Impact | None | None | N/A |
| Availability Impact | High | High | N/A |
Vector
Red Hat: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
NVD: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Memory
An attacker could get secret values such as cryptographic keys, PII, memory addresses, or other information that could be used in additional attacks.
Confidentiality
Technical Impact: Bypass Protection Mechanism
Out-of-bounds memory could contain memory addresses or other information that can be used to bypass ASLR and other protection mechanisms in order to improve the reliability of exploiting a separate weakness for code execution.
Availability
Technical Impact: DoS: Crash, Exit, or Restart
An attacker could cause a segmentation fault or crash by causing memory to be read outside of the bounds of the buffer. This is especially likely when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string.
Other
Technical Impact: Varies by Context
The read operation could produce other undefined or unexpected results.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.