CVE-2024-42152

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a possible leak when destroy a ctrl during qp establishment<br /> <br /> In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we<br /> know that a ctrl was allocated (in the admin connect request handler)<br /> and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl<br /> (for nvme-loop primarily), and drop the final reference on the ctrl.<br /> <br /> However, a small window is possible where nvmet_sq_destroy starts (as<br /> a result of the client giving up and disconnecting) concurrently with<br /> the nvme admin connect cmd (which may be in an early stage). But *before*<br /> kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq<br /> live reference). In this case, sq-&gt;ctrl was allocated however after it was<br /> captured in a local variable in nvmet_sq_destroy.<br /> This prevented the final reference drop on the ctrl.<br /> <br /> Solve this by re-capturing the sq-&gt;ctrl after all inflight request has<br /> completed, where for sure sq-&gt;ctrl reference is final, and move forward<br /> based on that.<br /> <br /> This issue was observed in an environment with many hosts connecting<br /> multiple ctrls simoutanuosly, creating a delay in allocating a ctrl<br /> leading up to this race window.