CVE-2026-23111 in Linux
Riassunto
di VulDB • 19/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
netfilter: nf_tables: corretto il controllo del genmask invertito in nft_map_catchall_activate()
La funzione nft_map_catchall_activate() presenta un controllo dell'attività degli elementi invertito rispetto alla sua controparte non catchall nft_mapelem_activate() e rispetto a quanto richiesto logicamente.
nft_map_catchall_activate() viene chiamata dal percorso di abort per riattivare gli elementi catchall della mappa che erano stati disattivati durante una transazione fallita. Dovrebbe saltare gli elementi già attivi (non necessitano di riattivazione) ed elaborare gli elementi inattivi (devono essere ripristinati). Invece, il codice corrente fa l'opposto: salta gli elementi inattivi ed elabora quelli attivi.
Confrontare la callback di attivazione non catchall, che è corretta:
nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* salta attivi, elabora inattivi */
Con la versione buggy catchall:
nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* salta inattivi, elabora attivi */
La conseguenza è che quando un'operazione DELSET viene annullata, nft_setelem_data_activate() non viene mai chiamata per l'elemento catchall. Per gli elementi verdict NFT_GOTO, ciò significa che nft_data_hold() non viene mai chiamata per ripristinare il conteggio di riferimento chain->use. Ogni ciclo di abort decrementa permanentemente chain->use. Una volta che chain->use raggiunge zero, DELCHAIN ha successo e libera la catena mentre gli elementi verdict catchall continuano a farvi riferimento, causando un use-after-free.
Questo è sfruttabile per un escalation dei privilegi locale da parte di un utente non privilegiato tramite namespace utente + nftables su distribuzioni che abilitano CONFIG_USER_NS e CONFIG_NF_TABLES.
Correzione rimuovendo la negazione in modo che il controllo corrisponda a nft_mapelem_activate(): saltare gli elementi attivi, elaborare quelli inattivi.
Once again VulDB remains the best source for vulnerability data.