Vulnerabilità del kernel Linux CVE-2026-98432: blocco temporaneo e applicazione della patch del kernel

CVE-2026-98432 è una vulnerabilità del kernel Linux in cui il codice del kernel che accetta le connessioni TCP IPv4 rilegge memoria già liberata; il team CVE del kernel Linux l'ha classificata come Critical. Poiché la falla si può attaccare da remoto senza autenticazione, abbiamo aggiornato un server Lightsail con AlmaLinux 9.8, Nginx e Apache ai pacchetti del kernel corretto, lo abbiamo riavviato e poi abbiamo verificato la patch dalla versione del kernel in esecuzione.

1️⃣ Vulnerabilità del kernel Linux CVE-2026-98432: come funziona la falla e cosa colpisce

Quando arriva una richiesta di connessione TCP (SYN) con opzioni IPv4, il kernel conserva una copia di quelle opzioni insieme alla connessione in attesa, per rimandarle nella sua risposta (SYN-ACK). Quando la connessione si stabilisce, questa copia passa così com'è al socket della nuova connessione, senza essere duplicata.

Se nel frattempo il client rimanda il SYN, un'altra CPU potrebbe star costruendo un SYN-ACK con le stesse opzioni. Se in quel momento la nuova connessione si chiude e il kernel libera subito la memoria delle opzioni, il codice che costruiva il SYN-ACK legge memoria già liberata: un use-after-free.

Questo codice gira mentre il kernel elabora la richiesta di connessione, prima che l'applicazione veda la connessione. Per questo, qualunque sia il servizio che ha aperto la porta, se è in ascolto su TCP IPv4 un attacco può raggiungerla da remoto senza credenziali, e il punteggio è 9.8 secondo CVSS 3.1.

La falla esiste da Linux 4.4, quindi riguarda la maggior parte dei server Linux. Tra i blueprint di Lightsail, la guida di AWS cita AlmaLinux 9, CentOS Stream 9, Debian, openSUSE Leap, Ubuntu, Amazon Linux 2 e Amazon Linux 2023. L'annuncio di AlmaLinux include le versioni 8, 9 e 10, e anche i blueprint di applicazioni di Lightsail come WordPress e LAMP girano su Debian o Ubuntu, quindi sono coinvolti allo stesso modo.

FreeBSD e Windows Server, che non usano il kernel Linux, restano esclusi.

Anche i server con MPTCP (Multipath TCP) disattivato hanno bisogno della patch. L'attacco pubblicato mirava ai server con un listener MPTCP aperto, ma la falla in sé è nel normale codice TCP IPv4; per questo anche l'annuncio di AlmaLinux dice che vanno corretti pure i sistemi senza MPTCP.

Il kernel corretto libera la memoria delle opzioni solo dopo che è trascorso un periodo di grazia RCU (grace period), così la memoria resta al suo posto mentre un'altra CPU legge le opzioni per costruire un SYN-ACK.

2️⃣ Verificare la versione del kernel Linux: il kernel è corretto?

La necessità della patch dipende dalla versione del kernel in esecuzione, quindi prima di aggiornare abbiamo controllato la distribuzione e la versione del kernel.

cat /etc/os-release

NAME="AlmaLinux"
VERSION="9.8 (Olive Jaguar)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.8"
SUPPORT_END=2032-06-01

uname -r

5.14.0-687.55.1.el9_8.x86_64

nft --version

-bash: nft: command not found

La distribuzione era AlmaLinux 9.8 e il kernel in esecuzione era 5.14.0-687.55.1.el9_8. Mancava anche il comando nft usato dalla regola di blocco temporanea, quindi il pacchetto nftables non era installato.

rpm -q kernel

kernel-5.14.0-611.30.1.el9_7.x86_64
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64

[rpm -q kernel] mostra l'elenco dei kernel installati, ma fino al riavvio l'unico che gira davvero è quello indicato da [uname -r]. Confronta questa versione con la versione corretta riportata da AlmaLinux nel suo annuncio.

5.14.0-687.55.1.el9_8 era inferiore a 5.14.0-687.64.1.el9_8, la versione corretta per AlmaLinux 9, quindi andava aggiornato.

Per vedere se l'attacco aveva una strada aperta, abbiamo controllato le porte TCP IPv4 in ascolto e lo stato di MPTCP.

ss -lnt4

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*

sysctl net.mptcp.enabled

net.mptcp.enabled = 0

ss -lnM

State Recv-Q Send-Q Local Address:Port Peer Address:Port

Le porte TCP IPv4 in ascolto su tutti gli indirizzi (0.0.0.0) erano la 80 e la 443 del server web e la 22 di SSH.

[net.mptcp.enabled] era 0 e non c'erano socket MPTCP, quindi la via MPTCP usata dall'attacco pubblicato era chiusa. La falla però parte dalle normali connessioni TCP IPv4, quindi un server in ascolto su tre porte IPv4 ha comunque bisogno della patch.

