In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix server re-repick on subrequest retry
When a subrequest is marked for needing retry, netfs will call cifspreparewrite() which will make cifs repick the server for the op before renegotiating credits; it then calls cifsissuewrite() which invokes smb2asyncwritev() - which re-repicks the server.
If a different server is then selected, this causes the increment of server->in_flight to happen against one record and the decrement to happen against another, leading to misaccounting.
Fix this by just removing the repick code in smb2asyncwritev(). As this is only called from netfslib-driven code, cifspreparewrite() should always have been called first, and so server should never be NULL and the preparatory step is repeated in the event that we do a retry.
The problem manifests as a warning looking something like:
WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2addcredits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2addcredits+0x3f0/0x9e0 [cifs] ... smb2writevcallback+0x334/0x560 [cifs] cifsdemultiplexthread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 retfromfork+0x34/0x60 retfromfork_asm+0x1a/0x30
Which may be triggered by a number of different xfstests running against an Azure server in multichannel mode. generic/249 seems the most repeatable, but generic/215, generic/249 and generic/308 may also show it.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/42xxx/CVE-2024-42256.json"
}