Message ID | 20230603145244.1538-2-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 k13csp1700778vqr; Sat, 3 Jun 2023 07:54:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Pmh4xfrEfgyC9CAEWyN+sKaupSZcJsYyWlu6U7ysOtFyyTba/LEKbNMSNVQygdnbq/AIh X-Received: by 2002:a05:6a20:12c1:b0:10b:9dc1:c5e5 with SMTP id v1-20020a056a2012c100b0010b9dc1c5e5mr522219pzg.34.1685804068280; Sat, 03 Jun 2023 07:54:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685804068; cv=none; d=google.com; s=arc-20160816; b=dVEMvZTDq7hBniI7GKDQVgVWFCvBIOBLBqBO5cMt+e1HVrVppnNpAuZw+UWS+3CL6j LHfwQATBWeT8zRJcCK89TxsZPrEWvHEmk7ekqp7hTrZi9tC0O9JePl+kjr+uSs6CRGvb kpWytKv5/R7tpdllc8C4rIaUdmQJ5Q845MRW7CJ+FHBy5K+HcJlHDIMFzUp+AGnvvr2n 4YnS6B2Rs3KlzGjeJS1ZcvtmtcfFjn/LphjyXuQjNefId3/mwGdPTyl1Ow31yd7IsSjq G4gjR+cHxniCK0Lu2MK6yHd4rCnZct+evYSFqaJUYEDwAX5vLNlFBsZ4E4nh0QI0MrGU T+jg== 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=YCzACzClxGa/ktYTHwJaaNWjaN7phPISbw1cPfpWZUo=; b=RDjYMwWJGvt/ErsT3wc0EVkBQ7xIEAP/py7HT5TrdSjTUGaTP43v/t+/iUi6pMHkgI jFIreFU1KVaODOf0c+/lhP/sgpjBtQeI97rJLJFyn7+vlhzU50C8JAe550ItKBsoLQ4R 5J4NI0AVwu2rC/FXqC2YohwznLc59GSLyHBfX6KjDxVx0VuJ59KFEl5fVhHTZb9IwTyj F3f5tv/QTu/lgj5Xc/zmq0jE66oXXM1VnIjXgwwUUs4TLSfJh6NmbfOe/ULRBC3w2jxo P64iizuEzV/J+u0AEXZkYERzZEkuN4x8t+jOnDzhBerV+UbKr0COlNGk/MqncT9gmCkk OjuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@invisiblethingslab.com header.s=fm1 header.b=pXYzXv05; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=vCBsWyth; 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 w184-20020a6382c1000000b00542232db0dcsi2813432pgd.792.2023.06.03.07.54.14; Sat, 03 Jun 2023 07:54:28 -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=pXYzXv05; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=vCBsWyth; 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 S230223AbjFCOxS (ORCPT <rfc822;limurcpp@gmail.com> + 99 others); Sat, 3 Jun 2023 10:53:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229606AbjFCOxO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 3 Jun 2023 10:53:14 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A602CE; Sat, 3 Jun 2023 07:53:13 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C76425C00C8; Sat, 3 Jun 2023 10:53:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 03 Jun 2023 10:53:12 -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=1685803992; x=1685890392; bh=YCzACzClxG a/ktYTHwJaaNWjaN7phPISbw1cPfpWZUo=; b=pXYzXv05o9CAdFMXpOMdKmLWi2 Q5Vuiijm/ua1tXFFnVVd1Mmlyx0n3sJG7LkVHlrx2skKiWiQsHJ5s+xH+jgC0xsU qnJCUnbr2+RZTznR9n9hba8/it5Hsqve8eNGpy0QG3q8nhb0B1fZMwII5oAYzLwz 7Ltro9/nIYFdvObT9L7XkEt3SEUT1fRvXKLzRUcRu0DWmp6C+ElO/93OT/zM8Aot qc/ZHGerpZ5NcMYIvFiQjfF3K6k3pdwGiI/q5Yhhb1BqGoXcKRrTEpbGWzp8Uf33 8phGyAwsIKivy40tWpDXpekYtqYOqbnwMX//S+yA+45b5TOkqsaxN67UJOtg== 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=1685803992; x= 1685890392; bh=YCzACzClxGa/ktYTHwJaaNWjaN7phPISbw1cPfpWZUo=; b=v CBsWyth29tlIlptRZtIJNH+muWrQmiT0Lbs0SbsNteRgKmQXQX+J7Vt5gror77e1 Ta3vwUGl8KlKj4yUjlg7SEmhjxAyAHA/3/GEaOcpKHbkZjqfeFUPzqGPayw4ppWt SY1iURtwhnQk12abr1qwqjnpnn2UOFpHOvFzRcNgap4XiFbgm/vJ8QcL2+l9m6nc yRf9hwoR8sxcEZqlk3scrn+CmX8utRGnawc1t1vP3GSe+0k5uAIC6suw46l5mpJr TYSOPN8JdKHQwvpvEoqy2l0jGPvAv+Wmyju1pHSFcnfe6O/TuNQJHDcwQFJvn/ez wcDzQsQBeOHQnAI6qxI+g== X-ME-Sender: <xms:2FN7ZE2h5QeLfbrohaX27qRqTPUK48kyBgm3-afbOaLUJukdgBM0-w> <xme:2FN7ZPH3omy1JSPsoxKOshmcJiJW3thxamhbYkN0FNFZAHg9LcV-H52-S7u4Ng0Nb n6Lg1u8Kx4mK7I> X-ME-Received: <xmr:2FN7ZM5vsjOKkKbG5RSuNkEV7oUWyz5n7GZ-mv36HQIUpYTZPZzD2_PiclAIGT-dSZBzc91_hsY> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepffgvmhhi ucforghrihgvucfqsggvnhhouhhruceouggvmhhisehinhhvihhsihgslhgvthhhihhngh hslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeffjefggfeugeduvedvjeekgfeh gffhhfffjeetkeelueefffetfffhtdduheetnecuvehluhhsthgvrhfuihiivgepudenuc frrghrrghmpehmrghilhhfrhhomhepuggvmhhisehinhhvihhsihgslhgvthhhihhnghhs lhgrsgdrtghomh X-ME-Proxy: <xmx:2FN7ZN0aOE4E4YhBrqF_xSyYQvn7SEcA-3yA5oHdNLWbpQSybaNF5Q> <xmx:2FN7ZHHCBVyVBX_loHW3pTFfQ6nennJbkyE4OHWJQicqH5itNUuEHw> <xmx:2FN7ZG_sNxo5GyxjtyLo1SVHeVmznrWI33qrIRRElaWXj51-P9LM5Q> <xmx:2FN7ZPDQwR-wycjhdOYZuCyv0fuuk_LPMaDvLTD8z-1uvyfBRl2U7g> Feedback-ID: iac594737:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 10:53:12 -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 1/6] device-mapper: Check that target specs are sufficiently aligned Date: Sat, 3 Jun 2023 10:52:39 -0400 Message-Id: <20230603145244.1538-2-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?1767537155071946148?= X-GMAIL-MSGID: =?utf-8?q?1767693686726042179?= |
Series |
Several device-mapper fixes
|
|
Commit Message
Demi Marie Obenour
June 3, 2023, 2:52 p.m. UTC
Otherwise subsequent code will dereference a misaligned
`struct dm_target_spec *`, which is undefined behavior.
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 | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Sat, Jun 03 2023 at 10:52P -0400, Demi Marie Obenour <demi@invisiblethingslab.com> wrote: > Otherwise subsequent code will dereference a misaligned > `struct dm_target_spec *`, which is undefined behavior. > > 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 | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 > --- a/drivers/md/dm-ioctl.c > +++ b/drivers/md/dm-ioctl.c > @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) > static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > struct dm_target_spec **spec, char **target_params) > { > + static_assert(_Alignof(struct dm_target_spec) <= 8, > + "struct dm_target_spec has excessive alignment requirements"); Really not sure what you mean by "has excessive alignment requirements"... > + if (next % 8) { > + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > + return -EINVAL; > + } > + > *spec = (struct dm_target_spec *) ((unsigned char *) last + next); > *target_params = (char *) (*spec + 1); > But this patch and patches 2 and 3 need more review. I'd like Mikulas to review. I did pick up patches 4-6 for the upcoming 6.5 merge window. Note, please prefix with "dm ioctl" instead of "device-mapper". (I just switched my "dm" prefix to "dm ioctl" and forced update on the dm-6.5 branch, so the commit I referenced earlier for your version copy patch is now here: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-6.5&id=a5a3de762b3ae8959347928843c12502b1b23163 ) Mike
On Sat, 3 Jun 2023, Demi Marie Obenour wrote: > Otherwise subsequent code will dereference a misaligned > `struct dm_target_spec *`, which is undefined behavior. > > 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 | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 > --- a/drivers/md/dm-ioctl.c > +++ b/drivers/md/dm-ioctl.c > @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) > static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > struct dm_target_spec **spec, char **target_params) > { > + static_assert(_Alignof(struct dm_target_spec) <= 8, > + "struct dm_target_spec has excessive alignment requirements"); > + if (next % 8) { > + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > + return -EINVAL; > + } > + > *spec = (struct dm_target_spec *) ((unsigned char *) last + next); > *target_params = (char *) (*spec + 1); > > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > Invisible Things Lab Hi Some architectures (such as 32-bit x86) specify that the alignment of 64-bit integers is only 4-byte. This could in theory break old userspace code that only uses 4-byte alignment. I would change "next % 8" to "next % __alignof__(struct dm_target_spec)". I think that there is no need to backport this patch series to the stable kernels because the bugs that it fixes may only be exploited by the user with CAP_SYS_ADMIN privilege. So, there is no security or reliability problem being fixed. Mikulas
On Thu, Jun 22, 2023 at 12:28:28PM -0400, Mike Snitzer wrote: > On Sat, Jun 03 2023 at 10:52P -0400, > Demi Marie Obenour <demi@invisiblethingslab.com> wrote: > > > Otherwise subsequent code will dereference a misaligned > > `struct dm_target_spec *`, which is undefined behavior. > > > > 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 | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > > index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 > > --- a/drivers/md/dm-ioctl.c > > +++ b/drivers/md/dm-ioctl.c > > @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) > > static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > > struct dm_target_spec **spec, char **target_params) > > { > > + static_assert(_Alignof(struct dm_target_spec) <= 8, > > + "struct dm_target_spec has excessive alignment requirements"); > > Really not sure what you mean by "has excessive alignment requirements"... This patch checks that struct dm_target_spec is 8-byte aligned. That is okay if its alignment is 8 or less, but not if is 16 or more, so I added a static assert to check that struct dm_target_spec indeed requires at most 8-byte alignment. That said, “excessive alignment requirements” is (as shown by you having to ask this question) a bad error message. Would “must not require more than 8-byte alignment” be better? > > + if (next % 8) { > > + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > > + return -EINVAL; > > + } > > + > > *spec = (struct dm_target_spec *) ((unsigned char *) last + next); > > *target_params = (char *) (*spec + 1); > > > > But this patch and patches 2 and 3 need more review. I'd like Mikulas to review. > > I did pick up patches 4-6 for the upcoming 6.5 merge window. Thanks! > Note, please prefix with "dm ioctl" instead of "device-mapper". Good to know, thanks! I have several additional patches written that require patch 4. Should I send patches 1 through 3 in the same series as well?
On Thu, Jun 22, 2023 at 07:29:52PM +0200, Mikulas Patocka wrote: > > > On Sat, 3 Jun 2023, Demi Marie Obenour wrote: > > > Otherwise subsequent code will dereference a misaligned > > `struct dm_target_spec *`, which is undefined behavior. > > > > 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 | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > > index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 > > --- a/drivers/md/dm-ioctl.c > > +++ b/drivers/md/dm-ioctl.c > > @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) > > static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > > struct dm_target_spec **spec, char **target_params) > > { > > + static_assert(_Alignof(struct dm_target_spec) <= 8, > > + "struct dm_target_spec has excessive alignment requirements"); > > + if (next % 8) { > > + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > > + return -EINVAL; > > + } > > + > > *spec = (struct dm_target_spec *) ((unsigned char *) last + next); > > *target_params = (char *) (*spec + 1); > > > > -- > > Sincerely, > > Demi Marie Obenour (she/her/hers) > > Invisible Things Lab > > Hi > > Some architectures (such as 32-bit x86) specify that the alignment of > 64-bit integers is only 4-byte. This could in theory break old userspace > code that only uses 4-byte alignment. I would change "next % 8" to "next % > __alignof__(struct dm_target_spec)". That’s fine, provided that the rest of the code is okay with 4-byte alignment. > I think that there is no need to backport this patch series to the stable > kernels because the bugs that it fixes may only be exploited by the user > with CAP_SYS_ADMIN privilege. So, there is no security or reliability > problem being fixed. I agree that there is no reliability problem, but with kernel lockdown root → kernel is a security boundary, so fixes for memory unsafety problems should still be backported IMO.
On Thu, Jun 22 2023 at 3:51P -0400, Demi Marie Obenour <demi@invisiblethingslab.com> wrote: > On Thu, Jun 22, 2023 at 12:28:28PM -0400, Mike Snitzer wrote: > > On Sat, Jun 03 2023 at 10:52P -0400, > > Demi Marie Obenour <demi@invisiblethingslab.com> wrote: > > > > > Otherwise subsequent code will dereference a misaligned > > > `struct dm_target_spec *`, which is undefined behavior. > > > > > > 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 | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c > > > index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 > > > --- a/drivers/md/dm-ioctl.c > > > +++ b/drivers/md/dm-ioctl.c > > > @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) > > > static int next_target(struct dm_target_spec *last, uint32_t next, void *end, > > > struct dm_target_spec **spec, char **target_params) > > > { > > > + static_assert(_Alignof(struct dm_target_spec) <= 8, > > > + "struct dm_target_spec has excessive alignment requirements"); > > > > Really not sure what you mean by "has excessive alignment requirements"... > > This patch checks that struct dm_target_spec is 8-byte aligned. That is > okay if its alignment is 8 or less, but not if is 16 or more, so I added > a static assert to check that struct dm_target_spec indeed requires at > most 8-byte alignment. That said, “excessive alignment requirements” is > (as shown by you having to ask this question) a bad error message. > Would “must not require more than 8-byte alignment” be better? Yes, that's better, I've updated it to use that. > > > + if (next % 8) { > > > + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); > > > + return -EINVAL; > > > + } > > > + > > > *spec = (struct dm_target_spec *) ((unsigned char *) last + next); > > > *target_params = (char *) (*spec + 1); > > > > > > > But this patch and patches 2 and 3 need more review. I'd like Mikulas to review. > > > > I did pick up patches 4-6 for the upcoming 6.5 merge window. > > Thanks! > > > Note, please prefix with "dm ioctl" instead of "device-mapper". > > Good to know, thanks! I have several additional patches written that > require patch 4. Should I send patches 1 through 3 in the same series > as well? I did end up picking up patches 1-3 and rebased so they are in front of your patches 4-6 like you intended. But I agree with Mikulas, I'm not seeing the point in tagging any of these for stable@. All commits are currently at the tip of dm-6.5, see: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-6.5 Mike
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index cc77cf3d410921432eb0c62cdede7d55b9aa674a..34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1394,6 +1394,13 @@ static inline fmode_t get_mode(struct dm_ioctl *param) static int next_target(struct dm_target_spec *last, uint32_t next, void *end, struct dm_target_spec **spec, char **target_params) { + static_assert(_Alignof(struct dm_target_spec) <= 8, + "struct dm_target_spec has excessive alignment requirements"); + if (next % 8) { + DMERR("Next target spec (offset %u) is not 8-byte aligned", next); + return -EINVAL; + } + *spec = (struct dm_target_spec *) ((unsigned char *) last + next); *target_params = (char *) (*spec + 1);