3️⃣ Aggiornamento del kernel Linux: sette pacchetti del kernel e un riavvio

Prima di cambiare kernel abbiamo creato uno snapshot manuale dell'istanza nella console di Lightsail. Lightsail non ha una schermata per scegliere il kernel di avvio; se il server non si avvia con il nuovo kernel, lo ripristini creando una nuova istanza da questo snapshot.

🔲 Simulatore di snapshot di Lightsail

🔲 Verificare l'aggiornamento del kernel Linux e il riavvio

Abbiamo controllato con un elenco dnf la versione del kernel corretto pubblicata nel repository.

dnf --showduplicates list available kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs kernel-headers

kernel.x86_64                 5.14.0-687.64.1.el9_8   baseos
kernel-core.x86_64            5.14.0-687.64.1.el9_8   baseos
kernel-modules.x86_64         5.14.0-687.64.1.el9_8   baseos
kernel-modules-core.x86_64    5.14.0-687.64.1.el9_8   baseos
kernel-tools.x86_64           5.14.0-687.64.1.el9_8   baseos
kernel-tools-libs.x86_64      5.14.0-687.64.1.el9_8   baseos
kernel-headers.x86_64         5.14.0-687.64.1.el9_8   appstream

dnf download kernel-core-5.14.0-687.64.1.el9_8

Scarica nella cartella corrente solo il file del pacchetto kernel-core, senza installarlo.

rpm -Kv kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm

    V4 RSA/SHA256 Signature, key ID b86b3716: OK

rpm -qp --changelog kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm | grep CVE-2026-98432

- ipv4: free inet_opt and ireq_opt after an RCU grace period (CKI Backport Bot) [RHEL-295635] {CVE-2026-98432}

La firma era OK e nel changelog c'era una riga che corregge CVE-2026-98432. Negli avvisi di sicurezza di dnf (updateinfo) che abbiamo controllato il 3 novembre questo CVE non c'era ancora, quindi con [dnf upgrade --security] non si poteva ottenere questo kernel.

Per questo abbiamo installato i sette pacchetti del kernel indicando anche la versione.

dnf install -y kernel-5.14.0-687.64.1.el9_8 kernel-core-5.14.0-687.64.1.el9_8 kernel-modules-5.14.0-687.64.1.el9_8 kernel-modules-core-5.14.0-687.64.1.el9_8 kernel-tools-5.14.0-687.64.1.el9_8 kernel-tools-libs-5.14.0-687.64.1.el9_8 kernel-headers-5.14.0-687.64.1.el9_8

================================================================================
 Package                Architecture Version                    Repository    Size
================================================================================
Installing:
 kernel                 x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
 kernel-core            x86_64    5.14.0-687.64.1.el9_8      baseos        17 M
 kernel-modules         x86_64    5.14.0-687.64.1.el9_8      baseos        40 M
 kernel-modules-core    x86_64    5.14.0-687.64.1.el9_8      baseos        31 M
Upgrading:
 kernel-headers         x86_64    5.14.0-687.64.1.el9_8      appstream    2.6 M
 kernel-tools           x86_64    5.14.0-687.64.1.el9_8      baseos       1.3 M
 kernel-tools-libs      x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
Removing:
 kernel                 x86_64    5.14.0-611.30.1.el9_7      @baseos        0
 kernel-core            x86_64    5.14.0-611.30.1.el9_7      @baseos       64 M
 kernel-modules         x86_64    5.14.0-611.30.1.el9_7      @baseos       33 M
 kernel-modules-core    x86_64    5.14.0-611.30.1.el9_7      @baseos       27 M

Transaction Summary
================================================================================
Install  4 Packages
Upgrade  3 Packages
Remove  4 Packages

Total download size: 94 M

Complete!

Sono stati installati quattro nuovi pacchetti del kernel, aggiornati i tre pacchetti kernel-headers, kernel-tools e kernel-tools-libs, e nessun altro pacchetto è cambiato. Poiché l'impostazione [installonly_limit=3] conserva fino a tre kernel installati, sono stati rimossi i quattro pacchetti del più vecchio, 5.14.0-611.30.1.el9_7; dal download al completamento sono serviti 74 secondi.

Il comando ufficiale indicato nell'annuncio di AlmaLinux scarica di nuovo le informazioni dei repository e poi aggiorna tutti i pacchetti che hanno un aggiornamento.

sudo dnf clean metadata && sudo dnf upgrade

Poiché oltre al kernel vengono aggiornati anche altri pacchetti, i passaggi per aggiornare l'intera versione della distribuzione sono in Aggiornamento di Alma Linux: 9.4 → 9.8 su LightSail.

Il nuovo kernel si applica solo dopo il riavvio.

systemctl reboot

Dopo che il server si è riacceso, abbiamo controllato in ordine il kernel in esecuzione, i kernel installati e il kernel predefinito.

