From: Danish Khateeb <danishkhateeb03@gmail.com>
To: "Martin K. Petersen" <mkp@kernel.org>
Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Akinobu Mita <akinobu.mita@gmail.com>,
Danish Khateeb <danishkhateeb03@gmail.com>
Subject: [PATCH 1/2] scsi: target: core: Fix kunmap_atomic() address in sbc_dif_copy_prot()
Date: Wed, 23 Sep 2026 08:13:18 -0500 [thread overview]
Message-ID: <20260923131319.310123-2-danishkhateeb03@gmail.com> (raw)
In-Reply-To: <20260923131319.310123-1-danishkhateeb03@gmail.com>
sbc_dif_copy_prot() copies protection information between the command's
protection SGL and the backend's SGL "sg". It maps each page of "sg" with
kmap_atomic() and unmaps it with kunmap_atomic(addr - sg->offset - offset).
The unmap runs after offset has been advanced by len, so it is passed an
address len bytes below the start of the mapped page, inside the page
below the mapping.
The only caller, rd_do_prot_rw(), passes the rd backend's protection
pages, which come from alloc_pages(GFP_KERNEL). kmap_atomic() of a lowmem
page returns its linear address, and kunmap_atomic() of a linear address
has nothing to unmap, so the wrong address has gone unnoticed. It matters
on 32-bit x86 with CONFIG_DEBUG_HIGHMEM, which selects
CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP so that lowmem pages get a real
temporary mapping too. kunmap_local_indexed() then warns
WARNING: mm/highmem.c:623 at kunmap_local_indexed+0x148/0x190
Workqueue: target_submission target_queued_submit_work
Call Trace:
sbc_dif_copy_prot+0xef/0x310
rd_do_prot_rw+0x115/0x140
rd_execute_rw+0x354/0x3b0
sbc_execute_rw+0x2b/0x40
__target_execute_cmd+0x22/0xb0
and clears the right PTE, but x86 flushes the TLB entry of the wrong
address. The stale entry keeps the slot pointing at the old page, so the
next page mapped there is not the one accessed. With an rd device with
pi_prot_type=1 exported through tcm_loop, reads and writes then fail
with "DIFv1 checksum failed" errors.
Unmap the page before advancing offset, so kunmap_atomic() gets the
address kmap_atomic() returned.
Fixes: 57636388af32 ("target: Fix inconsistent address passed to kunmap_atomic() in sbc_dif_copy_prot()")
Assisted-by: LLM
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
---
drivers/target/target_core_sbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 21f5cb86d70c..55a8c2f0a286 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -1347,13 +1347,13 @@ void sbc_dif_copy_prot(struct se_cmd *cmd, unsigned int sectors, bool read,
else
memcpy(addr, paddr + copied, len);
+ kunmap_atomic(addr - sg->offset - offset);
+
left -= len;
offset += len;
copied += len;
psg_len -= len;
- kunmap_atomic(addr - sg->offset - offset);
-
if (offset >= sg->length) {
sg = sg_next(sg);
offset = 0;
--
2.55.0
next prev parent reply other threads:[~2026-09-23 13:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 13:13 [PATCH 0/2] scsi: target: core: Fix and convert kmap_atomic() in SBC emulation Danish Khateeb
2026-09-23 13:13 ` Danish Khateeb [this message]
2026-09-23 13:13 ` [PATCH 2/2] scsi: target: core: Use kmap_local_page() " Danish Khateeb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923131319.310123-2-danishkhateeb03@gmail.com \
--to=danishkhateeb03@gmail.com \
--cc=akinobu.mita@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@kernel.org \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®