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