CVE WatchAug 4, 2026

CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_h

CVSS

7.8

High

EPSS

0.3%

p23

KEV

—

Exploit Today

0-100

Published: Jul 12, 2024 · Last modified: Aug 4, 2026 · CWE-787

EPSS · 30d

0.3%EPSS · 30 days0.3%

2026-08-122026-09-09

Technical 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.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-567118.8 HIG

—

——0VLC media player computes the size of a picture buffer with 32-bit arithmetic and allocates from the wrapped result. In AllocatePicture in src/misc/picture.c the running total is accumulated as i_bytes += p->i_pitch * p->i_lines, and both plane_t fields are declared int in include/vlc_picture.h, so the multiplication is evaluated at 32 bits and wraps before it is widened to the size_t accumulator. The overflow check that precedes it divides in 64-bit arithmetic and therefore does not constrain the product, and the subsequent comparison against PICTURE_SW_SIZE_MAX examines the already wrapped value, so both guards pass. aligned_alloc then reserves the small wrapped size while the decoder writes scanlines sized from the original dimensions. A crafted PNG whose IHDR declares large width and height reaches this path through the image demuxer, whose only size guard is on the input file's byte count rather than the declared dimensions, and the decoder in modules/codec/png.c writes past the end of the allocation with attacker-influenced length and content. Opening the file directly or through a playlist entry is sufficient, with no non-default settings.1d CVE-2026-876389.6 CRI

20.0%

——6Out of bounds write in Media in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium)1d CVE-2026-876219.6 CRI

11.8%

——4Out of bounds write in ANGLE in Google Chrome on on Windows prior to 153.0.8010.36 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)1d CVE-2026-874918.8 HIG

21.4%

KEV—56Google Chromium V8 Out of Bounds Write Vulnerability1d CVE-2026-874389.6 CRI

32.0%

——10Out of bounds write in WebGL in Google Chrome on on Android prior to 153.0.8010.36 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical)1d CVE-2026-539388.2 HIG

14.6%

——4OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose's JWE decryption path for the AES Key Wrap key-management algorithms (`alg` = `A128KW`, `A192KW`, `A256KW`) does not validate the length of the attacker-supplied `encrypted_key` (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. `cjose_jwe_import()` / `cjose_jwe_decrypt()` are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (`A128KW`/`A192KW`/`A256KW`) for untrusted JWEs at the application layer.1d