CVE intelligence

CVE-2026-53138

Vulnerability intelligence

Published Jun 25, 2026Sources checked Nov 12, 2026

7.1HIGHCVSS out of 10

What this means

Review the available evidence

CVE-2026-53138 and is rated High severity with a CVSS score of 7.1. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Ubuntu Security Notices guidance

Vendor revision: Oct 9, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - ARM32 architecture; - ARM64 architecture; - MIPS architecture; - x86 architecture; - Intel NPU Driver; - Auxiliary display drivers; - Compressed RAM block device driver; - GPIO subsystem; - GPU drivers; - HID subsystem; - I2C subsystem; - IIO subsystem; - InfiniBand drivers; - Input Device core drivers; - Input Device (Mouse) drivers; - Multiple devices driver; - Media drivers; - Fastrpc Driver; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Texas Instruments network drivers; - NVMEM (Non Volatile Memory) drivers; - Parport drivers; - SCSI subsystem; - SLIMbus drivers; - NVIDIA Tegra SoC drivers; - SPI subsystem; - Trusted Execution Environment drivers; -

Ubuntu Security Notices guidance

Vendor revision: Oct 9, 2026

Vendor remediation details

Ubuntu Security Notices guidance

Vendor revision: Oct 8, 2026

Vendor remediation details

CISA KEVNot listedBased on the latest collected catalog

EPSS0.1%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2026-53138?

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Bound VBIOS record-chain walk loops

[Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1.

In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds.

Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13.

Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound.

(cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)

Source: NVD