# Root Cause Analysis — CVE-2025-24985 ## Summary | Field | Value | |---|---| | **CVE** | CVE-2025-24985 | | **Binary** | fastfat.sys (Windows Fast FAT File System Driver) | | **Component** | FAT volume allocation support / cluster bitmap initialization | | **Bug Class** | Integer Overflow (CWE-190) leading to Kernel Pool Overflow | | **Impact** | Remote Code Execution / Elevation of Privilege | | **CVSS 3.1** | 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) | | **Exploited ITW** | Yes (CISA KEV) | | **Patch** | March 2025 Patch Tuesday (KB5053606 Win10 22H2) | ## Vulnerability Overview An integer overflow vulnerability exists in the Windows Fast FAT file system driver during cluster count computation when mounting a crafted FAT32 volume. The cluster count is computed from boot sector fields that are entirely user-controlled in a crafted VHD file. By setting specific values, the attacker produces a cluster count of 0xFFFFFFFB, which causes a second integer overflow when computing the bitmap allocation size: `(0xFFFFFFFB + 7) >> 3 = 0`. This results in a near-zero allocation (kernel minimum = 0x20 bytes) but a bitmap configured for 0xFFFFFFFB bits, leading to a massive kernel paged pool overflow with attacker-controlled bit patterns. ## Root Cause — Integer Overflow Chain ### Step 1: Crafted Boot Sector Values The attacker modifies the FAT32 boot sector (BPB) in a VHD file: | BPB Field | Normal Value | Crafted Value | Purpose | |---|---|---|---| | NumberOfSector32 | ~0x1F4000 | 0xFFFFFFFF | Maximize total sectors | | NumberOfFatTables | 2 | 2 | Keep standard | | SectorsPerFat32 | ~0xF80 | 0x80000000 | Maximize FAT size (causes subtraction overflow) | | ReservedSectors | ~32 | 4 | Minimize reserved | | SectorsPerCluster | ~8 | 1 | 1 sector = 1 cluster (no division reduction) | ### Step 2: Cluster Count Computation Overflow In `FatSetupAllocationSupport()`: ```c // Pre-patch: no overflow validation NumberOfClusters = (NumberOfSector32 - NumberOfFatTables * SectorsPerFat32 - ReservedSectors) / SectorsPerCluster; // With crafted values: // = (0xFFFFFFFF - 2 * 0x80000000 - 4) / 1 // = (0xFFFFFFFF - 0x100000000 - 4) / 1 ← 32-bit wrap! // = (0xFFFFFFFF - 0x00000000 - 4) / 1 ← 0x100000000 truncates to 0 // = 0xFFFFFFFB ``` The result `0xFFFFFFFB` is stored in the VCB (Volume Control Block) at offset `+0x15C` (`NumberOfClusters`). ### Step 3: FAT Type Check Bypass The overflow also bypasses the FAT type determination logic: ```c v35 = (NumberOfClusters + 0xFFFF); // = 0xFFFFFFFB + 0xFFFF = 0x1_0000FFFA // 32-bit truncation → 0x0000FFFA v_type = v35 >> 16; // = 0x0000FFFA >> 16 = 0 // *(a2 + 0xC8) = 0 → passes the "if (*(a2+0xC8) <= 1u)" check later ``` ### Step 4: Bitmap Allocation Overflow In `FatExamineFatEntries()`: ```c // NumberOfClusters = 0xFFFFFFFB from *(a2 + 0x15C) ULONG bitmapSize = (NumberOfClusters + 7) >> 3; // = (0xFFFFFFFB + 7) >> 3 // = 0x100000002 >> 3 ← 32-bit wrap! // = 0x00000002 >> 3 // = 0x00000000 PVOID bitmap = ExAllocatePoolWithTag(PagedPool, bitmapSize, 'tFaF'); // bitmapSize = 0 → kernel allocates minimum 0x20 bytes RtlInitializeBitMap(&bitmapHeader, bitmap, NumberOfClusters); // NumberOfBits = 0xFFFFFFFB but buffer is only 0x20 bytes! ``` ### Step 5: Kernel Pool Overflow The while loop in `FatExamineFatEntries()` iterates over all FAT entries (0xFFFFFFFB clusters) and calls `RtlSetBits`/`RtlClearBits` to track cluster allocation state changes: ```c while (1) { // ... read FAT entry for current cluster ... if (!previousState && currentState) { // free → used RtlClearBits(&bitmapHeader, startIndex, count); // WRITES BEYOND 0x20 bytes! } if (previousState && !currentState) { // used → free RtlSetBits(&bitmapHeader, startIndex, count); // WRITES BEYOND 0x20 bytes! } // ... } ``` Since each cluster maps to 1 bit, and the bitmap buffer is only 0x20 bytes (256 bits), any cluster index > 256 writes past the allocation into adjacent kernel pool objects. ### Attacker-Controlled Write Primitive The bit values written depend on the FAT entry values in the crafted VHD: - FAT entry = 0x00000000 → cluster is FREE → bit = 0 (RtlClearBits) - FAT entry != 0x00000000 → cluster is USED → bit = 1 (RtlSetBits) By crafting the FAT table entries, the attacker controls which bits are set or cleared in the overflowed region, achieving arbitrary byte writes to adjacent paged pool memory. ## Patch Analysis The patch adds overflow validation in both functions: ### FatSetupAllocationSupport (patched) ```c // Post-patch: validate cluster count computation won't overflow if (overflow_detected_in_cluster_computation) { return STATUS_DISK_CORRUPT_ERROR; } ``` ### FatExamineFatEntries (patched) ```c // Post-patch: validate (NumberOfClusters + 7) doesn't overflow ULONG v47 = *(a2 + 0x15C); // NumberOfClusters if (v47 + 7 < v47) { // overflow check return STATUS_DISK_CORRUPT_ERROR; } ULONG bitmapSize = (v47 + 7) >> 3; ``` ## Reachability - **Attack vector**: Local — requires user to mount a crafted VHD/VHDX or insert a crafted USB drive with a FAT32 partition - **Privileges required**: None — any user can mount a VHD by double-clicking - **User interaction**: Required — user must mount the crafted volume - **Attack surface**: - Double-click a .vhd or .vhdx file - Disk Management → Attach VHD - `diskpart` → `attach vdisk` - Insert USB drive with crafted FAT32 partition - Network share containing crafted VHD (social engineering) ## Detection ### YARA — Crafted FAT32 VHD with Overflow Boot Sector ```yara rule CVE_2025_24985_Crafted_FAT32_VHD { meta: description = "Detects VHD files with FAT32 boot sector values designed to overflow cluster count" cve = "CVE-2025-24985" author = "OnlyFm252" strings: // FAT32 signature at boot sector offset 0x52 $fat32_sig = "FAT32 " // SectorsPerFat32 = 0x80000000 (abnormally large) $large_spf = { 00 00 00 80 } // NumberOfSector32 = 0xFFFFFFFF $max_sectors = { FF FF FF FF } // VHD footer magic "conectix" $vhd_magic = "conectix" condition: ($fat32_sig and $large_spf and $max_sectors) or ($vhd_magic and $large_spf and $max_sectors) } ``` ### Sigma — VHD Mount Followed by BSOD ```yaml title: CVE-2025-24985 Crafted FAT32 VHD Mount id: e7f8a9b0-c1d2-3456-ef01-789012abcdef status: experimental description: > Detects mounting of VHD files followed by kernel crash, indicating possible exploitation of CVE-2025-24985 via crafted FAT32 volume. author: OnlyFm252 date: 2026/07/26 references: - https://hackyboiz.github.io/2025/07/17/ogu123/[Research]_CVE-2025-24985/EN/ - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24985 logsource: product: windows category: process_creation detection: selection_mount: CommandLine|contains: - 'attach vdisk' - 'Mount-VHD' - 'Mount-DiskImage' selection_file: CommandLine|contains: - '.vhd' - '.vhdx' condition: selection_mount and selection_file level: medium tags: - attack.execution - attack.t1203 - cve.2025.24985 ``` ### Sysmon Configuration ```xml .vhd .vhdx Mount-DiskImage attach vdisk Mount-VHD ``` ## References - [hackyboiz — CVE-2025-24985: Windows Fast FAT Driver RCE Vulnerability](https://hackyboiz.github.io/2025/07/17/ogu123/[Research]_CVE-2025-24985/EN/) - [MSRC Advisory — CVE-2025-24985](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24985) - [NVD — CVE-2025-24985](https://nvd.nist.gov/vuln/detail/CVE-2025-24985) - [CISA KEV — CVE-2025-24985](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)