Skip to content
VulniPulse

Red Hat Linux Security Advisories & CVEs

15666 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited sources checked less often

Get an email when Red Hat publishes the next one.

See Red Hat's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).

Alert me about Red Hat

iPhone and Android apps · New on the App Store

Monitor Red Hat CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.

Security advisories for your Red Hat release

Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata, so keep the system patched. This is the release's advisory history, not a per-package scan.

Official source

Red Hat Security Data API

Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.

Latest Red Hat advisories

UnratedRed Hat

Advisory [CVE-2026-64461] Fix IRQ domain leak when port fails to enable

In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series. When a Peripheral Component Interconnect Express (PCIe) port fails to enable, the associated Interrupt Request (IRQ) domains are not properly released. This resource leak can accumulate over time, potentially leading to a denial of service (DoS) due to resource exhaustion. Red Hat severity: not rated. Weakness: CWE-772. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64461
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64348] free iso schedules on failed submit

In the Linux kernel, the following vulnerability has been resolved: usb: free iso schedules on failed submit EHCI and FOTG210 isochronous submits build an ehci_iso_sched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until iso_stream_schedule() and the link helpers consume it. If the controller is no longer accessible, or usb_hcd_link_urb_to_ep() fails, submit jumps to done_not_linked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed. A flaw was found in the Linux kernel's Universal Serial Bus (USB) subsystem. When an isochronous USB request block (URB) submission fails, the associated schedule is not properly freed. This memory leak can accumulate over time, potentially leading to memory exhaustion and a denial of service (DoS) for the system. Red Hat severity: not rated. Weakness: CWE-772.

CVE-2026-64348
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64358] cancel workqueue on release for supported platforms only

In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: cancel workqueue on release for supported platforms only Since a recent fix the mtk_jpeg_release function cancels any pending or running work present in the driver workqueue using cancel_work_sync function. Currently, only the multicore based variants use this workqueue and they have the jpeg_worker platform data field initialized with a workqueue callback function. For the others, this field value remain NULL by default. The cancel_work_sync function is unconditionally called in mtk_jpeg_release function, even for the variants that do not use the workqueue. This call generates a WARN_ON print in __flush_work because the workqueue callback function presence check fails in __flush_work function (used by cancel_work_sync). So, to avoid these warnings, call cancel_work_sync only if a workqueue callback is defined in platform data. An internal function attempts to cancel a background task even when that task is not active on certain system configurations. This can lead to the system logging warning messages, potentially causing minor system instability or unexpected behavior. This issue does not result in critical security impacts such as data compromise or unauthorized code execution. Red Hat severity: not rated. Weakness: CWE-476.

CVE-2026-64358
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64521] fix deadlock issue

In the Linux kernel, the following vulnerability has been resolved: pinctrl: meson: amlogic-a4: fix deadlock issue Accessing the pinconf-pins sysfs node may deadlock. pinconf_pins_show() holds pctldev->mutex, and the platform driver calls pinctrl_find_gpio_range_from_pin(), which tries to acquire the same mutex again, leading to a deadlock. Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue. A flaw was found in the Linux kernel's pinctrl subsystem for Amlogic A4 devices. This occurs because the `pinconf_pins_show()` function attempts to acquire a mutex that is already held, leading to a system freeze or unresponsiveness. This vulnerability can result in a denial of service. Red Hat severity: not rated. Weakness: CWE-764. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64521
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64272] mms114 - fix touch indexing for MMS134S and MMS136

