Message ID | 20230603145244.1538-3-demi@invisiblethingslab.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1700720vqr; Sat, 3 Jun 2023 07:54:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7HAidQIKvn8aYUhleCQdwosjRQpLhc3ePrgKFouZytZpxsqOSrJS1GoqIh3aKNfkDDE00A X-Received: by 2002:a17:902:d2c5:b0:1ae:622c:e745 with SMTP id n5-20020a170902d2c500b001ae622ce745mr3693586plc.1.1685804057761; Sat, 03 Jun 2023 07:54:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685804057; cv=none; d=google.com; s=arc-20160816; b=QPZ02FjThRCzfy83RC9WlWiFNDIgPsh5Yzr5H4kA+3MgEyPh/tTMYjqJ5yhrCOAUpQ nL9SDwmiaejZtAJKdAtnzv/zc1/7sGyOGyrp5FGWMrzf0rvme7tbj+ypOcS+vxRDCYFg K29vg7V54f9Ol+d7jMr842BNIINeWM5XpashrnA8c63XzDoFhQsBjp1ncKBaKulc9TzS 50pOLPEGTqpKHbjmku28U2ga3VyGJzBXaC3ZZmgQ3cagaKD9uKFM9YQ94sfMg0s/OYOP wmmIS0b508fDgfQj3Kb+R1WvUTGqb5/n7oRRvm/LuDd4x3KX4esXfxQChZW684LiRzm6 PzHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :feedback-id:dkim-signature:dkim-signature; bh=aSjkzE25S8BxmyJfHmxx2kjK812O0BGlmJS9UYp63Y4=; b=YMKNcVRYj2EJjBfrxA8WuwF+kNJAOjBl6b1hp5iEop8ScBbXvlZT6PglddY3dFDKAv Sy6CMyKoyCxYS8xWNMc4S0BKOdzt5TuILuMKxAx02J3UPjguP6NzB7Sc0SGIO+2O21eR VvivxZBjIdGnWY3jLwSCkCm+I1q1Kc9U4+L90KorjyRh8NsmtNQUIgs35tKKT+woBD/J 7sTDvJc7lO4FYvyxweFDory51tYj6HX+wNJ3cnQ2OBlqucWD1YJ7CQtMBo00GmsoYLy6 PVVmViVMVYcVB8Svn7wGZOhOqwjL0mOns4Xp6NOqUekh0//f7wSztm01Hcc820vy+CLr XASA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@invisiblethingslab.com header.s=fm1 header.b=i7f0Q9d5; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JiBQ1MuY; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w17-20020a170902e89100b001a24521e826si2817135plg.61.2023.06.03.07.54.04; Sat, 03 Jun 2023 07:54:17 -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; dkim=pass header.i=@invisiblethingslab.com header.s=fm1 header.b=i7f0Q9d5; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JiBQ1MuY; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230024AbjFCOxU (ORCPT <rfc822;limurcpp@gmail.com> + 99 others); Sat, 3 Jun 2023 10:53:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229640AbjFCOxP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 3 Jun 2023 10:53:15 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 983F4197; Sat, 3 Jun 2023 07:53:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 05CCE5C00D5; Sat, 3 Jun 2023 10:53:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 03 Jun 2023 10:53:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1685803994; x=1685890394; bh=aSjkzE25S8 BxmyJfHmxx2kjK812O0BGlmJS9UYp63Y4=; b=i7f0Q9d5TEM1LgMqJdRiHaENlq ynQteKNn8bi2ztKCkSRVp4PxCircChHJT/lYVyvSYX0Z7/qgUv30JIzrk7ZYzd9i AKpKIVDyu3UAbtIRA78mvGuQxHdfXgT4ZsQlTamYjEoYxKy3K3SrCDGg6x+TRcWC PRTR9cmPgtqtcQlhEfHPC0N+VDElYhcKIbVFQCNVDt5ii7Z+pgsCClY33l8He98V C+xZF3NFoGeKTHJGUNqkMQ2tt2DgND6dr1InWKfjK2UwmGmAMarSoXt0/8UgfsN/ qIXYrRMLYKpDfyanOmEeliW/NbSDAg+adQX8UewvfqzWjY3IRWMEP6UMqISg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1685803994; x= 1685890394; bh=aSjkzE25S8BxmyJfHmxx2kjK812O0BGlmJS9UYp63Y4=; b=J iBQ1MuYjIHoAHRkeTOW9xDwi5DUzBk+/ahqcMcNfOXPc8+MBgWAtdbyAcZpxzIa1 ne/CK8oMKk7G+IAqFPQTTQOxKru3sgIM+tatRjNxFPMPYFzthPJse+XnxjxmgWgu rG0zNv63FslYu0OuN//1Md2SXw1/m8ZlbTDkDseHCLVTTnGOigAGCEGDPsMh8/yM bKGgGhhl6euDITEJ9ZRAtzHnpAdOavk99iorbnhFA5HmX4/25rx8CJ6j4Tqgzrq2 L98mPoTsXdOEhMrwBSQcz9IKGjbQiuXyUsBZy2E1JtKyInnFAm3MIL7PJnaNeY/f i/odYTx+R7YDYAb3QRjWQ== X-ME-Sender: <xms:2VN7ZFOOnLLSMNyLKsjRpe64xNv4C7ld1fAh9C3BV--P5_bBM4otUQ> <xme:2VN7ZH9HASt9Rc9hMEGzW_kzKXepnp30YWZf1kO9WtKvPTqTjXv5NhSJkYGSRD7hg a0Yqm-hc5X4AVY> X-ME-Received: <xmr:2VN7ZETjO3jSzOnsD7iG4cQuZP7Ywu6sDDveNM4Ikww850NU-fG25jr5MXeFW3KVywvz5u9EY7Q> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepffgvmhhi ucforghrihgvucfqsggvnhhouhhruceouggvmhhisehinhhvihhsihgslhgvthhhihhngh hslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeffjefggfeugeduvedvjeekgfeh gffhhfffjeetkeelueefffetfffhtdduheetnecuvehluhhsthgvrhfuihiivgepudenuc frrghrrghmpehmrghilhhfrhhomhepuggvmhhisehinhhvihhsihgslhgvthhhihhnghhs lhgrsgdrtghomh X-ME-Proxy: <xmx:2VN7ZBtIQr8ab_QY7pzn9qmzRils_8B8d0AnTu7S1xcwjAVBYDLCBw> <xmx:2VN7ZNe5KBuMTfqM1xxpC7q-CKAEFwowwLos69plGuNf7DHCuY6Pqw> <xmx:2VN7ZN3maGw4XPSuYZKLMM_p98HZ5GDfJT9zMTF86Sj8fRdDy5ZF7A> <xmx:2lN7ZB5rgqfmsT9A-XpPh30iiaFF6T0YJSxpGK4rjSbnKd6OvQVOsw> Feedback-ID: iac594737:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 10:53:13 -0400 (EDT) From: Demi Marie Obenour <demi@invisiblethingslab.com> To: Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com Cc: Demi Marie Obenour <demi@invisiblethingslab.com>, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v2 2/6] device-mapper: Avoid pointer arithmetic overflow Date: Sat, 3 Jun 2023 10:52:40 -0400 Message-Id: <20230603145244.1538-3-demi@invisiblethingslab.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230603145244.1538-1-demi@invisiblethingslab.com> References: <20230601212456.1533-1-demi@invisiblethingslab.com> <20230603145244.1538-1-demi@invisiblethingslab.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767537440509240946?= X-GMAIL-MSGID: =?utf-8?q?1767693675559108749?= |
Series |
Several device-mapper fixes
|
|
Commit Message
Demi Marie Obenour
June 3, 2023, 2:52 p.m. UTC
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 <demi@invisiblethingslab.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
---
drivers/md/dm-ioctl.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Comments
On Sat, 3 Jun 2023, 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 <demi@invisiblethingslab.com> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org Reviewed-by: Mikulas Patocka <mpatocka@redhat.com> > --- > 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"); > + > + /* > + * Number of bytes remaining, starting with last. This is always > + * sizeof(struct dm_target_spec) or more, as otherwise *last was > + * out of bounds already. > + */ > + size_t remaining = (char *)end - (char *)last; > + > + /* > + * There must be room for both the next target spec and the > + * NUL-terminator of the target itself. > + */ > + if (remaining - sizeof(struct dm_target_spec) <= next) { > + DMERR("Target spec extends beyond end of parameters"); > + return -EINVAL; > + } > + > if (next % 8) { > DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > return -EINVAL; > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > Invisible Things Lab > > -- > dm-devel mailing list > dm-devel@redhat.com > https://listman.redhat.com/mailman/listinfo/dm-devel >
On Sat, Jun 03 2023 at 10:52P -0400, Demi Marie Obenour <demi@invisiblethingslab.com> 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 <demi@invisiblethingslab.com> > 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
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"); + + /* + * Number of bytes remaining, starting with last. This is always + * sizeof(struct dm_target_spec) or more, as otherwise *last was + * out of bounds already. + */ + size_t remaining = (char *)end - (char *)last; + + /* + * There must be room for both the next target spec and the + * NUL-terminator of the target itself. + */ + if (remaining - sizeof(struct dm_target_spec) <= next) { + DMERR("Target spec extends beyond end of parameters"); + return -EINVAL; + } + if (next % 8) { DMERR("Next target spec (offset %u) is not 8-byte aligned", next); return -EINVAL;