Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp11607522rwd; Thu, 22 Jun 2023 16:07:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ53rkop54cnC3Ut0d2a1a3hRqgUzWSE+QSqeokcrp9Ro65VJI69oYiEkrp+TZale80sbXuS X-Received: by 2002:a17:903:484:b0:1b0:4502:8547 with SMTP id jj4-20020a170903048400b001b045028547mr18606141plb.35.1687475277374; Thu, 22 Jun 2023 16:07:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687475277; cv=none; d=google.com; s=arc-20160816; b=zxSw1DL6yeE14X+g5RFEJhORLJvbHdUGXmI/NBoBDIP+Y2a58jb8WCh0ckJFIltby3 egCqv6usA1s7c5/q+oFX8GcN5JCJCCC02dIiSg1k41II4vU5uLfTxH1ozwV7mM3+exMZ pOkROtcnudAcRZlxuMPl2nDmzxJrPTnPk1DUvUz5vJCzPqTO3x5n0SOdODPqpuGGjQWU sILjwN7PQr7sQIp14RA6u55UFgMn/2g4tV21iHElE+KcXdOPhCCfdYqMDYMEcq4cTZUs wkwXupBsFyO2YO1z0Elcpbj5LRoqgPzJYasB0VTyE1q3a45PH3N7etKXPZf5vw/VE/bW r6Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=9x9QfSSVUpTeAWdqCixUHSwi7foPPLLpLOSUdEXv8WE=; b=qoyaJpskfbuZ710CW7oei87oJ6pb+WPC3Tppx8HbU7W9ecwE4plr5Qrxz7ncka5HFu CKj+0zAuOzBLaZgVsE439lJ3975f4adIf6Vw2JdvR5dOouxmIIfdnuIOepLTbnP1nWCW UMjHgvfaxoRJ+L0cX5beXlcdSmaL98fWH6nvhT6mzmcQIfCTIiFkvn+4JOzgDhEOSgEl xtRPIFH390NzJA9FsY4WWax/Egz+FAlL6w6+x5qAjsJsGVhKgRGP+LOQ3XvxOYlawlhy /MjGYTqQlQ4NQSNqjKMjn6MOQdcQ023mL8P9PdXEWZYWdLYDpEROufCifCB4re8ftBrA kCvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x1-20020a170902b40100b001b4f582d796si7203955plr.167.2023.06.22.16.07.44; Thu, 22 Jun 2023 16:07:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231414AbjFVWvV (ORCPT + 99 others); Thu, 22 Jun 2023 18:51:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231411AbjFVWvS (ORCPT ); Thu, 22 Jun 2023 18:51:18 -0400 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04AA41BD3 for ; Thu, 22 Jun 2023 15:50:38 -0700 (PDT) Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6300465243eso209806d6.2 for ; Thu, 22 Jun 2023 15:50:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687474237; x=1690066237; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9x9QfSSVUpTeAWdqCixUHSwi7foPPLLpLOSUdEXv8WE=; b=WUvGAV6sUSx4GZ+ymKgR2k6r8qrSDXV1628oH4zeSpiqHZ2DJBG+e0eej38xUsEjSe NL1hq5K+W/reggbSTNkHcsRZBaFUY7KfhNdnRF8FCrTjghcCx9Ss3/sAZbF5tdp0H31f 80Xr0WVubOYPzkqLczVCyo/vl1Ef8FOpsjL/XeqDAICkwvcGf4bGX6kG5/gyT1MvO+LF txxc/lr/xJh6yoIIHIzKhRy60Vm8lBK6jb+8p50txGYSey+b3caNOb9VbRj65mT29WF0 M3exU1ApLfAyRdTW2v5TzpHVdeY7guX3UDA0Amg+zm/AM8EqD8H58qNXLrro5hxLoREj PyjA== X-Gm-Message-State: AC+VfDy8rMFHgqcRxI92/lbYdE5tuaTngwL9mud5CmIXniu4bMD06zfj siymYfzF8KFoQOIBC/yc4fQy X-Received: by 2002:a05:6214:20ae:b0:62f:fe87:67e9 with SMTP id 14-20020a05621420ae00b0062ffe8767e9mr21122003qvd.44.1687474237072; Thu, 22 Jun 2023 15:50:37 -0700 (PDT) Received: from localhost (pool-68-160-166-30.bstnma.fios.verizon.net. [68.160.166.30]) by smtp.gmail.com with ESMTPSA id i20-20020a0cf394000000b0063013c621fasm4263594qvk.68.2023.06.22.15.50.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jun 2023 15:50:36 -0700 (PDT) Date: Thu, 22 Jun 2023 18:50:35 -0400 From: Mike Snitzer To: Demi Marie Obenour Cc: Alasdair Kergon , dm-devel@redhat.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 2/6] device-mapper: Avoid pointer arithmetic overflow Message-ID: References: <20230601212456.1533-1-demi@invisiblethingslab.com> <20230603145244.1538-1-demi@invisiblethingslab.com> <20230603145244.1538-3-demi@invisiblethingslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230603145244.1538-3-demi@invisiblethingslab.com> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 03 2023 at 10:52P -0400, Demi Marie Obenour wrote: > Especially on 32-bit systems, it is possible for the pointer arithmetic > to overflow and cause a userspace pointer to be dereferenced in the > kernel. > > Signed-off-by: Demi Marie Obenour > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > --- > drivers/md/dm-ioctl.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > index 34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc..64e8f16d344c47057de5e2d29e3d63202197dca0 100644 > --- a/drivers/md/dm-ioctl.c > +++ b/drivers/md/dm-ioctl.c > @@ -1396,6 +1396,25 @@ static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > { > static_assert(_Alignof(struct dm_target_spec) <= 8, > "struct dm_target_spec has excessive alignment requirements"); > + static_assert(offsetof(struct dm_ioctl, data) >= sizeof(struct dm_target_spec), > + "struct dm_target_spec too big"); I'm struggling to see the point for this compile-time check? Especially when you consider (on x86_64): sizeof(struct dm_target_spec) = 40 offsetof(struct dm_ioctl, data) = 305 Just feels like there is no utility offered by adding this check. SO I've dropped it. But if you feel there is some inherent value please let me know. Thanks, Mike