uname -r

5.14.0-687.64.1.el9_8.x86_64

rpm -q kernel

kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64
kernel-5.14.0-687.64.1.el9_8.x86_64

grubby --default-kernel

/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64

Il server si è riacceso in meno di un minuto dal comando di riavvio, e sia il kernel in esecuzione sia il kernel predefinito per il prossimo avvio sono passati a 5.14.0-687.64.1.el9_8. Il kernel precedente, 5.14.0-687.55.1.el9_8, è ancora presente: se il nuovo kernel dà problemi, puoi riportare indietro il kernel predefinito.

4️⃣ Blocco temporaneo prima del riavvio: regole nft e loro limiti

Se non puoi riavviare subito, puoi bloccare con una regola temporanea i pacchetti che fanno partire la falla finché non installi il kernel corretto. I comandi di questa sezione non li abbiamo eseguiti noi; seguono le indicazioni ufficiali (gli annunci di AlmaLinux e di AWS).

Sul server Lightsail con AlmaLinux 9.8, Nginx e Apache un riavvio richiede solo pochi minuti, quindi abbiamo aggiornato subito il kernel, senza blocco temporaneo.

La falla parte solo da richieste di connessione TCP con opzioni IPv4. Il traffico normale non usa quasi mai le opzioni IPv4, quindi bloccando solo i pacchetti TCP IPv4 con opzioni le connessioni abituali continuano a funzionare.

sudo dnf install -y nftables

Il comando nft fa parte del pacchetto nftables, che si installa insieme a firewalld. Se sul tuo server il comando manca, installalo prima.

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Crea una tabella che scarta nella fase prerouting i pacchetti TCP con lunghezza dell'intestazione IPv4 superiore a 5, cioè i pacchetti con opzioni IPv4. È una regola che AlmaLinux ha provato su 8, 9 e 10; si può usare insieme a firewalld ed è sicuro eseguirla più volte.

sudo nft list table ip cve_2026_98432

Controlla che la regola sia attiva; il valore counter nell'output è il numero di pacchetti bloccati finora.

sudo nft delete table ip cve_2026_98432

Dopo il riavvio con il kernel corretto, elimina la tabella con questo comando.

Questa regola sparisce al riavvio; se hai riavviato prima di installare il kernel corretto, esegui di nuovo il comando che crea la tabella.

Questa regola non va bene per server con applicazioni che si basano sulle opzioni IPv4. Un esempio sono le reti che usano le etichette di sicurezza CIPSO (NetLabel), trasportate nelle opzioni IPv4; nella configurazione predefinita non si usano.

La regola protegge l'host e i container che ricevono il traffico attraverso l'host (la modalità predefinita di Podman e Docker). Il traffico scambiato tra container dello stesso host può aggirare questa regola.

Su Debian, Ubuntu e openSUSE usa la regola iptables di una riga della guida di AWS. I kernel di AlmaLinux 9 e CentOS Stream 9 non hanno il match u32 usato da questa regola, quindi lì si usa la regola nft qui sopra.

sudo iptables -I INPUT 1 -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

L'espressione u32 legge il campo della lunghezza dell'intestazione IPv4; se il valore è maggiore di 5, il pacchetto porta opzioni IPv4. Dopo aver installato il kernel corretto, elimina questa regola con il comando qui sotto.

sudo iptables -D INPUT -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Chiudere nel firewall di Lightsail le porte che non usi e limitare le altre a indirizzi IP affidabili è un'altra misura consigliata dalla guida di AWS.

🔢 FAQ & contenuti consigliati

🔗 Contenuti consigliati

Altra risposta a un CVE: OpenSSH Vulnerabilità di OpenSSH CVE-2024-6387: blocco temporaneo e applicazione della patch La vulnerabilità di OpenSSH CVE-2024-6387 sfrutta il segnale di allarme che scatta quando chi si collega non completa l'accesso entro 120 secondi. Lo riassumiamo in questo ordine: spegnere l'allarme per chiudere il buco urgente, correggere il codice con un aggiornamento e poi annullare la modifica. Leggi l'articolo →

Versione del kernel Comandi per controllare la versione del kernel Linux e come controllare la versione della distribuzione Su Linux la versione del kernel si controlla con il comando uname. Gestione dei pacchetti Comando dnf: installare, aggiornare e rimuovere pacchetti e differenze con yum Il comando dnf è il comando di gestione dei pacchetti per cercare, installare, aggiornare e rimuovere pacchetti su Linux della famiglia RHEL. Vulnerabilità di PHP Vulnerabilità PHP: la patch PHP2Shell e come controllare la versione di PHP (WordPress) È una falla di esecuzione di codice da remoto che fa girare codice sul server anche con richieste senza accesso, quindi la prima cosa da fare è controllare la versione di PHP del tuo sito e portarla a una versione con patch.

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente ^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.