From: sashiko-bot@kernel.org
To: "Sanan Hasanov" <sanan.hasanou@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 2/3] scsi: target: rd: Release protection space on allocation failure
Date: Fri, 09 Oct 2026 00:07:08 +0000 [thread overview]
Message-ID: <sashiko-outbox-164669@kernel.org> (raw)
In-Reply-To: <20261008235411.56641-3-sanan.hasanou@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] target: UAF in rd_build_prot_space() error path during concurrent configfs writes
--
commit d01a55deaeecc1f16dadcdc415bd1b576984c0da
Author: Sanan Hasanov <sanan.hasanov@ucf.edu>
scsi: target: rd: Release protection space on allocation failure
When rd_allocate_sgl_table() fails, rd_build_prot_space() returns the error
but leaves the partially populated sg_prot_array in place. This commit adds
a call to rd_release_prot_space() before returning the error to prevent
leaking the previous allocation.
> diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
> index 97c63b12266fb..b73bdd733928e 100644
> --- a/drivers/target/target_core_rd.c
> +++ b/drivers/target/target_core_rd.c
> @@ -263,8 +263,10 @@ static int rd_build_prot_space(struct rd_dev *rd_dev, int prot_length, int block
> rd_dev->sg_prot_count = sg_tables;
>
> rc = rd_allocate_sgl_table(rd_dev, sg_table, total_sg_needed, 0xff);
> - if (rc)
> + if (rc) {
> + rd_release_prot_space(rd_dev);
[Severity: High]
Could this introduce a use-after-free if triggered by concurrent configfs
writes?
Looking at pi_prot_type_store() in drivers/target/target_core_configfs.c,
there appears to be no locking before checking old_prot and calling
dev->transport->init_prot(dev):
int old_prot = da->pi_prot_type, ret;
struct se_device *dev = da->da_dev;
...
da->pi_prot_type = flag;
if (flag && !old_prot) {
ret = dev->transport->init_prot(dev);
If multiple threads write to pi_prot_type concurrently, they can both enter
rd_build_prot_space() and concurrently overwrite the global
rd_dev->sg_prot_array pointer:
rd_dev->sg_prot_array = sg_table;
rd_dev->sg_prot_count = sg_tables;
rc = rd_allocate_sgl_table(rd_dev, sg_table, total_sg_needed, 0xff);
If one thread's allocation fails, it executes this new error path which
reads rd_dev->sg_prot_array and frees it. This could free the active
scatterlist array that is currently being populated by the other racing
thread, causing a use-after-free of the scatterlist table and pages.
> return rc;
> + }
>
> pr_debug("CORE_RD[%u] - Built Ramdisk Device ID: %u prot space of"
> " %u pages in %u tables\n", rd_dev->rd_host->rd_host_id,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008235411.56641-1-sanan.hasanou@gmail.com?part=2
next prev parent reply other threads:[~2026-10-09 0:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 23:54 [PATCH v3 0/3] scsi: target: rd: Fix oversized ramdisk allocations Sanan Hasanov
2026-10-08 23:54 ` [PATCH v3 1/3] scsi: target: rd: Fix oversized sg table array allocation Sanan Hasanov
2026-10-09 0:03 ` sashiko-bot
2026-10-08 23:54 ` [PATCH v3 2/3] scsi: target: rd: Release protection space on allocation failure Sanan Hasanov
2026-10-09 0:07 ` sashiko-bot [this message]
2026-10-08 23:54 ` [PATCH v3 3/3] scsi: target: rd: Don't invoke the OOM killer for ramdisk pages Sanan Hasanov
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=sashiko-outbox-164669@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sanan.hasanou@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.