CVE-2026-53306 in Linux
Summary
by MITRE • 06/26/2026
In the Linux kernel, the following vulnerability has been resolved:
tty: hvc_iucv: fix off-by-one in number of supported devices
MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];
Sometimes hvc_iucv_table[] is limited by:
(a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.)
hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES)
If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].
Oops.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/27/2026
This vulnerability exists in the Linux kernel's hvc_iucv tty driver implementation where an off-by-one error occurs in the management of virtual console devices. The issue stems from a fundamental mismatch between the maximum number of supported devices defined by MAX_HVC_IUCV_LINES which equals 8 and the actual device counter hvc_iucv_devices that can range from 0 to 8. The static array hvc_iucv_table[MAX_HVC_IUCV_LINES] contains exactly 8 elements indexed from 0 to 7, yet the code logic permits access to index 8 when hvc_iucv_devices equals 8, creating a buffer overflow condition that violates standard memory safety principles.
The vulnerability manifests through inconsistent boundary checking mechanisms within the driver's device management code. The first validation check uses if (num > hvc_iucv_devices) which allows access to hvc_iucv_table[8] when hvc_iucv_devices is 8, while the second validation uses for (i = 0; i < hvc_iucv_devices; i++) loops that correctly limit access to indices 0 through 7. This discrepancy creates a dangerous path where code can access memory beyond the allocated array bounds, potentially leading to memory corruption and system instability. The inconsistent boundary enforcement represents a classic software defect pattern that aligns with CWE-129 and CWE-131 vulnerability classifications.
The operational impact of this vulnerability extends beyond simple memory corruption as it affects the kernel's tty subsystem which handles terminal device operations critical to system functionality. An attacker could potentially exploit this buffer overflow to execute arbitrary code within kernel space, gaining elevated privileges and compromising system integrity. The vulnerability is particularly concerning because it occurs in a core kernel component that manages virtual console communications, making it accessible through normal system operations involving terminal devices. This type of vulnerability falls under ATT&CK technique T1068 which involves exploiting vulnerabilities in the operating system to gain elevated privileges.
The fix for this vulnerability requires implementing consistent boundary checking that ensures array access remains within valid bounds by changing the problematic condition from if (num > hvc_iucv_devices) to if (num >= hvc_iucv_devices) or by ensuring the loop termination condition properly validates against the maximum array size. Additionally, the code should validate that hvc_iucv_devices never exceeds MAX_HVC_IUCV_LINES-1 to prevent any potential overflow conditions. Proper defensive programming practices including bounds checking, input validation, and consistent boundary enforcement are essential for preventing such memory safety violations in kernel space operations. This vulnerability demonstrates the critical importance of maintaining array access consistency in kernel drivers where memory corruption can lead to complete system compromise rather than just application-level failures.