In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
IntheLinux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen asubrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() -which re-repicks the server.If adifferent server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in the event that we do aretry.The problem manifests as awarning looking something like: WARNING: CPU: 4PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by anumber of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhena subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev()- which re-repicks the server.Ifa different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory step is repeated in theevent that we doa retry.The problem manifests asa warning looking something like: WARNING: CPU:4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered bya number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
| linux | | https://git.kernel.org/linus/de40579b903883274fe203865f29d66b168b7236 | https://git.kernel.org/linus/3ee1a1fc39819906f04d6c62c180e760cd3a689d | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.The Linux kernel CVE team has assigned CVE-2024-42256 to this issue.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
In the Linux kernel, the following vulnerability has been resolved:cifs: Fix server re-repick on subrequest retryWhen a subrequest is marked for needing retry, netfs will callcifs_prepare_write() which will make cifs repick the server for the opbefore renegotiating credits; it then calls cifs_issue_write() whichinvokes smb2_async_writev() - which re-repicks the server.If a different server is then selected, this causes the increment ofserver->in_flight to happen against one record and the decrement to happenagainst another, leading to misaccounting.Fix this by just removing the repick code in smb2_async_writev(). As thisis only called from netfslib-driven code, cifs_prepare_write() shouldalways have been called first, and so server should never be NULL and thepreparatory 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 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Which may be triggered by a number of different xfstests running against anAzure server in multichannel mode. generic/249 seems the most repeatable,but generic/215, generic/249 and generic/308 may also show it.
