GIGABYTE H510M K V2 BIOS SMM Reverse-Engineering & CVE-2025-7026/7027/7028/7029 Research

Static reverse-engineering of a GIGABYTE H510M K V2 (H510MKV2.F3) BIOS image: full UEFI firmware-volume extraction analysis of the PI-spec SMM Core memory allocator and a targeted hunt for the four SMM memory-corruption vulnerabilities GIGABYTE/Binarly disclosed in 2025 (CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-7029).

Status: 1 of 4 CVEs confirmed present (CVE-2025-7027). The other 3 were actively searched for across the entire accessible firmware and not found see Unconfirmed CVEs for exactly what that does and doesn't mean.

---

ALL FILES OF THE RESEARCH: GOOGLE DRIVE DOWNLAOAD: SMM_ALL

Table of contents

• Disclaimer / scope
• Target
• TL;DR
• Methodology & tooling
• Firmware layout
• Repository layout
• Background: the public CVEs
• Bonus finding: the SMM memory allocator (PiSmmCore)
• Confirmed: CVE-2025-7027
• Unconfirmed CVEs CVE-2025-7026 / 7028 / 7029
• Remediation
• Limitations
• References

---

Disclaimer / scope

This is n-day research not a 0-day disclosure. All four CVEs referenced here were already publicly disclosed and patched by GIGABYTE (patched firmware began shipping 2025-06-12) assigned CVEs and written up by Binarly and CERT/CC before this research began. Nothing in this repository is new vulnerability discovery it is an independent static-analysis verification of whether the previously-disclosed previously-patched bug classes are present in one specific publicly-downloadable BIOS build.

• No working exploit or PoC is included or was built. This is static-analysis-only (disassembly/decompilation of the extracted firmware modules); nothing was executed no SMRAM was read/written no hardware was touched.
• No new vulnerability is claimed. CVE-2025-7027's presence is confirmed by matching the vulnerable code pattern already described publicly by Binarly not by independently discovering it.
• Published for educational / defensive-security purposes: understanding how n-day firmware bugs look in practice and to reinforce GIGABYTE's own update recommendation with concrete evidence for this specific board/BIOS revision.
• If you have this board: update your BIOS. See Remediation.

Target

Board	GIGABYTE H510M K V2 (H510MKV2)
BIOS file	H510MKV2.F3
File size	16777216 bytes (16 MB)
File date	2023-12-20
MD5	a9bca8aeb55061824af1c3eedfb5c846
SHA-256	934a935e5faba8d2cea4e1d51e9edb6aed86b32f412d0da5bae602bd9fd8f9f3
Chipset	Intel H510
Vendor patch available since	2025-06-12 (this build predates it by ~18 months)

TL;DR

• Extracted the full UEFI firmware volume tree from the BIOS image (uefi_firmware / uefi-firmware-parser) 356 FFS files enumerated across the SMM/DXE volume 302 with an extractable PE32/TE image.
• Isolated and fully reverse-engineered PiSmmCore (the PI-spec SMM Core) confirming and naming the real SMM pool/page allocator (SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages internals) via its hard-coded "sphd"/"tail" guard signatures an exact match to EDK2's open-source MdeModulePkg/Core/PiSmmCore/Pool.c.
• Searched every extractable module in every firmware volume found in the ROM (325+ modules total) for identifying markers from Binarly's public CVE-2025-7026/7027/7028/7029 writeups.
• CVE-2025-7027 confirmed. Found and traced the exact vulnerable code path in GenericComponentSmmEntry: an NVRAM variable (SetupXtuBufferAddress) is fetched via GetVariable() with no validation and used directly as a write pointer reachable via SW SMI 0xB2 this matches Binarly's public root-cause description point for point.
• CVE-2025-7026 / -7028 / -7029 not found despite an exhaustive string/byte-level sweep of the entire accessible firmware. This is reported as an open inconclusive result not a clean bill of health see the dedicated section for why and what a real answer would require.

Methodology & tooling

1. Extraction uefi_firmware (uefi-firmware-parser -e) recursively unpacked the BIOS image: Intel Flash Descriptor regions → firmware volumes → FFS files → sections decompressing every LZMA/Tiano-compressed firmware volume it found.
2. Module isolation every FFS file with a .ui (driver display name) section and a .pe/.te image section was copied out as a standalone PE32+/TE binary named <DriverName>__<GUID8>.<pe32|te>.
3. Static analysis IDA Pro (via the ida-pro-mcp / idalib headless worker interface) with the Hex-Rays decompiler one database per module. Auto-analysis + Hex-Rays only no FLIRT signatures or EDK2 type libraries were available in this environment (noted as a limitation below).
4. Marker search Python byte/string scans across every extracted module (and the raw 16 MB image) for identifiers named in Binarly's public advisories (variable names magic constants function labels).
5. Manual tracing for every marker hit the referencing function was decompiled and its call graph walked (callers/callees) by hand to reconstruct the actual code path cross-checked against the public root-cause description.
6. Renaming confirmed functions were renamed in their IDA database to document the finding directly in the analyzable artifact not just in prose.

Firmware layout

The BIOS image contains four Intel Flash Descriptor regions; only region-bios contains GIGABYTE/OEM code (region-me.fd region-gbe.fd region-pdr.fd are Intel Management Engine / GbE / descriptor firmware separate components out of scope not explored).

Within region-bios four firmware volumes were found and extracted:

Volume (container FFS GUID)	Contents	Files extracted
file-9e21fd93-... → volume-ee4e5898-...	Main DXE/SMM driver volume all Smm* drivers platform DXE drivers	302
file-f641ac56-... → volume-ee4e5898-...	Duplicate/PEI-phase copy of the above (smaller subset: PiSmmCommunicationPei IT8728FSmmFeaturesPei etc.)	22
file-3417f275-... → volume-3417f275-...	Early PEI/DXE bring-up volume (DxeIpl FspS3Notify ...)	21 (2 with images)
file-05ca020b-... → volume-05ca020b-...	Small auxiliary volume no executable images	2

All four were extracted and marker-scanned (see Unconfirmed CVEs).

Repository layout