In the Linux kernel, the following vulnerability has been resolved: Input: mms114 - fix touch indexing for MMS134S and MMS136 The MMS134S and MMS136 touch controllers have an event size of 6 bytes rather than 8 bytes. When __mms114_read_reg() reads the touch data packet from the device into the touch buffer, the events are packed tightly at 6-byte intervals. However, the driver iterates through the events using standard C array indexing (touch[index]), where each element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any touch events beyond the first one are read from incorrect offsets and parsed improperly. Fix this by explicitly calculating the byte offset for each touch event based on the device's specific event size. The driver misinterprets the size of touch event data, causing it to read information from incorrect memory locations. This issue, known as an out-of-bounds read, could be exploited by a local attacker to disrupt system operations or potentially access sensitive data, leading to a denial of service or information disclosure. Red Hat severity: not rated. Weakness: CWE-125. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64272
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64443] fix OOB read in update_beacon_info IE loop

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above. A remote attacker could exploit an out-of-bounds read vulnerability in the `update_beacon_info()` function by sending a specially crafted wireless Beacon frame containing a malformed Information Element (IE). This could lead to the disclosure of sensitive information or cause a denial of-service (DoS) on the affected system. Red Hat severity: not rated. Weakness: CWE-125. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64443
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64447] fix double-free and use-after-free in error paths

In the Linux kernel, the following vulnerability has been resolved: staging: media: ipu7: fix double-free and use-after-free in error paths In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and then passed to ipu7_bus_initialize_device(), which stores it in adev->pdata. The ipu7_bus_release() function frees adev->pdata when the device's reference count drops to zero. Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it: 1. 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit() internally, which calls put_device() -> ipu7_bus_release() -> kfree(pdata). Note that the kfree(pdata) when ipu7_bus_initialize_device() itself fails is correct, because in that case auxiliary_device_init() failed and the release function was never set up, so pdata must be freed manually. Additionally, the error code was not saved before calling put_device(), causing ERR_CAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from dev_err_probe() before put_device() and returning ERR_PTR() instead. Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths.

CVE-2026-64447
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64528] Remove redundant port lock acquisition in rx helpers

In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the.stop_tx() and.start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. When console flow control is enabled, a redundant attempt to acquire a port lock occurs within the receive helper functions. This can lead to a deadlock on the same CPU, causing the system to become unresponsive. Red Hat severity: not rated. Weakness: CWE-833.

CVE-2026-64528
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64399] add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE

In the Linux kernel, the following vulnerability has been resolved: ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE The FSCTL_DUPLICATE_EXTENTS_TO_FILE arm of smb2_ioctl() overwrites the destination file's data via vfs_clone_file_range() with neither the share-level KSMBD_TREE_CONN_FLAG_WRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILE_WRITE_ATTRIBUTES (which still yields an FMODE_WRITE filp). Add both checks, matching the FSCTL_SET_SPARSE permission fix; require FILE_WRITE_DATA since this writes data. A flaw was found in ksmbd. This vulnerability allows a remote attacker to overwrite data on a shared file system due to insufficient permission checks in the FSCTL_DUPLICATE_EXTENTS_TO_FILE function. Even if a share is configured as read-only or a client has limited write attributes, an attacker can still modify the destination file's data, leading to unauthorized data alteration. Red Hat severity: not rated. Weakness: CWE-250. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64399
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64392] use opener credentials for delete-on-close

In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for delete-on-close Delete-on-close can be completed by deferred or durable handle teardown, where no request work is available. Both the base-file unlink and the ADS xattr removal consequently run with the ksmbd worker credentials and can bypass filesystem permission checks. Run both operations with the credentials captured in struct file when the handle was opened. This preserves the authenticated user's fsuid, fsgid, supplementary groups and capability restrictions at final close. This vulnerability allows an attacker to bypass filesystem permission checks during 'delete-on-close' operations. Specifically, when a file handle is torn down, the base-file unlink and extended attribute (xattr) removal operations incorrectly execute with ksmbd worker credentials instead of the original opener's credentials. This can lead to unauthorized deletion of files or removal of extended attributes, potentially compromising data integrity and availability. Red Hat severity: not rated. Weakness: CWE-270. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64392
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64504] clamp the device-reported FIFO frame count

In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: count = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: if (samples && count > samples) count = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: bmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address.

