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

Reverse-engineering statico di un'immagine BIOS GIGABYTE H510M K V2 (H510MKV2.F3): analisi completa, tramite estrazione dei firmware volume UEFI, dell'allocatore di memoria del SMM Core di specifica PI e una ricerca mirata delle quattro vulnerabilità di corruzione della memoria SMM divulgate da GIGABYTE/Binarly nel 2025 (CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-7029).

Stato: 1 delle 4 CVE confermata presente (CVE-2025-7027). Le altre 3 sono state attivamente cercate nell'intero firmware accessibile e non trovate — vedi CVE non confermate per capire esattamente cosa questo significa e cosa non significa.

---

TUTTI I FILE DELLA RICERCA: DOWNLOAD GOOGLE DRIVE: SMM_ALL

Indice

• Disclaimer / ambito
• Target
• TL;DR
• Metodologia e strumenti
• Struttura del firmware
• Struttura del repository
• Contesto: le CVE pubbliche
• Scoperta bonus: l'allocatore di memoria SMM (PiSmmCore)
• Confermata: CVE-2025-7027
• CVE non confermate CVE-2025-7026 / 7028 / 7029
• Rimedi
• Limitazioni
• Riferimenti

---

Disclaimer / ambito

Questa è una ricerca n-day, non una divulgazione 0-day. Tutte e quattro le CVE qui menzionate erano già state divulgate pubblicamente e corrette da GIGABYTE (il firmware corretto ha iniziato a essere distribuito il 2025-06-12), con CVE assegnate e documentate da Binarly e CERT/CC prima dell'inizio di questa ricerca. Nulla in questo repository è una nuova scoperta di vulnerabilità — è una verifica indipendente tramite analisi statica per stabilire se le classi di bug precedentemente divulgate e corrette siano presenti in una specifica build BIOS scaricabile pubblicamente.

• Nessun exploit funzionante o PoC è incluso o è stato realizzato. Questa è solo analisi statica (disassemblaggio/decompilazione dei moduli firmware estratti); non è stato eseguito nulla, nessuna SMRAM è stata letta/scritta, nessun hardware è stato toccato.
• Nessuna nuova vulnerabilità viene rivendicata. La presenza di CVE-2025-7027 è confermata riscontrando il pattern di codice vulnerabile già descritto pubblicamente da Binarly, non scoprendolo in modo indipendente.
• Pubblicato per scopi educativi / di sicurezza difensiva: per capire come appaiono i bug firmware n-day nella pratica e per rafforzare la raccomandazione di aggiornamento di GIGABYTE con prove concrete per questa specifica scheda/revisione BIOS.
• Se possiedi questa scheda: aggiorna il BIOS. Vedi Rimedi.

Target

Scheda	GIGABYTE H510M K V2 (H510MKV2)
File BIOS	H510MKV2.F3
Dimensione file	16777216 bytes (16 MB)
Data file	2023-12-20
MD5	a9bca8aeb55061824af1c3eedfb5c846
SHA-256	934a935e5faba8d2cea4e1d51e9edb6aed86b32f412d0da5bae602bd9fd8f9f3
Chipset	Intel H510
Patch del vendor disponibile dal	2025-06-12 (questa build la precede di ~18 mesi)

TL;DR

• Estratto l'intero albero dei firmware volume UEFI dall'immagine BIOS (uefi_firmware / uefi-firmware-parser) — 356 file FFS enumerati nel volume SMM/DXE; 302 con un'immagine PE32/TE estraibile.
• Isolato e completamente reverse-engineered PiSmmCore (il SMM Core di specifica PI), confermando e dando un nome al vero allocatore di pool/pagine SMM (interni di SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages) tramite le sue firme di guardia hard-coded "sphd"/"tail" — una corrispondenza esatta con l'open-source MdeModulePkg/Core/PiSmmCore/Pool.c di EDK2.
• Cercati marker identificativi dagli advisory pubblici di Binarly sulle CVE-2025-7026/7027/7028/7029 in ogni modulo estraibile in ogni firmware volume trovato nella ROM (325+ moduli in totale).
• CVE-2025-7027 — confermata. Trovato e tracciato il percorso di codice vulnerabile esatto in GenericComponentSmmEntry: una variabile NVRAM (SetupXtuBufferAddress) viene letta tramite GetVariable() senza alcuna validazione e usata direttamente come puntatore di scrittura raggiungibile via SW SMI 0xB2 — corrisponde punto per punto alla descrizione pubblica della causa radice di Binarly.
• CVE-2025-7026 / -7028 / -7029 — non trovate nonostante una scansione esaustiva a livello di stringhe/byte dell'intero firmware accessibile. Questo viene riportato come risultato aperto e non conclusivo, non come un certificato di buona salute — vedi la sezione dedicata per capire perché e cosa servirebbe per una risposta reale.

Metodologia e strumenti

1. Estrazione — uefi_firmware (uefi-firmware-parser -e) ha decomposto ricorsivamente l'immagine BIOS: regioni Intel Flash Descriptor → firmware volume → file FFS → sezioni, decomprimendo ogni firmware volume compresso LZMA/Tiano trovato.
2. Isolamento dei moduli — ogni file FFS con una sezione .ui (nome visualizzato del driver) e una sezione immagine .pe/.te è stato copiato come binario PE32+/TE autonomo denominato <DriverName>__<GUID8>.<pe32|te>.
3. Analisi statica — IDA Pro (tramite l'interfaccia worker headless ida-pro-mcp / idalib) con il decompilatore Hex-Rays, un database per modulo. Solo auto-analisi + Hex-Rays — in questo ambiente non erano disponibili firme FLIRT né librerie di tipi EDK2 (segnalato come limitazione più avanti).
4. Ricerca marker — scansioni Python a livello di byte/stringhe su ogni modulo estratto (e sull'immagine grezza da 16 MB) alla ricerca degli identificatori citati negli advisory pubblici di Binarly (nomi di variabili, costanti magiche, etichette di funzioni).
5. Tracciamento manuale — per ogni riscontro di marker, la funzione che vi fa riferimento è stata decompilata e il suo grafo delle chiamate è stato percorso a mano (chiamanti/chiamate) per ricostruire il percorso di codice effettivo, incrociato con la descrizione pubblica della causa radice.
6. Rinomina — le funzioni confermate sono state rinominate nel loro database IDA per documentare il risultato direttamente nell'artefatto analizzabile, non solo in prosa.

Struttura del firmware

L'immagine BIOS contiene quattro regioni Intel Flash Descriptor; solo region-bios contiene codice GIGABYTE/OEM (region-me.fd region-gbe.fd region-pdr.fd sono firmware Intel Management Engine / GbE / descriptor — componenti separati, fuori ambito, non esplorati).

All'interno di region-bios sono stati trovati ed estratti quattro firmware volume:

Volume (GUID container FFS)	Contenuti	File estratti
file-9e21fd93-... → volume-ee4e5898-...	Volume principale dei driver DXE/SMM — tutti i driver Smm* e i driver DXE di piattaforma	302
file-f641ac56-... → volume-ee4e5898-...	Copia duplicata/di fase PEI del precedente (sottoinsieme più piccolo: PiSmmCommunicationPei IT8728FSmmFeaturesPei ecc.)	22
file-3417f275-... → volume-3417f275-...	Volume di early bring-up PEI/DXE (DxeIpl FspS3Notify ...)	21 (2 con immagini)
file-05ca020b-... → volume-05ca020b-...	Piccolo volume ausiliario senza immagini eseguibili	2

Tutti e quattro sono stati estratti e sottoposti a scansione dei marker (vedi CVE non confermate).

Struttura del repository