CVE-2026-89088: Parted: parted: denial of service via heap buffer overflow during fat16 resize

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

— Red Hat