CVE-2026-64504
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64389] validate NTLMv2 response before updating session key

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate NTLMv2 response before updating session key ksmbd_auth_ntlmv2() derives the NTLMv2 session key into sess->sess_key before it verifies the NTLMv2 response. ksmbd_decode_ntlmssp_auth_blob() then continues into KEY_XCH even when ksmbd_auth_ntlmv2() failed. With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEY_XCH and still modify sess->sess_key before STATUS_LOGON_FAILURE is returned. Relevant path: smb2_sess_setup() -> conn->binding = true -> ntlm_authenticate() -> session_user() -> ksmbd_decode_ntlmssp_auth_blob() -> ksmbd_auth_ntlmv2() -> calc_ntlmv2_hash() -> hmac_md5_usingrawkey(..., sess->sess_key) -> crypto_memneq() returns mismatch -> KEY_XCH arc4_crypt(..., sess->sess_key,...) -> out_err without expiring the binding session Derive the base session key into a local buffer and copy it to sess->sess_key only after the proof matches. Return immediately on authentication failure so KEY_XCH is only processed after successful authentication. A remote attacker could exploit a vulnerability in the NTLMv2 authentication process to modify a session key even when authentication fails.

CVE-2026-64389
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64390] track the connection owning a byte-range lock

In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again. A flaw was found in the Linux kernel's ksmbd component, which provides Server Message Block (SMB) protocol support. This vulnerability involves incorrect management of byte-range locks when multiple connections are used with SMB3 multichannel. An attacker could exploit this by sending specially crafted SMB requests, potentially causing memory corruption.

CVE-2026-64390
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64501] fix CS held asserted and state leaks

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad_sigma_delta: fix CS held asserted and state leaks In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and disable_one() were called from the out: block while keep_cs_asserted was still true. This caused any SPI transfer issued by those callbacks to carry cs_change=1, leaving CS permanently asserted after the conversion. Fix by moving both calls into the out_unlock: block, after keep_cs_asserted is cleared, matching the pattern already used in ad_sd_calibrate(). In the error path of ad_sd_buffer_postenable(), if an operation fails after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g. spi_offload_trigger_enable()), the device is left in continuous conversion mode with CS physically asserted. Additionally, bus_locked remaining true after spi_bus_unlock() causes subsequent SPI operations to call spi_sync_locked() without the bus lock actually held, allowing concurrent SPI access. Fix the error path by clearing keep_cs_asserted first, then calling set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS, then clearing bus_locked before releasing the bus. For devices that implement neither set_mode nor disable_one (such as MAX11205, which has no physical CS pin), no SPI transfer is issued during cleanup and the cs_change flag has no effect on any physical line.

CVE-2026-64501
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64444] fix OOB read in OnAssocRsp IE loop

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len. A remote attacker, by operating a malicious Access Point (AP), could send a specially crafted association response frame. This could lead to an out-of-bounds read vulnerability, potentially causing information disclosure or system instability. Red Hat severity: not rated. Weakness: CWE-125. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64444
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64498] free scan_mask on buffer release

In the Linux kernel, the following vulnerability has been resolved: iio: buffer: hw-consumer: free scan_mask on buffer release The scan_mask lifetime changed in commit 9a2e1233d38c ("iio: buffer: hw-consumer: remove redundant scan_mask flexible array"). Before that change, the scan mask storage was embedded in struct hw_consumer_buffer, so iio_hw_buf_release() could free the whole allocation with a single kfree(hw_buf). That commit moved the scan mask to a separate bitmap_zalloc() allocation stored in buffer.scan_mask, but left iio_hw_buf_release() unchanged. A flaw was found in the Linux kernel's Industrial I/O (IIO) subsystem, specifically within the hardware consumer buffer (hw-consumer). Due to an oversight in memory management, a dedicated memory region (scan_mask) was not properly released when its associated buffer was freed. A local attacker with low privileges could exploit this memory leak, potentially leading to system instability or a denial of service (DoS) by exhausting available memory resources. Red Hat severity: not rated. Weakness: CWE-772. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64498
Unclassified
Jul 25, 2026
UnratedRed Hat

Advisory [CVE-2026-64462] Fix resource leaks on probe failure

