CVE-2026-89085: Parted: parted: heap-based buffer overflow via crafted fat32 filesystem image

AIONLYREPORT package: parted-3.6-7.el10 ------ Summary: Heap Buffer Overflow in FAT Resize/Open Path (initfats / fattableread) via Integer Truncation: a crafted FAT32 image can declare a FAT large enough to truncate the computed table allocation size, after which the full on-disk FAT is read into the undersized heap buffer. Requirements to exploit: An attacker must supply a crafted FAT32 filesystem image or block device and have it opened through the libparted-fs-resize FAT open path on a non-DEBUG build. Reachability also depends on using a backing geometry large enough for the declared FAT length to be accepted and read. Component affected: parted-3.6-7.el10; FAT resize/open path in libparted-fs-resize, specifically initfats and fattableread Version affected: parted-3.6-7.el10; reachable when the FAT resize/open path is used to open attacker-controlled FAT32 media or images on non-DEBUG builds Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H - 7.1 (HIGH) AV:L - The attacker supplies a local disk image or removable media rather than exploiting a network-reachable service. AC:L - The malformed FAT metadata is straightforward to construct once the vulnerable code path is known. PR:N - No privileges are required to create or provide the crafted filesystem. UI:R - A user or consuming application must open or inspect the crafted filesystem through the affected path. S:U - The corruption occurs within the privileges and security scope of the consuming process. C:L - Memory corruption may expose limited process memory, but broader confidentiality impact is not established from the available evidence. I:L - Memory corruption may permit limited in-process data corruption, but stronger integrity impact is not demonstrated here. A:H - The available evidence supports a reliable crash or other severe availability impact when the oversized FAT is read. Impact: Moderate. This is a real heap overflow in a filesystem parsing path, but the attack vector is local and user-assisted, and exploitation depends on the libparted-fs-resize FAT open path being exercised against attacker-controlled media. The available evidence firmly supports denial of service and heap corruption; broader compromise is plausible but not demonstrated. That combination is more consistent with Red Hat's Moderate classification than Important or Critical. Embargo: no Reason: The issue is local, requires user interaction or an application opening crafted media, and affects a specific parser path rather than a default remote service. Public remediation without embargo is proportionate. Acknowledgement: Aisle Research Vulnerability Details: In the FAT resize/open path, the computed FAT table size is derived from attacker-controlled on-disk metadata and stored in a 32-bit FatCluster without a bounds check. For FAT32, fsinfo->fatsectors comes from the boot sector fatlength field: c / libparted/fs/r/fat/bootsector.c / fsinfo->fatsectors = PEDLE32TOCPU (bs->u.fat32.fatlength) fsinfo->logicalsectorsize;

That value is then used to compute the FAT table allocation in initfats: c / libparted/fs/r/fat/fat.c / static int initfats (PedFileSystem fs) { FatSpecific fsinfo = FATSPECIFIC (fs); FatCluster tablesize; tablesize = fsinfo->fatsectors 512 / fattableentrysize (fsinfo->fattype); fsinfo->fat = fattablenew (fsinfo->fattype, tablesize); ... if (!fattableread (fsinfo->fat, fs, 0)) ... } Later, fattableread reads fsinfo->fatsectors sectors into the allocated table buffer. The only size check shown in the affected path is a PEDASSERT, which is not a runtime protection in non-DEBUG builds: c / libparted/fs/r/fat/table.c / PEDASSERT (ft->rawsize >= fsinfo->fatsectors 512); if (!pedgeometryread (fs->geom, (void ) ft->table, fsinfo->fatoffset + tablenum fsinfo->fatsectors, fsinfo->fatsectors)) return 0; The result is an undersized-allocation plus oversized-read condition. When the computed table size truncates during assignment to FatCluster, fattablenew() can allocate a smaller heap buffer than fattableread() later fills. In the observed path, this is reachable when the filesystem is opened through pedfilesystemopen() into fatopen(), which in turn calls initfats() and then fattableread(). Steps to reproduce: 1. Build the affected code in a non-DEBUG configuration with ASan or another memory safety checker. 2. Create a sufficiently large sparse disk image or backing geometry so FAT32 probe/open checks can succeed. 3. Craft a FAT32 boot sector with valid signature and required fields, and set u.fat32.fatlength = 0x02000000. 4. Trigger pedfilesystemopen() on that geometry so execution reaches fatopen(), initfats(), and then fattableread(). 5. Observe that the allocation size is derived from truncated 32-bit tablesize, while the read size still uses the full fsinfo->fatsectors value. 6. Under ASan, expect a heap out-of-bounds report during FAT table loading. Mitigation: Until a fix is available, avoid opening untrusted FAT32 media or disk images through the libparted-fs-resize FAT open path. If such parsing is required, isolate it in a sandboxed helper process and reject filesystems whose declared FAT length is implausibly large before passing them to this code. Proposed Fix: Add explicit range checks before converting the computed FAT size to FatCluster, and replace the PEDASSERT-only buffer size check in fattableread with a runtime error path. diff diff --git a/libparted/fs/r/fat/fat.c b/libparted/fs/r/fat/fat.c @@ -141,9 +141,22 @@ initfats (PedFileSystem fs) { FatSpecific fsinfo = FATSPECIFIC (fs); FatCluster tablesize; + uint64t fatbytes; + uint64t tablesize64; + int entrysize; tablesize = fsinfo->fatsectors 512

/ fattableentrysize (fsinfo->fattype); + entrysize = fattableentrysize (fsinfo->fattype); + fatbytes = (uint64t) fsinfo->fatsectors 512ULL; + tablesize64 = fatbytes / (uint64t) entrysize; + if (tablesize64 > UINT32MAX) { + pedexceptionthrow (PEDEXCEPTIONERROR, PEDEXCEPTIONCANCEL, + ("FAT table is too large.")); + return 0; + } + tablesize = (FatCluster) tablesize64; + fsinfo->fat = fattablenew (fsinfo->fattype, tablesize); if (!fsinfo->fat) goto error; diff --git a/libparted/fs/r/fat/table.c b/libparted/fs/r/fat/table.c @@ -121,7 +121,13 @@ fattableread (FatTable ft, const PedFileSystem fs, int tablenum) { FatSpecific fsinfo = FATSPECIFIC (fs); + uint64t need = (uint64t) fsinfo->fatsectors 512ULL;

PEDASSERT (ft->rawsize >= fsinfo->fatsectors 512); + if ((uint64t) ft->rawsize < need) { + pedexceptionthrow (PEDEXCEPTIONERROR, PEDEXCEPTIONCANCEL, + ("FAT table buffer smaller than on-disk FAT.")); + return 0; + }

memset (ft->table, 0, ft->rawsize); ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat