From: sashiko-bot@kernel.org
To: "Bryam Vargas via B4 Relay"
<devnull+hexlabsecurity.proton.me@kernel.org>
Cc: nvdimm@lists.linux.dev
Subject: Re: [PATCH v2 2/2] libnvdimm/labels: reject an implausibly large on-media slot count
Date: Wed, 24 Jun 2026 04:30:13 +0000 [thread overview]
Message-ID: <20260624043013.9AD331F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623-b4-disp-1f2c537a-v2-2-59af73f1f090@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The hardcoded cap of 64K for `nslot` breaks legitimate devices with large label storage areas and introduces a self-bricking behavior by rejecting natively generated label formats.
--
commit e9419d2283340d1b7069d74b83a7188e43fd5de9
Author: Bryam Vargas <hexlabsecurity@proton.me>
libnvdimm/labels: reject an implausibly large on-media slot count
This commit adds a 64K upper bound check on the nslot value read from the
media to prevent large allocations. It validates the nslot field in
__nd_label_validate() against the newly introduced NSINDEX_NSLOT_MAX.
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index ec12ce72cfe2c..ce1e43d67babe 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -202,6 +202,10 @@ static int __nd_label_validate(struct nvdimm_drvdata *ndd)
}
nslot = __le32_to_cpu(nsindex[i]->nslot);
+ if (nslot > NSINDEX_NSLOT_MAX) {
+ dev_dbg(dev, "nsindex%d nslot: %u implausibly large\n", i, nslot);
+ continue;
+ }
[Severity: High]
Could this cause a regression by breaking legitimate devices with large
label areas?
If a device has a config_size larger than ~8.4MB, nvdimm_num_label_slots()
will naturally generate an nslot value greater than 64K.
When the kernel formats such a device in nd_label_write_index(), it writes
this unbounded nslot to the media:
drivers/nvdimm/label.c:nd_label_write_index() {
...
if (flags & ND_NSINDEX_INIT)
nslot = nvdimm_num_label_slots(ndd);
...
}
Will __nd_label_validate() then reject these newly initialized labels on the
next probe, making the namespaces inaccessible?
Also, does this check prevent the large allocation mentioned in the commit
message? Looking at nd_label_data_init(), the allocation appears to use
config_size directly before nslot is even read or validated.
if ((u64)nslot * sizeof_namespace_label(ndd)
+ 2 * sizeof_namespace_index(ndd)
> ndd->nsarea.config_size) {
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-b4-disp-1f2c537a-v2-0-59af73f1f090@proton.me?part=2
prev parent reply other threads:[~2026-06-24 4:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 4:19 [PATCH v2 0/2] libnvdimm/labels: fix the nslot product overflow and cap the slot count Bryam Vargas via B4 Relay
2026-06-24 4:19 ` Bryam Vargas
2026-06-24 4:19 ` [PATCH v2 1/2] libnvdimm/labels: Prevent integer overflow in __nd_label_validate() Bryam Vargas via B4 Relay
2026-06-24 4:19 ` Bryam Vargas
2026-06-24 4:31 ` sashiko-bot
2026-06-24 4:19 ` [PATCH v2 2/2] libnvdimm/labels: reject an implausibly large on-media slot count Bryam Vargas via B4 Relay
2026-06-24 4:19 ` Bryam Vargas
2026-06-24 4:30 ` sashiko-bot [this message]
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=20260624043013.9AD331F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=devnull+hexlabsecurity.proton.me@kernel.org \
--cc=nvdimm@lists.linux.dev \
--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.