CVE-2026-64318

What it actually does

This Linux kernel flaw is an out-of-bounds read in the AIX partition-table parser. During block-device partition discovery, the kernel reads an on-disk AIX physical volume descriptor into a fixed-size allocation containing space for 1016 partition-extent entries, but it trusts the on-disk pp_count value and can iterate up to 65535 entries. A crafted disk image or block device can therefore make the kernel read beyond the allocated structure during partition scanning, before any filesystem is mounted. The likely outcomes are kernel memory disclosure through side effects or diagnostics, kernel fault/oops, and denial of service; reliable code execution is not indicated by the available details.

Why it matters to the business

Systems that allow users, automation, virtualization tooling, container runtimes, forensic tools, or removable-media workflows to attach untrusted disk images may be crashed by a malicious image during automatic partition probing. The operational risk is highest for multi-user Linux hosts, build or CI systems, virtualization platforms, desktop fleets handling removable media, and services that inspect uploaded disk images. Although this is not in CISA KEV, has very low EPSS at this time, and has no reported mature exploit, kernel-level crashes can still create service outages and incident-response workload.

How an attack unfolds

An attacker first needs local capability to cause a Linux system to scan an attacker-controlled block device or disk image, such as by attaching a crafted image with loop-device partition scanning, presenting malicious removable media, or submitting a disk image to a system that automatically probes partitions. The crafted image contains an AIX/IBM-style partition structure whose physical volume descriptor advertises a pp_count larger than the in-memory ppe array can hold. When the kernel partition discovery path reaches the AIX parser, it iterates past the end of the allocated descriptor while reading partition-extent entries. Depending on memory layout and kernel hardening, the result may be a kernel oops, KASAN report, panic, or other denial-of-service condition; limited exposure of adjacent kernel memory may also be possible through crash telemetry or diagnostic output.

How to fix it

Upgrade to a Linux kernel build that includes the fix clamping the AIX partition pp_count scan to the actual ppe array length. Where vendor-fixed package versions are available, deploy the exact distribution kernel updates from the operating-system vendor rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by preventing untrusted users and services from attaching loop devices or raw block devices, disabling or tightly controlling automatic partition probing of untrusted media/images, restricting access to losetup and similar tooling, and processing untrusted disk images only inside disposable, isolated sandboxes. Consider disabling rarely used partition formats only if supported by the distribution or local kernel configuration and tested for operational impact.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the AIX partition parser by checking the installed kernel package changelog/advisory or source patch history for the pp_count bounds check. Verify all booted hosts are actually running the patched kernel after reboot, not merely having the package installed. On representative non-production systems, test that malformed images are rejected or handled without kernel oops/panic. Review whether any services can attach untrusted block images, use loop devices with partition scanning, or trigger udev partition discovery. Validate compensating controls by ensuring unprivileged users cannot create or scan loop devices unless explicitly required.

Typical attack path

1. Obtain local access or access to a workflow that accepts or auto-probes disk images, removable media, or virtual block devices.
2. Create a malformed AIX/IBM partition image with a physical volume descriptor whose pp_count exceeds the fixed ppe array size of 1016 entries.
3. Cause the target Linux system to scan the image or device, for example through loop-device partition scanning, udev-driven device discovery, virtualization import, or forensic/image-processing automation.
4. Trigger the kernel partition parser path that reaches the AIX partition handler during block-device discovery.
5. Force an out-of-bounds read past the allocated descriptor, potentially causing a kernel oops, panic, or diagnostic memory exposure.
6. Use the resulting crash or instability to disrupt services, or use any exposed diagnostic data to aid further local exploitation.

How to detect it

Look for evidence that a host scanned an untrusted or unusual block image shortly before a kernel oops, panic, KASAN report, or unexpected reboot. Relevant sources include kernel ring buffer logs, journald kernel records, syslog, auditd process execution logs, udev events, EDR telemetry, crash dump metadata, and virtualization or image-processing service logs. Focus on sequences involving loop-device creation or partition scanning followed by messages referencing AIX partition parsing, msdos partition probing, slab out-of-bounds reads, general protection faults, kernel NULL/invalid memory access, or panic. Also review use of losetup with partition scanning options, qemu/guest tooling, forensic image tools, removable-media insertion, and automated import pipelines. Because exploitation may only produce a crash and not a durable file artifact, absence of a specific IOC does not rule out attempted exploitation.

• aix_partition
• msdos_partition
• BUG: KASAN: slab-out-of-bounds
• KASAN: slab-out-of-bounds
• Read of size 2
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• unable to handle kernel paging request
• losetup -P
• LOOP_SET_STATUS
• /dev/loop
• /proc/partitions
• udevd
• systemd-udevd

What your security team should do

• Inventory Linux systems that process untrusted disk images, removable media, VM images, forensic images, or user-supplied block-device content, and prioritize them for patching.
• Apply vendor kernel updates containing the bounds-check fix and reboot affected systems to activate the patched kernel.
• Restrict local privileges required to create loop devices, attach raw block devices, or invoke partition scanning; remove these capabilities from untrusted workloads.
• Run disk-image inspection workflows in isolated, disposable environments with crash containment and no access to sensitive host workloads.
• Monitor kernel logs and crash telemetry for AIX partition parsing, KASAN slab-out-of-bounds reports, and oops/panic events following loop-device or removable-media attachment.
• If suspicious crashes are observed, preserve the triggering image/device metadata, kernel logs, and crash dumps for forensic analysis.
• Track vendor advisories for exact fixed kernel package versions because no affected product list or per-package fixed versions were provided in the input.