CVE-2026-53306

What it actually does

This is an off-by-one bounds-checking flaw in the Linux kernel hvc_iucv TTY driver. The driver allocates an array for 8 hvc_iucv console entries, indexed 0 through 7, but one validation path can incorrectly allow access to index 8 when the configured device count is 8. That can result in an out-of-bounds pointer access in kernel memory. The most likely impact is kernel instability, crash, or denial of service on affected systems using the hvc_iucv driver; depending on surrounding memory layout and reachable code paths, memory corruption risk exists, but no public exploit maturity is currently indicated.

Why it matters to the business

Affected Linux systems that use the hvc_iucv console driver, primarily specialized IBM s390/zVM-style virtualization environments, may be exposed to kernel crashes or unreliable console behavior. Operationally, this could interrupt workloads, management access, or host availability if the vulnerable driver path is reachable. The EPSS score is very low, it is not listed in CISA KEV, and no known ransomware use is reported, so urgency is lower than internet-facing actively exploited issues; however, kernel fixes should still be prioritized for platforms where this driver is enabled or required.

How an attack unfolds

An attacker would first need access to a system or execution path where the hvc_iucv TTY driver is present and active. They would then attempt to exercise the vulnerable device-selection logic when the number of configured hvc_iucv devices reaches the maximum supported count of 8. Because one check treats the device count as an inclusive upper bound, a request referencing device number 8 may pass validation even though the backing array only contains valid entries 0 through 7. The kernel may then read or dereference memory just beyond the hvc_iucv_table array. In practical terms, exploitation is likely to appear as a kernel oops, panic, or console-driver fault rather than reliable code execution, and there is no public evidence in the provided data of weaponized exploitation.

How to fix it

Apply a Linux kernel update from the relevant distribution or platform vendor that includes the hvc_iucv bounds-check fix. No exact fixed package versions were provided, so track vendor advisories for the kernel package used by the affected distribution and upgrade to a release containing the upstream fix for the hvc_iucv off-by-one issue. Where immediate patching is not possible, reduce exposure by disabling or unloading the hvc_iucv driver if it is not required, avoiding configurations that provision the maximum number of hvc_iucv devices, and restricting local administrative or device access that could exercise the vulnerable path. Validate mitigation choices carefully on IBM s390/zVM-style systems where hvc_iucv may be used for console access.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for the hvc_iucv off-by-one bounds check. Check whether the hvc_iucv module or built-in driver is present and active using kernel module inventory, boot configuration, and dmesg output. Validate that vendor kernel changelogs or package metadata reference the hvc_iucv fix. If the driver is not required, confirm it is not loaded and cannot be autoloaded through normal device access. For systems where it is required, confirm that post-upgrade testing of hvc_iucv console functionality succeeds without kernel oops, panic, or out-of-bounds access reports.

Typical attack path

1. Identify a Linux system running on an architecture or virtualization stack where the hvc_iucv driver is available and loaded.
2. Determine whether hvc_iucv devices are configured up to the maximum count of 8.
3. Gain a local or otherwise privileged path capable of interacting with the relevant hvc_iucv TTY/console device logic.
4. Trigger a code path that validates a device number using the incorrect boundary check.
5. Cause the driver to access hvc_iucv_table[8], which is outside the valid array bounds.
6. Observe resulting kernel instability, crash, or potential memory corruption effects.

How to detect it

Look for evidence of kernel faults involving the hvc_iucv driver in system logs and crash artifacts. Relevant sources include journald, syslog, dmesg, kernel ring buffer captures, kdump/vmcore records, crash utility analysis output, hypervisor console logs, and endpoint telemetry that records kernel panics or module faults. Search for oops, panic, KASAN, UBSAN, slab, or general protection fault messages that reference hvc_iucv, hvc_iucv_table, TTY/HVC, or out-of-bounds access near the time of system instability. Also review configuration and boot/module logs to determine whether hvc_iucv was loaded and whether the environment had 8 hvc_iucv devices configured. Because no public exploitation or unique attacker artifact is indicated, detection should focus on anomalous driver crashes and repeated attempts to interact with hvc_iucv console devices rather than fixed network indicators.

• hvc_iucv
• hvc_iucv_table
• hvc_iucv_table[8]
• tty: hvc_iucv
• BUG: unable to handle kernel
• general protection fault
• Kernel panic - not syncing
• Oops:
• KASAN:
• UBSAN:
• out-of-bounds
• hvc_iucv_devices
• MAX_HVC_IUCV_LINES

What your security team should do

• Inventory Linux systems where the hvc_iucv driver is loaded, built in, or required, with special focus on s390/zVM-related environments.
• Prioritize kernel updates for systems where hvc_iucv is active or where console availability is operationally important.
• If patching is delayed, disable hvc_iucv where unused and restrict local/device-level access that could trigger the vulnerable driver path.
• Monitor kernel logs for oops, panic, KASAN, UBSAN, or general protection fault messages involving hvc_iucv.
• Track distribution-specific advisories because fixed versions were not provided in the input and may vary by vendor kernel stream.
• Treat confirmed crashes in this driver as potential security events until correlated with benign operational causes.