diff options
author | Sagi Grimberg <sagi@grimberg.me> | 2024-05-08 10:53:06 +0300 |
---|---|---|
committer | Keith Busch <kbusch@kernel.org> | 2024-05-08 16:17:01 +0300 |
commit | 73964c1d07c054376f1b32a62548571795159148 (patch) | |
tree | b9ccc62c03a9648009b65f66936e86f3be4fa2e6 /security/apparmor/mount.c | |
parent | d15dcd0f1a4753b57e66c64c8dc2a9779ff96aab (diff) | |
download | linux-73964c1d07c054376f1b32a62548571795159148.tar.xz |
nvmet-rdma: fix possible bad dereference when freeing rsps
It is possible that the host connected and saw a cm established
event and started sending nvme capsules on the qp, however the
ctrl did not yet see an established event. This is why the
rsp_wait_list exists (for async handling of these cmds, we move
them to a pending list).
Furthermore, it is possible that the ctrl cm times out, resulting
in a connect-error cm event. in this case we hit a bad deref [1]
because in nvmet_rdma_free_rsps we assume that all the responses
are in the free list.
We are freeing the cmds array anyways, so don't even bother to
remove the rsp from the free_list. It is also guaranteed that we
are not racing anything when we are releasing the queue so no
other context accessing this array should be running.
[1]:
--
Workqueue: nvmet-free-wq nvmet_rdma_free_queue_work [nvmet_rdma]
[...]
pc : nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma]
lr : nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma]
Call trace:
nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma]
nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma]
process_one_work+0x1ec/0x4a0
worker_thread+0x48/0x490
kthread+0x158/0x160
ret_from_fork+0x10/0x18
--
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Diffstat (limited to 'security/apparmor/mount.c')
0 files changed, 0 insertions, 0 deletions