CVE-2026-93231 in Linux
Zusammenfassung
von VulDB • 24.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
lockd: Vertauschte Argumente in nlmsvc_match_ip() korrigiert
Beim Freigeben von Sperren über die Server-IP-Adresse mittels /proc/fs/nfsd/unlock_ip ruft nlmsvc_unlock_all_by_ip() nlm_traverse_files() mit der Server-Socketadresse als undurchsichtigem @data-Argument auf:
nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL);
Der Match-Callback wird später aus nlm_traverse_locks() wie folgt aufgerufen:
match(lockhost, host);
wobei das erste Argument der nlm_host ist, dem die Sperre gehört, und das zweite Argument das ursprünglich übergebene @data (hier die Server-Socketadresse) darstellt. Dies entspricht der Konvention, von der jeder andere Match-Callback abhängt (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 ist der eigentliche nlm_host, arg2 ist der vom Aufrufer bereitgestellte Referenzwert.
Die beiden Argumente in nlmsvc_match_ip() waren seit Einführung der Unlock-by-IP-Funktion im Commit 4373ea84c84d („lockd: unlock lockd locks associated with a given server ip") vertauscht:
return rpc_cmp_addr(nlm_srcaddr(host), datap);
Hierbei ist @host tatsächlich die Server-Socketadresse, sodass nlm_srcaddr(host) eine struct sockaddr als struct nlm_host dereferenziert und an der Position von h_srcaddr Müllwerte liest; gleichzeitig wird bei @datap eigentlich der nlm_host des Sperreninhabers behandelt, jedoch wie ein sockaddr verglichen. Infolgedessen stimmt der Vergleich praktisch nie überein, und die Sperren werden für die angeforderte IP-Adresse nicht freigegeben.
Die Argumente wurden getauscht, sodass die Quelladresse des Sperreninhabers mit der angeforderten Serveradresse verglichen wird:
return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host);
[ cel: auch die irreführenden typedef-Parameternamen korrigiert ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.