In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log] When the driver fails to initialize properly, it can leave interrupt handlers and related resources active with outdated information. This resource leak and stale data pointer can lead to system instability or a denial of service, where the system becomes unresponsive or crashes. Red Hat severity: not rated. Weakness: CWE-825. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.

CVE-2026-64462
Unclassified
Jul 25, 2026
High8.8Red Hat

High [CVE-2026-66041] Arbitrary code execution via crafted PGS/SUP subtitle file

FFmpeg 7.0 through 8.1.2, fixed in commit 4da9812, contains a heap out-of-bounds write vulnerability in the vf_quirc filter that allows an attacker to corrupt heap memory by supplying a crafted PGS/SUP subtitle file with mismatched frame dimensions. Attackers can provide a subtitle file whose second presentation has larger dimensions than its first, causing av_image_copy_plane() to copy data exceeding the initial allocation size into the undersized libquirc grayscale image buffer, resulting in heap corruption and process crash with potential for code execution. A flaw was found in FFmpeg's `vf_quirc` filter, which handles subtitle processing. This file, with mismatched frame dimensions, can cause the software to write data beyond the allocated memory buffer. Successful exploitation can lead to heap corruption, a process crash, and potentially arbitrary code execution, allowing the attacker to run malicious code on the affected system. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux AI (RHEL AI) 3; Red Hat OpenShift AI (RHOAI). Red Hat does not currently list a fixing RHSA for this CVE.

CVE-2026-66041
Unclassified
Jul 24, 2026
High8.8Red Hat

High [CVE-2026-66040] Arbitrary code execution via crafted PNG image

FFmpeg through 8.1.2, fixed in commit b506faf, contains a heap out-of-bounds write vulnerability in the native PNG and APNG encoders that allows remote attackers to corrupt heap memory by supplying a crafted PNG image with a malicious eXIf chunk. Attackers can craft an eXIf chunk where multiple IFD entries reference the same large value payload, causing canonical serialization to expand the output far beyond the undersized allocation estimated by add_exif_profile_size(), resulting in png_write_chunk() writing tens of thousands of bytes past the buffer boundary, leading to deterministic heap corruption, process crash, and potentially arbitrary code execution. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat OpenShift AI 3.3; Red Hat Enterprise Linux AI (RHEL AI) 3. Red Hat fixing advisory: RHSA-2026:73987.

CVE-2026-66040
Unclassified
Jul 24, 2026
High8.8Red Hat

High [CVE-2026-66039] Arbitrary code execution via crafted CAF file

FFmpeg through 8.1.2, fixed in commit aafb5c6, contains a signed integer overflow vulnerability in the MACE6 audio decoder that allows attackers to corrupt heap memory by supplying a crafted CAF file with a malicious bytes_per_packet value. Attackers can craft a CAF file with oversized bytes_per_packet and frames_per_packet values in the desc chunk to trigger an integer overflow in mace_decode_frame() during output sample count computation, resulting in an undersized buffer allocation and heap out-of-bounds write that could enable code execution. A flaw was found in FFmpeg. This vulnerability could allow an attacker to execute arbitrary code on the affected system. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux AI 3.0 for RHEL 9; Red Hat Enterprise Linux AI 3.3 for RHEL 9; Red Hat Enterprise Linux AI 3.4 for RHEL 9; Red Hat Enterprise Linux AI 3.5 for RHEL 9; Red Hat Enterprise Linux AI 3.6 for RHEL 9; Red Hat OpenShift AI 2.25; Red Hat OpenShift AI 3.5; Red Hat Enterprise Linux AI (RHEL AI) 3. Red Hat fixing advisory: RHSA-2026:74089, RHSA-2026:60336, RHSA-2026:60334, RHSA-2026:60335, RHSA-2026:66381, RHSA-2026:65126, RHSA-2026:74771.

CVE-2026-66039
Unclassified
Jul 24, 2026

← All vendors

Free weekly CVE digest

Every Monday: the week's critical and high advisories for Red Hat or every vendor, new CISA KEV entries and upcoming end-of-life dates.

Free, no account. Confirm by email; unsubscribe in one click. Choose vendors and severity