CVE-2026-89525

What it actually does

The Linux kernel UDF driver performs an off-by-one bounds check in udf_get_pblock_virt15() when resolving UDF 1.50 virtual partition mappings. s_num_entries is an exclusive count of Virtual Allocation Table (VAT) slots, but the pre-fix check only rejected indexes greater than that count, so index == s_num_entries was accepted and the kernel read one entry past the allocated VAT array. The result is a slab out-of-bounds read in kernel context that can panic the host and, depending on slab layout, expose adjacent heap contents. This is local memory corruption in the filesystem stack, not a remotely reachable network service flaw.

Why it matters to the business

Any Linux host that mounts untrusted UDF media—USB sticks, optical discs, ISOs, or other disk images—can be crashed with a kernel panic, taking down all workloads on that machine until reboot. Highest operational exposure is on desktops and kiosks with automount, multi-user jump boxes, CI/build agents, backup/restore and forensic/sandbox systems that ingest untrusted images, and appliances that still use UDF. The issue is not in CISA KEV, is not tied to ransomware campaigns, and has no public exploit maturity rating beyond a known panic-triggering reproducer described about a month after disclosure. Residual risk is primarily availability (sudden host outage) and, secondarily, confidentiality if adjacent kernel heap is observed; treat unpatched kernels that still load the udf module as an urgent local hardening item rather than an internet-facing emergency.

How an attack unfolds

An attacker crafts a UDF 1.50 filesystem image that uses virtual partition mapping and induces a VAT lookup whose index equals the stored entry count. The image is delivered as removable media, an ISO, or another mountable block device. When a user, automounter, or tooling mounts the image with the in-tree UDF driver, block-mapping calls udf_get_pblock_virt15(), the off-by-one check succeeds, and the kernel reads one slot past the VAT allocation. On instrumented kernels this surfaces as a KASAN slab-out-of-bounds report in that function; on production kernels it commonly panics. Exploitation requires the victim to mount the crafted filesystem (or a privileged local user to do so); it does not by itself provide unauthenticated remote code execution. A public panic reproducer exists, which lowers the bar for denial-of-service even though no in-the-wild campaign is indicated.

How to fix it

Apply Linux kernel updates from your distribution or vendor that include the UDF fix changing udf_get_pblock_virt15() to reject VAT indexes >= s_num_entries (treat the entry count as an exclusive upper bound). Rebuild and redeploy custom kernels that still contain the old comparison. Until every host is patched, prevent untrusted UDF mounts: blacklist or unload the udf module where UDF is not required, disable automount of udf, and restrict who can mount removable media or arbitrary disk images. Do not rely on userspace scanners alone; the defect is in kernel block mapping after mount.

How to confirm the fix worked

Confirm installed kernel packages include the UDF VAT bounds-check fix (changelog or git commit covering udf_get_pblock_virt15 rejecting index >= s_num_entries). On running systems, verify uname -r against the patched package set, check whether udf is loaded (lsmod) or built-in, and inspect the running kernel source/debuginfo or distro patch list for the exclusive-bound comparison. After patching, regression-test only with trusted UDF media; do not validate by mounting untrusted crafted images on production hosts. Systems that never load udf and have automount of that type disabled can be recorded as not exposed.

Typical attack path

1. Prepare a UDF 1.50 image that uses virtual partition mapping and a VAT index equal to the table entry count
2. Deliver the image as USB/optical media, an ISO, or another block device the target is likely to mount
3. Rely on user action, automount, or image-ingestion tooling to mount the filesystem with the Linux UDF driver
4. Cause the kernel to resolve a virtual partition block so udf_get_pblock_virt15() indexes one past the allocated VAT
5. Induce a kernel oops/panic (denial of service) or an out-of-bounds slab read of adjacent kernel memory

How to detect it

This is a kernel-space out-of-bounds read at mount/block-map time, so evidence lives in kernel logs rather than application telemetry. Search dmesg, journalctl -k, crash dumps, and kdump/vmcore for oops, panic, or KASAN slab-out-of-bounds reports whose call trace includes udf_get_pblock_virt15 or other udf_* helpers around the time a UDF volume was mounted. Correlate with audit or systemd mount records for fstype=udf, unusual block devices (USB, loop, ISO), and automount activity. On KASAN/debug kernels look for slab-out-of-bounds attributed to the UDF VAT path; on production kernels look for BUG/Oops followed by a UDF stack. Absence of these artifacts does not prove non-exploitation if logs rotated, but a matching oops plus a contemporaneous untrusted UDF mount is a strong historic indicator. There are no stable network signatures.

• udf_get_pblock_virt15
• KASAN: slab-out-of-bounds
• KASAN: slab-out-of-bounds in udf_get_pblock_virt15
• Call Trace: udf_get_pblock_virt15
• Oops:.*udf_
• kernel BUG at fs/udf/
• fstype=udf
• mount.*type udf
• UDF-fs:
• udf: error

What your security team should do

• Patch Linux kernels so UDF VAT lookups reject indexes >= s_num_entries; prioritize hosts that automount removable media or ingest untrusted disk images
• Until patched, blacklist/unload udf where unused and disable automount of UDF volumes
• Hunt historical kernel logs for oops/KASAN hits in udf_get_pblock_virt15 and for unexpected udf mounts
• Inventory where the udf module is loaded or built-in across fleets (desktops, kiosks, CI, forensic, and backup systems first)
• Treat this as local DoS/memory-corruption risk, not a network worm; still close it promptly because a panic reproducer is known and the bug has been public for weeks