CVE-2026-52943

Riepilogo

Nel kernel Linux è stata risolta la seguente vulnerabilità: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() e pskb_carve_inside_nonlinear() copiano entrambe il vecchio header skb_shared_info in un nuovo buffer tramite memcpy(), che include il puntatore destructor_arg (uarg) per gli skb MSG_ZEROCOPY. Nessuna delle due funzioni chiama net_zcopy_get() per il nuovo shinfo, creando un detentore non contabilizzato: ogni skb_shared_info con destructor_arg impostato chiamerà skb_zcopy_clear() una volta quando viene liberato, ma il corrispondente net_zcopy_get() non è mai stato chiamato per la nuova copia. Chiamate ripetute portano uarg->refcnt a zero prematuramente, liberando ubuf_info_msgzc mentre gli skb TX mantengono ancora puntatori destructor_arg attivi. KASAN segnala use-after-free su un ubuf_info_msgzc liberato: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 Lo skb che consuma l'accesso tardivo faceva ancora riferimento allo stesso uarg tramite shinfo->destructor_arg copiato da pskb_carve_inside_nonlinear() senza un incremento del refcount. È stato verificato che questa vulnerabilità è sfruttabile in modo affidabile: una proof-of-concept funzionante raggiunge la piena escalation dei privilegi a root da un utente locale non privilegiato su una configurazione kernel predefinita. La correzione segue il modello di pskb_expand_head() che ha la stessa struttura memcpy/cloned. Per pskb_carve_inside_header(), net_zcopy_get() viene posizionato dopo che skb_orphan_frags() ha avuto successo, quindi il percorso di errore dell'orphan non richiede pulizia. Per pskb_carve_inside_nonlinear(), net_zcopy_get() viene posizionato dopo tutti i punti di errore e subito prima di skb_release_data(), quindi nessun percorso di errore richiede pulizia — avvicinandosi maggiormente a pskb_expand_head() ed evitando la necessità di un net_zcopy_put() di bilanciamento.