mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bryam Vargas <hexlabsecurity@proton.me>
To: David Laight <david.laight.linux@gmail.com>
Cc: Dan Williams <djbw@kernel.org>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>, Ira Weiny <iweiny@kernel.org>,
	Alison Schofield <alison.schofield@intel.com>,
	nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libnvdimm/labels: Prevent integer overflow in __nd_label_validate()
Date: Wed, 24 Jun 2026 05:45:40 +0000	[thread overview]
Message-ID: <20260624054533.531015-1-hexlabsecurity@proton.me> (raw)
In-Reply-To: <20260621112357.56a290bc@pumpkin>

On 2026-06-21, David Laight wrote:
> The same could be done for nslot - any value above 64k is pretty much
> guaranteed to be garbage

I took that up in v2, but it does not hold against the code, so v3 drops it.

The allocation it was meant to bound -- ndd->data in nd_label_data_init() --
is kvzalloc(config_size), not nslot-derived, so capping nslot shrinks nothing.
And the cap is unsafe: on ND_NSINDEX_INIT the kernel writes
nslot = nvdimm_num_label_slots(ndd) = config_size / label_size, which is above
64K once config_size is past ~8.4MB.  A 64K cap then rejects labels the kernel
itself wrote, so a freshly-formatted large device fails its own next probe.

The (u64) cast in patch 1 already makes the bound exact, so the overflow is
closed without the cap.  v3 keeps the cast; the labelsize-shift UB the review
also turned up is a separate fix, not a stand-in for the cap.

Thanks,
Bryam


  parent reply	other threads:[~2026-06-24  5:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-20 20:54 Bryam Vargas via B4 Relay
2026-06-21 10:23 ` David Laight
2026-06-22  8:14   ` Bryam Vargas
2026-06-24  5:45   ` Bryam Vargas [this message]
2026-06-24  0:38 ` Alison Schofield

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=20260624054533.531015-1-hexlabsecurity@proton.me \
    --to=hexlabsecurity@proton.me \
    --cc=alison.schofield@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david.laight.linux@gmail.com \
    --cc=djbw@kernel.org \
    --cc=iweiny@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=vishal.l.verma@intel.com \
    /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®