CVE-2026-64318: partitions: aix: bound the pp_count scan to the ppe array
In the Linux kernel, the following vulnerability has been resolved:
partitions: aix: bound the ppcount scan to the ppe array
aixpartition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array:
int numpps = be16tocpu(pvd->ppcount); ... for (i = 0; i < numpps; i += 1) { struct ppe p = pvd->ppe + i; ... lpix = be16tocpu(p->lpix);
pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAYSIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk ppcount. ppcount is an unvalidated be16 read straight from the descriptor, so a crafted AIX image with ppcount larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds).
The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdospartition() -> aixpartition().
Clamp the scan to the number of entries the ppe[] array can hold.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel so that the partition scan bounds the AIX pp_count scan to the ppe array capacity (fixed ARRAY_SIZE(pvd->ppe) = 1016) instead of iterating up to the unvalidated on-disk pp_count value (up to 65535).
Linux kernel AIX partition scanner (aix_partition/msdos_partition) pp_count scan bounds = Clamp the loop upper bound to ARRAY_SIZE(pvd->ppe) (1016) so the scan does not read pvd->ppe[i] past the end of the allocation
Event History
Frequently Asked Questions
Who can trigger this issue in practice?
A local attacker who can cause the system to scan an attacker-controlled block-device image or device with a crafted AIX/IBM partition table can trigger it. The described paths include attaching an image with losetup -P and devices automatically scanned by udev.
Is mounting the crafted filesystem required?
No. The vulnerable partition scan occurs before mounting, when the block device is scanned through msdos_partition() and then aix_partition().
What makes the crafted partition table malicious?
Its on-disk pp_count value is set above the fixed ppe[] array capacity of 1016 entries. The vulnerable code trusts that value and can read beyond the allocated partition descriptor structure.
What is the immediate mitigation if a fix cannot be applied?
Avoid attaching or allowing automatic scanning of untrusted block devices or disk images that could contain crafted AIX/IBM partition tables. In particular, do not use losetup -P on untrusted images.