CVE-2026-53397 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
nfsd: correzione della perdita di memoria (leak) dell'oggetto posix_acl in caso di errore nella decodifica SETACL
Le funzioni nfsaclsvc_decode_setaclargs() e nfs3svc_decode_setaclargs() chiamano ciascuna due volte nfs_stream_decode_acl(), prima per NFS_ACL e poi per NFS_DFACL. Ogni chiamata riuscita trasferisce la proprietà di un oggetto posix_acl appena allocato ad argp->acl_access o a argp->acl_default. Se la prima chiamata ha successo ma la seconda fallisce, il decoder restituisce false e argp->acl_access rimane come puntatore pendente (dangling).
La funzione pc_release per ACLPROC2_SETACL era collegata a nfssvc_release_attrstat e quella per ACLPROC3_SETACL era collegata a nfs3svc_release_fhandle. Entrambe chiamano solo fh_put() e non hanno conoscenza dei campi ACL presenti in argp. Le coppie posix_acl_release() erano posizionate nelle etichette out: all'interno di nfsacld_proc_setacl() e nfsd3_proc_setacl(), ma svc_process() salta pc_func quando pc_decode restituisce false, rendendo tale pulizia irraggiungibile in caso di errore nella decodifica:
svc_process_common() pc_decode() /* decode_setaclargs: falso */ /* pc_func saltato */ pc_release() /* solo fh_put -- ACL persi (leaked) */
L'oggetto posix_acl orfano viene perso per tutta la durata del server.
La correzione consiste nell'aggiungere nfsaclsvc_release_setacl() e nfs3svc_release_setacl(), che rilasciano sia argp->acl_access che argp->acl_default, oltre a chiamare fh_put(), collegandole come pc_release per le rispettive procedure SETACL. Poiché pc_release viene eseguita su ogni percorso seguito da svc_process() dopo la decodifica, incluso in caso di errore nella decodifica, le coppie posix_acl_release() vengono rimosse dalle etichette out: delle funzioni proc per mantenere il controllo della proprietà in un unico punto. Questo approccio corrisponde al pattern release_getacl() esistente utilizzato dalle procedure GETACL correlate (sibling).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.