CVE-2024-40974

HIGH EPSS 21.9%
Published Jul 12, 20241y ago · Modified Jun 17, 20262w ago
7.8 CVSS 3.1
High
Find Similar
Published Jul 12, 2024 1y ago
Last Modified Jun 17, 2026 2w ago

Description

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.

CVSS Details

Base Score
7.8
Exploitability
1.8
Impact
5.9
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector Local
Attack Complexity Low
Privileges Required Low
User Interaction None
Scope Unchanged
Confidentiality High
Integrity High
Availability High

Threat Intelligence

EPSS Exploit Probability
21.9% percentile
Exploit & Patch Status
No Known Exploit
Patch Available

Weaknesses 1

CWE-787 Out-of-bounds Write Memory Safety

Affected Products 7

VendorProductVersionRange
linuxlinux_kernel* <4.19.317
linuxlinux_kernel*≥4.20  –  <5.4.279
linuxlinux_kernel*≥5.5  –  <5.10.221
linuxlinux_kernel*≥5.11  –  <5.15.162
linuxlinux_kernel*≥5.16  –  <6.1.96
linuxlinux_kernel*≥6.2  –  <6.6.36
linuxlinux_kernel*≥6.7  –  <6.9.7

References 9

  • git.kernel.org https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a445c3e4
    Patch
  • lists.debian.org https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

Remediation

  • git.kernel.org https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a445c3e4
    Patch