CVE-2026-93231 in Linux
Riassunto
di VulDB • 24/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
lockd: correzione degli argomenti invertiti in nlmsvc_match_ip()
Quando si rilasciano i lock tramite l'indirizzo IP del server utilizzando /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() chiama nlm_traverse_files() passando il sockaddr del server come argomento @data opaco:
nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL);
La callback di match viene successivamente invocata da nlm_traverse_locks() come segue:
match(lockhost, host);
dove il primo argomento è l'nlm_host che possiede il lock e il secondo argomento è @data, passato originariamente (in questo caso il sockaddr del server). Questa è la convenzione su cui si basa ogni altra callback di match (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 è l'nlm_host reale, arg2 è il valore di riferimento fornito dal chiamante.
La funzione nlmsvc_match_ip() ha questi due argomenti invertiti fin dall'introduzione della funzionalità unlock-by-IP nel commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"):
return rpc_cmp_addr(nlm_srcaddr(host), datap);
Qui @host è in realtà il sockaddr del server, quindi nlm_srcaddr(host) dereferenzia una struct sockaddr come se fosse una struct nlm_host e legge dati spuri (garbage) all'offset di h_srcaddr; nel frattempo @datap è effettivamente l'nlm_host proprietario del lock ma viene confrontato come un sockaddr. Di conseguenza il confronto praticamente non corrisponde mai e i lock non vengono rilasciati per l'IP richiesto.
Scambiare gli argomenti in modo che l'indirizzo sorgente del proprietario del lock venga confrontato con l'indirizzo server richiesto:
return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host);
[ cel: correggere anche i nomi dei parametri typedef fuorvianti ]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.