CVE WatchAug 4, 2026

CVE-2024-46713

In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_m

CVSS

7.8

High

EPSS

0.3%

p23

KEV

—

Exploit Today

0-100

Published: Sep 13, 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: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.

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)23h 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)23h CVE-2026-874918.8 HIG

21.4%

KEV—56Google Chromium V8 Out of Bounds Write Vulnerability22h 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.23h