diff options
| author | Ewan D. Milne <emilne@redhat.com> | 2020-07-29 19:10:11 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2020-08-21 13:15:14 +0200 |
| commit | ff1345a6663d9527e01aa808ff1f7ff50bc5235d (patch) | |
| tree | e6bca3ba95e62458f5bb7264f03eaed09be53c42 /fs/block_dev.c | |
| parent | 3fb06144f4af11493797c7d48328dbcd6af123a5 (diff) | |
| download | linux-stable-ff1345a6663d9527e01aa808ff1f7ff50bc5235d.tar.gz linux-stable-ff1345a6663d9527e01aa808ff1f7ff50bc5235d.tar.bz2 linux-stable-ff1345a6663d9527e01aa808ff1f7ff50bc5235d.zip | |
scsi: lpfc: nvmet: Avoid hang / use-after-free again when destroying targetport
[ Upstream commit af6de8c60fe9433afa73cea6fcccdccd98ad3e5e ]
We cannot wait on a completion object in the lpfc_nvme_targetport structure
in the _destroy_targetport() code path because the NVMe/fc transport will
free that structure immediately after the .targetport_delete() callback.
This results in a use-after-free, and a crash if slub_debug=FZPU is
enabled.
An earlier fix put put the completion on the stack, but commit 2a0fb340fcc8
("scsi: lpfc: Correct localport timeout duration error") subsequently
changed the code to reference the completion through a pointer in the
object rather than the local stack variable. Fix this by using the stack
variable directly.
Link: https://lore.kernel.org/r/20200729231011.13240-1-emilne@redhat.com
Fixes: 2a0fb340fcc8 ("scsi: lpfc: Correct localport timeout duration error")
Reviewed-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/block_dev.c')
0 files changed, 0 insertions, 0 deletions