Un bug Linux poteva cancellare dati senza mostrare errori: esisteva dal 2023

Un singolo bit perso durante la gestione delle pagine di memoria può bastare per cancellare dati appena scritti senza produrre un crash, un errore I/O o un messaggio evidente nei log. È quanto accaduto nel kernel Linux per circa tre anni: un difetto nella gestione delle Transparent Huge Pages sui sistemi x86 poteva indurre il kernel a considerare eliminabile una porzione di memoria che un programma aveva inizialmente segnalato come non più necessaria tramite il flag MADV_FREE, ma che aveva poi modificato e quindi avrebbe dovuto essere nuovamente preservata.

Il problema, introdotto nel ciclo che portò a Linux 6.6 nel 2023, è emerso con chiarezza soltanto a settembre 2026, dopo casi reali di perdita di dati riscontrati anche da utenti della nota libreria analitica Polars.

La correzione è arrivata durante lo sviluppo di Linux 7.3, poco dopo la pubblicazione della release candidate 7.3-rc3. L’aspetto quasi paradossale è la sproporzione tra conseguenze e modifica necessaria: la patch tocca una sola riga del codice.

Come è stato scoperto il bug che porta alla perdita di dati su Linux

Il problema è stato segnalato da Orson Peters sulla mailing list linux-mm il 3 settembre 2026. Peters ha pubblicato anche un piccolo programma C capace di riprodurre la perdita dei dati su una macchina AWS c7a.8xlarge usando Linux 7.3-rc1.

Il test mette insieme deliberatamente le condizioni necessarie a far emergere il difetto. Il programma alloca memoria privata, cioè utilizzata soltanto dal processo e non condivisa con altri, e chiede al kernel di gestirla tramite Transparent Huge Pages, pagine di memoria più grandi delle normali pagine da 4 KB.

Successivamente usa MADV_FREE per indicare che quei dati possono essere scartati se il sistema ha bisogno di recuperare RAM, quindi li riscrive. A quel punto impone al processo un limite di memoria tramite cgroup e provoca nuove allocazioni, costringendo Linux ad avviare un’attività di reclaim, cioè il recupero delle pagine considerate sacrificabili. È proprio durante questa fase che il bug può indurre il kernel a eliminare anche dati che, essendo stati modificati dopo MADV_FREE, avrebbe dovuto conservare.

Perché basta perdere un solo bit per cancellare dati validi

Quando una pagina di memoria cambia, il processore imposta un indicatore chiamato dirty bit: serve, in sostanza, a ricordare al kernel che quel contenuto non può essere semplicemente ignorato.

Con le Transparent Huge Pages interessate dal bug, una particolare operazione sulle tabelle della memoria può far scomparire proprio quel bit. Linux finisce quindi per “dimenticare” che l’applicazione aveva riscritto i dati dopo MADV_FREE. Sotto pressione sulla RAM, il kernel poteva considerarli ancora eliminabili e recuperarne lo spazio.

La correzione proposta fa sì che il dirty bit non sia più escluso dalle informazioni che il kernel conserva durante l’aggiornamento della voce di memoria. Una variazione minima nel codice, ma sufficiente a impedire che dati validi siano scambiati per memoria di cui potersi sbarazzare.

Linus Torvalds porta la correzione nel kernel Linux 7.3

La patch ha seguito il percorso previsto per le correzioni urgenti del kernel. Dopo la revisione degli sviluppatori x86, è entrata nel ramo x86/urgent, quello utilizzato proprio per problemi che non possono attendere il normale ciclo di sviluppo.

Il fix è quindi arrivato nell’albero principale mantenuto da Linus Torvalds subito dopo Linux 7.3-rc3.

Linux 7.3 si trova ancora in fase release candidate, ma la gravità del problema giustifica l’inserimento immediato della patch invece di rimandarla al ciclo successivo. Una perdita silenziosa dei dati è infatti molto più difficile da individuare rispetto a un crash: il sistema può continuare a funzionare apparentemente senza problemi.

Non serve aspettare Linux 7.3 per ricevere la patch

Per amministratori e utenti il punto più importante è un altro: la correzione non resterà confinata a Linux 7.3. La patch contiene il tag Cc: stable@vger.kernel.org, utilizzato per indicare ai maintainer dei kernel stable che il fix deve essere valutato e riportato anche sulle altre versioni del kernel interessate dal difetto.

Poiché la regressione risale al codice entrato in Linux 6.6, le distribuzioni possono quindi integrare la modifica nei propri kernel tramite backport.

In pratica, un server che utilizza una versione precedente a Linux 7.3 potrà ricevere la correzione attraverso un normale aggiornamento del kernel distribuito da Debian, Ubuntu, Red Hat, SUSE, Arch o dagli altri vendor, senza dover passare alla nuova major release.

I sistemi da controllare con maggiore attenzione (la versione del kernel effettivamente in esecuzione è restituita dal comando uname -r) sono soprattutto server x86 con carichi che utilizzano molta RAM, container sottoposti a limiti cgroup, applicazioni analitiche e workload nei quali il kernel deve recuperare frequentemente memoria. Il caso Polars dimostra inoltre che non si tratta soltanto di una costruzione teorica: la perdita di dati è comparsa anche in ambienti reali.

Un normale PC desktop ha probabilità molto inferiori di incontrare esattamente quella combinazione. Ciò non significa però che l’aggiornamento sia facoltativo: quando la distribuzione renderà disponibile il kernel corretto, installarlo resta la scelta consigliata.