The Linux kernel’s digital TV code carried an off-by-one indexing bug that now has its own identifier: CVE-2026-31405. It is rated CVSS 9.8, squarely in the critical range, and the reason is real: under certain conditions the kernel reads a function pointer from beyond the end of a table and ends up calling it.
The bug lives in handle_one_ule_extension(), part of the code that processes ULE (Ultra Lightweight Encapsulation), the format that carries IP packets over MPEG streams in DVB. That function decides what to do with each extension by indexing into two function pointer tables: ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[]. Both are declared with 255 elements, meaning valid indices 0 through 254. The trouble is that the htype index, derived from network data, can reach 255. Using 255 against a table that only goes up to 254 makes the kernel read a memory location it does not own and treat that content as a valid function pointer.
From there, two outcomes follow. The milder one is a kernel crash, a denial of service that takes the machine down. The worse one is code execution: if an attacker can shape what sits in that adjacent memory, calling the pointer jumps to code of their choosing.
Who is affected
Any Linux system that has the DVB subsystem with ULE processing built and in use. That covers digital TV receivers, tuner cards and hardware that ingests DVB streams in general. The version range is wide: the flaw has been present since 2.6.12, so it spans most of modern kernel history, including supported branches such as 5.10, 5.15, 6.1, 6.6, 6.12 and the 6.19 and 7.0 series.
The CVSS vector (AV:N/AC:L/PR:N/UI:N) points to network access, low complexity, no required privileges and no user interaction. That explains the high score. The practical condition is that the machine is processing attacker-controllable ULE data, which fits a scenario where the received DVB stream is not trusted.
Mitigation
The patch is straightforward: it adds a bounds check on htype before either table is accessed. When the value is out of range, the SNDU (the data unit) is discarded instead of proceeding. There is nothing to configure; the fix is to update the kernel to a version that carries the change.
If your distribution ships its own kernels, install the security updates as soon as they land and reboot, or use livepatch if your vendor offers it. On systems that do not use DVB at all, unloading the relevant module shrinks the exposed surface until the patch arrives, though updating remains the right call.
You can check the Linux kernel version list to see which branch you are on and whether it already includes the fix.
Source
- NVD — CVE-2026-31405 Detail: https://nvd.nist.gov/vuln/detail/CVE-2026-31405