From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 219E1257452 for ; Sun, 21 Jun 2026 10:24:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782037445; cv=none; b=FPqMC2P2ItfKuCDqNgebDraWZ7FZQGi5cIWGHjTtuNzL/AGynDtVG+qkf/lG+MEMH3QICKefCIDrSG4pjwQ9kTKgJtDc/lvEP6hFWPQMIMt1BShUTMBoiVribZp3HZyHsLqyrCi2QzXvnOJIP/YqrN241zRCe/Z1dfbu0dvtUag= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782037445; c=relaxed/simple; bh=ywfWqiioRSMVXSoicXy7pHEdlVNNT3ATJpOSLq5TwFc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mg+zCtdZplgbEihUWulrqxcb/AxdY6Na6CCDsxyblmd44BzU1QSCqF3CC7/F03bnhl2SEQGqs/tnjwe8I/XepHrdM0fIwJus2uxl1gflFk8facpdEJosjqOQyGk+umkHGstjHvkl4M9mzaMJcae5kOTv6FISWkZ9OG70IzvWQKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pOjkGLdQ; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pOjkGLdQ" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49249707788so7074695e9.2 for ; Sun, 21 Jun 2026 03:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782037441; x=1782642241; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YArF8gKOdruQVzdzXc/NwPAF4gYYVy3RGU/L1AprjhI=; b=pOjkGLdQGhzf4geyKoZiRtJvSxNIPrEISvVAZ985gO296ebjS+9D6/lThIeNTxiT/W pinNbogiHJGASJm/zwgGyNbAIRj1qZesih2c8bNjmMuDvedp6euWBnGMsTJawLkxX9sF dWY6oOHidimZ732zFereDrwIFoqnaO1GUlBkbM1s4haeCxJ+K2vC+qFcShUrscRCQn8w RwcMnBDaLMqFG7uq3FfTnPOS61nv3CJRAb8o/VMnbQW4iuCTytyADB56a/PIx2dyMN8r OIFmtRTevFEl2SmhhQgw7hHLdOk2qM6J0ClqvP4p5gV2SEf3zq7J8llW8vT3cGNqfNHD k6/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782037441; x=1782642241; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YArF8gKOdruQVzdzXc/NwPAF4gYYVy3RGU/L1AprjhI=; b=cDL2zqeLxExuchK7WIGYR/88Iiqhe5MQAWjDJJ5hOtZdBda04uWVpDiAbXKex5tNfG a3S5VxG0JSRSPkKk8uC9arwRJ6Tc9aBBJpNSBJlCK2dJ6v7Yp1m9vUwyxtG3qgBqUl4G mMpkkYVf1YtSeeco+nK9YD02XmCHRBwxpDCL2cLYGV4h/zlM/gSZHbiD/BhV+38k81li mehNuNUAJSCdkMO1SWNE4H5g7kj7/ExA/BgyWOp+23FCqWJk7Ivqg8vqg5TXUBcAv8wL sSbmmcotBhqKp4XoXY8FbE1BWJfuDOGcHXfejlefkO855L0umIQkD58AkX+zYfkB7mg8 x0pg== X-Forwarded-Encrypted: i=1; AFNElJ/v2sSWsyh3PuJwQ/6jivzvrkW6RjtdugYXSshLRXjT26LPhbA/1Rz48QFj9iqcCgNZsnNqeJkJJVLRur0=@vger.kernel.org X-Gm-Message-State: AOJu0YyPeo5I+JtvNFV7NpTDuC7mdQrAxwQm4qpvhHLYDOGN2RdQpjuA L9d1XKpdhI9CjXlCNvduA0fpeZDghve4Gs1MFOmLD+f+G3UDgk+3x2S3Q2WiiC8u X-Gm-Gg: AfdE7cl7HpJU8sq9Mo/8rpkvEowMzp1gM8J3Vn7BPePvNRUM5Cp/Jp19B42+HpyQgFX WKVGI15QuyGd5tRzR3UnDum9gJMivZ32PcN8jBQRwTHhLdHrGso1isH4sEKBNZO2mjPjm5k+u0e B41spEpfm15KUWhD97/t/4m1lKw+8my71s31S39X7AQJUMdjqOjNcIJ0VBTAUxJDBqw2VO5ilpC f+OYGEqmpJMLKiwkqsc7GcClMdNwCtNXFtu4ClOtb2k2LmSmABpeq3ewq5SaTBkPIGTdrMVV41F G0kjGcVePjz0QXK2XKNp/ZH0/edklpalx/vDuX0xzFiay4RqB3thFu9JUoGlm+Jf3NM3JQbfWum /s668kbr6MkclPY6b95XSJophgAugAtkuNWxnNXyRwS5vhkkRJi0Uxx6ltEmtMiESeavFKRqkap Y4Ah2duEl7Cw7ohpEKOzsCm1GisYcn/ZmCLo6LKYtmDyosZqYEag== X-Received: by 2002:a05:600c:6288:b0:490:e18f:d108 with SMTP id 5b1f17b1804b1-492490a7778mr84446065e9.19.1782037441272; Sun, 21 Jun 2026 03:24:01 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49245a69f81sm168379525e9.1.2026.06.21.03.24.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2026 03:24:00 -0700 (PDT) Date: Sun, 21 Jun 2026 11:23:57 +0100 From: David Laight To: Bryam Vargas via B4 Relay Cc: hexlabsecurity@proton.me, Dave Jiang , Dan Williams , Ira Weiny , Vishal Verma , linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev Subject: Re: [PATCH] libnvdimm/labels: Prevent integer overflow in __nd_label_validate() Message-ID: <20260621112357.56a290bc@pumpkin> In-Reply-To: <20260620-b4-disp-7f43b155-v1-1-0cfd8017f7a0@proton.me> References: <20260620-b4-disp-7f43b155-v1-1-0cfd8017f7a0@proton.me> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 20 Jun 2026 15:54:39 -0500 Bryam Vargas via B4 Relay wrote: > From: Bryam Vargas > > The on-media namespace index field nslot is a u32 read from the DIMM > label storage area. __nd_label_validate() bounds it against the config > area size, but sizeof_namespace_label() returns unsigned, so the product > nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before > the comparison. A crafted nslot passes the bound and is then used as the > loop trip count in nd_label_data_init(), whose memset() walks off the end > of the config_size buffer: an out-of-bounds write. > > The field is not trusted -- it comes from the medium, or from userspace > via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound > check is exact; conforming labels are unaffected. Is this enough and/or a sane way to stop the overflow. AFAICT label_size is either 128 or 258. But I can't see where nsarea.config_size is set. If it comes from a user ioctl there should be some associated sanity limits. The same could be done for nslot - any value above 64k is pretty much guaranteed to be garbage - I'd bet valid values are actually very small integers. David > > Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") > Cc: stable@vger.kernel.org > Signed-off-by: Bryam Vargas > --- > The check was safe when introduced: 4a826c83db4e ("libnvdimm: namespace > indices: read and validate") multiplied by sizeof(struct > nd_namespace_label), a size_t, so the product was 64-bit. 564e871aa66f > replaced that with sizeof_namespace_label(), which returns unsigned, when > the label size became a runtime value -- narrowing the product to 32 bits. > > The sibling multiply in sizeof_namespace_index() uses an nslot derived > from config_size (nvdimm_num_label_slots()), not the on-media field, so it > cannot overflow and is left unchanged. > > Reproduced with an out-of-tree module that mirrors nd_label_data_init() -- > kvzalloc(config_size), the __nd_label_validate() bound check, and the > memset loop -- since the defect is the wrapped arithmetic into the memset, > not the DIMM-probe plumbing: > > Build A (without this patch), nslot = 0x02000000, 128-byte labels: > the u32 product wraps to 0, the index is accepted, and the loop's > memset() writes past the kvzalloc'd buffer -> > right of the config_size region -> panic. > Build B (with this patch): the 64-bit product exceeds config_size, the > index is rejected, the loop never runs -> clean. > Control (legitimate small nslot): writes stay in bounds -> clean. > > BUG: KASAN: slab-out-of-bounds, Write of size 128, 0 bytes to the > --- > drivers/nvdimm/label.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c > index 4218e3ac4a2a..ec12ce72cfe2 100644 > --- a/drivers/nvdimm/label.c > +++ b/drivers/nvdimm/label.c > @@ -202,7 +202,7 @@ static int __nd_label_validate(struct nvdimm_drvdata *ndd) > } > > nslot = __le32_to_cpu(nsindex[i]->nslot); > - if (nslot * sizeof_namespace_label(ndd) > + if ((u64)nslot * sizeof_namespace_label(ndd) > + 2 * sizeof_namespace_index(ndd) > > ndd->nsarea.config_size) { > dev_dbg(dev, "nsindex%d nslot: %u invalid, config_size: %#x\n", > > --- > base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66 > change-id: 20260620-b4-disp-7f43b155-92b84c904c08 > > Best regards,