CVE-2026-98173: smb: client: fix use-after-free of iface in cifs_try_adding_channels()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of iface in cifstryaddingchannels()
cifstryaddingchannels() iterates ses->ifacelist with listforeachentrysafefrom(), which captures the next entry (niface) under ifacelock. The loop body then drops ifacelock for the whole duration of cifssesaddchannel().
A concurrent interface refresh (SMB3requestinterfaces() -> parseserverinterfaces()) marks all ifaces inactive and removes and frees any that are not re-advertised via listdel() + krefput(), where releaseiface() is a bare kfree(). Since niface typically has no channel holding a reference, the list reference is its last and it can be freed inside the unlocked window. On continue, the iterator advance step then dereferences niface->ifacehead.next, and the loop body reads iface->rdmacapable/isactive, both on freed memory.
Fix this by never keeping an unreferenced list pointer across the unlocked window. Each channel attempt now re-scans the list from the head under ifacelock, takes a kref on the selected candidate, and passes only that referenced candidate to cifssesaddchannel(). weightfulfilled still tracks selection progress, so restarting the scan preserves the original weighted distribution and the weightfulfilled-before-krefput ordering on the failure path.
Add a per-pass attempts cap so a flapping interface refresh cannot keep the inner loop spinning within a single tries increment.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update cifs_try_adding_channels() so each channel attempt selects a candidate while holding iface_lock, takes a kref before releasing the lock, keeps that reference for the entire cifs_ses_add_channel() call, and adds a per-pass attempts cap so a flapping interface refresh cannot keep the loop spinning.
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The affected SMB client must be attempting to add channels while a concurrent SMB3 interface refresh updates the server interface list. Exploitation also depends on the race occurring during the period when the interface-list lock is released for cifs_ses_add_channel().
Is an attacker required to have local access or credentials?
The CVSS vector identifies network reachability, no privileges, and user interaction as required. The supplied details do not specify what user action triggers the vulnerable SMB client behavior.
How can I tell whether a system has the fix?
The fix changes cifs_try_adding_channels() so that it re-scans the interface list while holding iface_lock and takes a kref on the selected interface before calling cifs_ses_add_channel(). The listed stable kernel references contain the corresponding fixes.