In the Linux kernel, the following vulnerability has been resolved:
smb: client: resolve SWN tcon from live registrations
cifsswnnotify() looks up a witness registration by id under cifsswnregidrmutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifsgetswnreg() lets multiple tcons for the same net/share name share one registration id.
A same-share second mount can keep the cifsswnreg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tclock or incrementing tccount through swnreg->tcon only moves the use-after-free earlier. Taking tclock while holding cifsswnregidrmutex also violates the documented CIFS lock order.
Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifsswnregidrmutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifstcpseslock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done.
Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifsswnunregister() while the registration is still protected by cifsswnregidr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings.
This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENTMOVE ordering for the representative tcon because the old-IP unregister is sent before cifsswn_register() sends the new-IP register.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64401.json"
}