Описание
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.
A vulnerability was found in the Linux kernel's nvme driver. A lack of proper checks can lead to a race condition during the destruction of a queue pair when a controller is being established. This issue can lead to system instability or crashes.
Отчет
Within regulated environments, a combination of the following controls acts as a significant barrier to successfully exploiting a CWE-404: Improper Resource Shutdown or Release vulnerability and downgrades the severity of this particular CVE from Moderate to Low. The platform enforces hardening guidelines to apply the most restrictive settings necessary for operational requirements. Baseline configurations and system controls ensure secure software configurations, while least functionality reduces the attack surface and mitigates the risk of resource exhaustion from data leaks. The environment incorporates malicious code protections such as IDS/IPS and antimalware solutions to detect threats and provide real-time visibility into resource usage, reducing the likelihood of resource leaks that could cause system instability. Event logs are collected and analyzed for centralization, correlation, monitoring, alerting, and retention, supporting the detection of abnormal resource usage patterns. Static code analysis and peer reviews enforce strong input validation and error handling to minimize the risk of denial-of-service (DoS) attacks. Lastly, memory protection mechanisms such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) strengthen resilience against memory-related vulnerabilities.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Затронутые пакеты
Платформа | Пакет | Состояние | Рекомендация | Релиз |
---|---|---|---|---|
Red Hat Enterprise Linux 6 | kernel | Not affected | ||
Red Hat Enterprise Linux 7 | kernel | Out of support scope | ||
Red Hat Enterprise Linux 7 | kernel-rt | Out of support scope | ||
Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2024:7001 | 24.09.2024 |
Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2024:7000 | 24.09.2024 |
Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:5928 | 28.08.2024 |
Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:5928 | 28.08.2024 |
Red Hat Enterprise Linux 9.2 Extended Update Support | kernel | Fixed | RHSA-2024:8613 | 30.10.2024 |
Red Hat Enterprise Linux 9.2 Extended Update Support | kernel-rt | Fixed | RHSA-2024:8614 | 30.10.2024 |
Показывать по
Дополнительная информация
Статус:
4.4 Medium
CVSS3
Связанные уязвимости
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 i...
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
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In the Linux kernel, the following vulnerability has been resolved: n ...
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 referen...
4.4 Medium
CVSS3