CVE-2024-40974: powerpc/pseries: Enforce hcall result buffer validity and size
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Enforce hcall result buffer validity and size
plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.
For example, if I write a bug like this:
long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);
This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)
To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:
error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
| ^ ~~~~~~
[1] Enabled for LLVM builds but not GCC for now. See commit
0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
related changes.
Security readout for executives and security teams
Plain-English summary
Linux PowerPC pSeries hypercall interfaces did not let the compiler reliably detect undersized result buffers. A mistaken caller could therefore overwrite kernel stack memory, potentially causing crashes or broader compromise. The source describes only a contrived example and says no real vulnerable caller was found.
Executive priority
Treat this as targeted high-priority kernel maintenance for PowerPC pSeries fleets, not an enterprise-wide emergency. Prioritize internet-facing or multi-user relevant systems, but first confirm platform applicability because the disclosed example was theoretical and active exploitation is unsupported.
Technical view
The fix declares plpar_hcall(), plpar_hcall9(), and related result parameters as explicitly sized arrays. This lets supported array-bounds diagnostics reject buffers smaller than the API requires. The stated runtime consequence of such misuse is an out-of-bounds result write and possible stack corruption; LLVM builds had the relevant warning enabled, while GCC builds did not.
Likely exposure
Exposure is concentrated in Linux systems using the PowerPC pSeries subsystem and affected kernel code. It is not presented as a general vulnerability across every Linux architecture. Custom or out-of-tree kernel callers warrant additional review. Confirm exposure through architecture, kernel package, and downstream backport records rather than version strings alone.
Exploitation context
The supplied CVSS is 7.8 and describes a local, low-privilege path requiring no user interaction. However, KEV is false, no cited source reports active exploitation, and the disclosure says no real undersized caller was found. Practical exploitation therefore remains unsubstantiated by this bundle.
Researcher notes
The record supplies no CWE and identifies no concrete vulnerable call site. The change primarily strengthens compile-time API contracts, reducing the chance that future or external callers create a runtime overwrite. Severity reflects potential kernel stack corruption, while real-world reachability and trigger conditions remain insufficiently evidenced.
Mitigation direction
Inventory PowerPC pSeries systems and map their running kernels to vendor advisories.
Apply a supported kernel update incorporating the referenced stable fix or documented downstream backport.
Reboot affected systems into the updated kernel and retire superseded boot entries where operationally appropriate.
For custom kernels, adopt the corrected declarations and enable supported array-bounds diagnostics.
Consult the Linux distribution or kernel vendor if package remediation status is unclear.
Validation and detection
Confirm whether each candidate system uses PowerPC pSeries functionality.
Compare installed kernel packages and source provenance with vendor backport documentation.
After maintenance, verify the updated kernel is actually running.
Review custom and out-of-tree hypercall callers for correctly sized result buffers.
Confirm builds report undersized array arguments where the compiler supports that diagnostic.
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-40974 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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.