A flaw was found in parted. A heap-based buffer overflow can occur when processing a specially crafted FAT32 filesystem due to an integer calculation error during buffer allocation. A local attacker could exploit this by enticing a user or automated service to open a malicious filesystem image, resulting in an application crash leading to a Denial of Service (DoS) or potential memory corruption.

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

A flaw was found in parted. A heap-based buffer overflow exists in libparted's file system resizing logic when handling FAT16 volumes. By convincing a user or administrator to resize a specially crafted FAT16 file system image with malformed directory metadata, an attacker can trigger an oversized read into a fixed-size memory buffer. This issue causes memory corruption, resulting in an application crash and a denial of service (DoS).

AIONLYREPORT package: parted-3.6-7.el10 ------ Summary: Heap Buffer Overflow in duplicatelegacyrootdir via Malformed BPB: a crafted FAT16 BPB direntries value can drive an oversized read into libparted's fixed heap buffer during a resize that remains on the FAT16 path. Requirements to exploit: Control over a FAT16 filesystem image or block device carrying a malicious BPB direntries value, plus a user or administrative tool that uses libparted from this SRPM to open and resize that image while remaining on the FAT16 to FAT16 path. Component affected: parted SRPM, libparted FAT resize logic in libparted/fs/r/fat/bootsector.c and libparted/fs/r/fat/resize.c, specifically duplicatelegacyrootdir Version affected: parted-3.6-7.el10 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:N/I:N/A:H - 5.5 (MEDIUM) AV:L - The attacker must supply a local crafted filesystem image or block device to software using libparted. AC:L - The overflow follows from a malformed BPB direntries value without additional race conditions or hard-to-meet preconditions. PR:N - No privileges are needed to create or provide the crafted image itself. UI:R - A user or administrative workflow must open the image and trigger a resize operation. S:U - The impact is confined to the component performing the resize. C:N - The available evidence does not show disclosure of data. I:N - The available evidence does not show controlled modification of data or state. A:H - The demonstrated outcome is a heap overflow leading to a reliable crash or denial of service during resize. Impact: Moderate. This issue does not fit Critical or Important because the available evidence supports only a local, user-assisted attack path and does not establish straightforward confidentiality or integrity compromise. It fits Moderate because a malformed filesystem image can still trigger a meaningful availability failure in a supported FAT resize code path under realistic administrative use. Embargo: no Reason: The currently supported impact is denial of service in a local resize workflow, exploitation requires attacker-controlled FAT16 media plus a resize action, and practical mitigation exists by avoiding resize of untrusted FAT16 images until bounds checks are added. Acknowledgement: Aisle Research Vulnerability Details: libparted allocates a fixed FAT buffer of 1024 sectors and later derives rootdirsectorcount for FAT16 directly from the untrusted BPB direntries field. That derived sector count is then used as the read length in duplicatelegacyrootdir without a corresponding check that it fits inside the fixed heap buffer. c // libparted/fs/r/fat/fat.h #define BUFFERSIZE 1024 c // libparted/fs/r/fat/fat.c fsinfo->buffersectors = BUFFERSIZE; fsinfo->buffer = pedmalloc (fsinfo->buffersectors 512); c // libparted/fs/r/fat/bootsector.c fsinfo->rootdirentrycount = PEDLE16TOCPU (bs->direntries); fsinfo->rootdirsectorcount = fsinfo->rootdirentrycount sizeof (FatDirEntry) / (512 fsinfo->logicalsectorsize); c // libparted/fs/r/fat/resize.c if (!pedgeometryread (ctx->oldfs->geom, oldfsinfo->buffer, oldfsinfo->rootdiroffset, oldfsinfo->rootdirsectorcount)) return 0; The available evidence shows that pedgeometryread() enforces geometry bounds, but not destination-buffer size. For a crafted FAT16 image with direntries=0xFFFF and 512-byte logical sectors (logicalsectorsize=1), rootdirsectorcount becomes 4095 sectors while the destination buffer holds only 1024 sectors. That creates an attempted overwrite of 3071 sectors, approximately 1.5 MiB, past the heap allocation. The demonstrated impact is a reliable crash during resize; broader confidentiality or integrity impact is not established from the current evidence. Steps to reproduce: 1. Build the package with AddressSanitizer enabled. 2. Create a FAT16 image and patch the BPB direntries field: bash dd if=/dev/zero of=fat16.img bs=1M count=64 mkfs.fat -F 16 fat16.img printf '\xff\xff' | dd of=fat16.img bs=1 seek=$((0x11)) conv=notrunc sudo losetup --find --show fat16.img # e.g. /dev/loop0 3. Run a minimal libparted harness that opens the filesystem and performs resize (pedfilesystemopen then pedfilesystemresize) while keeping the target type FAT16. 4. Observe an AddressSanitizer heap-buffer-overflow in duplicatelegacyrootdir during pedgeometryread(...). Mitigation: Avoid resizing untrusted FAT16 images or block devices with libparted until a bounds check is added. Where such media must be handled, reject BPB direntries values that would make rootdirsectorcount exceed the internal buffer before invoking the resize path. Proposed Fix: Add an explicit bounds check in duplicatelegacyrootdir before the read and write operations so the resize fails cleanly when the legacy root directory would exceed the internal buffer. As an additional hardening step, oversized direntries values can also be rejected earlier in fatbootsectoranalyse(). diff diff --git a/libparted/fs/r/fat/resize.c b/libparted/fs/r/fat/resize.c @@ -86,6 +86,16 @@ duplicatelegacyrootdir (FatOpContext ctx) PEDASSERT (oldfsinfo->rootdirsectorcount == newfsinfo->rootdirsectorcount); + if (oldfsinfo->rootdirsectorcount > oldfsinfo->buffersectors + || newfsinfo->rootdirsectorcount > oldfsinfo->buffersectors) { + pedexceptionthrow (PEDEXCEPTIONERROR, PEDEXCEPTIONCANCEL, + ("Legacy FAT root directory is too large for internal " + "buffer (%lld sectors > %lld)."), + (long long) oldfsinfo->rootdirsectorcount, + (long long) oldfsinfo->buffersectors); + return 0; + } + if (!pedgeometryread (ctx->oldfs->geom, oldfsinfo->buffer, oldfsinfo->rootdiroffset, oldfsinfo->rootdirsectorcount)) ------ This report was generated using AI technology. Always review AI-generated content prior to use