Message ID | 20221121112134.407362-1-glider@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1524951wrr; Mon, 21 Nov 2022 03:28:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf4hw6BSAKVhH579spKWXtHoCbLWaPjVGtuR/eqrmXALk4arAihH0+P17+RnLGCxjSJz30vB X-Received: by 2002:a17:906:4309:b0:78d:36d7:92ae with SMTP id j9-20020a170906430900b0078d36d792aemr15501886ejm.113.1669030081824; Mon, 21 Nov 2022 03:28:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669030081; cv=none; d=google.com; s=arc-20160816; b=mAOV8BIIzVUMQw+kjK9qt2QlSDyWP4f72ijYqzNEGovryPe5f5adLIwenseVPXMHLT DBFpCLEyntGPTS00mZJd4thU/j7bsMkuYy8ewRce4VgMlbMwDk3UwJ76+Ap/Y+Y30ksf RyLNFKZNx5C98lfKHsjMxH9ubRZS8x935mw4swLOXqibuzfvEisSCVdwFxhcuSNyPz1t MTqKDSydrtrq9WrEFRbjYjQn+09ML3XOaBJWTulHXbckllRr/6PzvVTkjga60FCQzf1Z ZrE2DXe2DEHUmSaFaYiavDIl/ZjM0ujadY9XQsk2kyT8Ktrhx6Df8lKiTEIo9MvnOf2N 8abQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=Ut094+1HiZ4Cjb1djYz8ZPvCLMxdVr+mJo3AtkrOKCA=; b=BR11xgA/ON/9gKbPuN+ftz/6hhZn4X+RF/7wziVsq6lZ7xyUFPIe62L/ZWTVmdp3Br dUfE1oBhuxefVIH3+s6o2pOnHjCq0TgbpRoG15a+dKwIKsPiWIaS8HcwtzA05zxuPNRc 2bSPCD+cd5gxT14NIo2Qn8LC4F3XuZzD+NLmsAeesQMMDR5G8uCPOoJnSFrW9TvKpJSt 0NI6l2Wo1Rb2+CkJXRILZ1r71Si0PR2PcU3k6NUAo4p6BBhmB0b050VqRcO5K/WjUAWF 70OM/Kexfektt9BchxpZiwMtrHMNLHvaVyxUemgaQ7dT2wM0fnP6u1opRa9kGL40x24x G0Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=PtZTUVzn; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sa27-20020a1709076d1b00b0078d93245e23si10364955ejc.791.2022.11.21.03.27.37; Mon, 21 Nov 2022 03:28:01 -0800 (PST) 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=@google.com header.s=20210112 header.b=PtZTUVzn; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229905AbiKUL0l (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Mon, 21 Nov 2022 06:26:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230247AbiKUL0J (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Nov 2022 06:26:09 -0500 Received: from mail-ej1-x64a.google.com (mail-ej1-x64a.google.com [IPv6:2a00:1450:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF360B10DC for <linux-kernel@vger.kernel.org>; Mon, 21 Nov 2022 03:21:39 -0800 (PST) Received: by mail-ej1-x64a.google.com with SMTP id hs34-20020a1709073ea200b007ad86f91d39so6492735ejc.10 for <linux-kernel@vger.kernel.org>; Mon, 21 Nov 2022 03:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=Ut094+1HiZ4Cjb1djYz8ZPvCLMxdVr+mJo3AtkrOKCA=; b=PtZTUVznvnflFwUv9SKypxZQqr7i1LRYenCMrhMEOVGiPfxccwpjsY0A4YtFeeVnlF h2lGU/CX2UGfxpSXxpMO1krIzX7InkrGi25tw16FUZGnYRG+48rz3JaSCOEXLpqgE/EM opVGk0Q/rJdXGr0oIG5tziMO7oWC8RwHnTFpjZTCghBdovVeuHaJ0UfGVV+HSRF+Mevy v/vENEx2/1GIDj3F6RVT8uC+lujEgt6uMMFBYmaBcrnbZqaZYAVFDM7x70bVO4+mtAA4 t18AcVUc3fi2I1HwUNs+HNibRi0u8zeQUEKGIUhxxWoUi8pcajXw5PvuDm5HDd/vf0M6 Dc+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Ut094+1HiZ4Cjb1djYz8ZPvCLMxdVr+mJo3AtkrOKCA=; b=JoobevLEXLEwsjpSMKZnR/4TGAzG3/OYg+UnnJUpZrT36Hf+wcxaatqonsiVnygErD 9ZIXmOharFTj/mZm9JqtUMouNv96u3gUckCDsxjGhyQdqXOhkdCVLbjSC1ixS41yarTV 6xw62fkN9MZxKvbl4yDs0BVcejM65IMgy1V7LalENF2nHspdQSibUz7ijYsnwD0I24WG EZ9TXm7ioQH8NLzlEgT2y28/Yg1CGfFK0Jl4NpfGHU6dQmDIdxPnIk6Qb5V6tnQI3nu4 rJnNe9a1f2K8vFE48kgPajLnbnfxycYDv5O7R9j126soEjRQaat6sg7rSQ09fbA3NZd8 wa1A== X-Gm-Message-State: ANoB5pk3jYbL+Z0+vFeWz7VsEauMIDx0LcVg1om8j00uZ2iP06C+ztDO lOi1+vcVOXajI6C+i7AdYABKyc0/nTE= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:db68:962:2bf6:6c7]) (user=glider job=sendgmr) by 2002:aa7:c788:0:b0:458:b9f9:9fba with SMTP id n8-20020aa7c788000000b00458b9f99fbamr16132478eds.305.1669029698340; Mon, 21 Nov 2022 03:21:38 -0800 (PST) Date: Mon, 21 Nov 2022 12:21:30 +0100 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog Message-ID: <20221121112134.407362-1-glider@google.com> Subject: [PATCH 1/5] fs: ext4: initialize fsdata in pagecache_write() From: Alexander Potapenko <glider@google.com> To: glider@google.com Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, tytso@mit.edu, adilger.kernel@dilger.ca, jaegeuk@kernel.org, chao@kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Eric Biggers <ebiggers@kernel.org>, syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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?1750104886891446038?= X-GMAIL-MSGID: =?utf-8?q?1750104886891446038?= |
Series |
[1/5] fs: ext4: initialize fsdata in pagecache_write()
|
|
Commit Message
Alexander Potapenko
Nov. 21, 2022, 11:21 a.m. UTC
When aops->write_begin() does not initialize fsdata, KMSAN reports
an error passing the latter to aops->write_end().
Fix this by unconditionally initializing fsdata.
Cc: Eric Biggers <ebiggers@kernel.org>
Fixes: c93d8f885809 ("ext4: add basic fs-verity support")
Reported-by: syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com
Signed-off-by: Alexander Potapenko <glider@google.com>
---
fs/ext4/verity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, 21 Nov 2022 12:21:30 +0100 Alexander Potapenko <glider@google.com> wrote: > When aops->write_begin() does not initialize fsdata, KMSAN reports > an error passing the latter to aops->write_end(). > > Fix this by unconditionally initializing fsdata. > > ... > I'm assuming that this is not-a-bug, and that these changes are purely workarounds for a KMSAN shortcoming? If true, this important info should be included in each changelog, please. If false, please provide a full description of the end-user visible effects of the bug. Also, it would be helpful to describe why it is not considered practical to teach KMSAN to handle this? > --- a/fs/ext4/verity.c > +++ b/fs/ext4/verity.c > @@ -79,7 +79,7 @@ static int pagecache_write(struct inode *inode, const void *buf, size_t count, > size_t n = min_t(size_t, count, > PAGE_SIZE - offset_in_page(pos)); > struct page *page; > - void *fsdata; > + void *fsdata = NULL; > int res; > > res = aops->write_begin(NULL, mapping, pos, n, &page, &fsdata);
On Mon, Nov 21, 2022 at 12:21:30PM +0100, Alexander Potapenko wrote: > When aops->write_begin() does not initialize fsdata, KMSAN reports > an error passing the latter to aops->write_end(). > > Fix this by unconditionally initializing fsdata. > > Cc: Eric Biggers <ebiggers@kernel.org> > Fixes: c93d8f885809 ("ext4: add basic fs-verity support") > Reported-by: syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com > Signed-off-by: Alexander Potapenko <glider@google.com> > --- > fs/ext4/verity.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ext4/verity.c b/fs/ext4/verity.c > index 3c640bd7ecaeb..30e3b65798b50 100644 > --- a/fs/ext4/verity.c > +++ b/fs/ext4/verity.c > @@ -79,7 +79,7 @@ static int pagecache_write(struct inode *inode, const void *buf, size_t count, > size_t n = min_t(size_t, count, > PAGE_SIZE - offset_in_page(pos)); > struct page *page; > - void *fsdata; > + void *fsdata = NULL; > int res; > > res = aops->write_begin(NULL, mapping, pos, n, &page, &fsdata); Reviewed-by: Eric Biggers <ebiggers@google.com> - Eric
On Mon, Nov 21, 2022 at 11:48:40AM -0800, Andrew Morton wrote: > On Mon, 21 Nov 2022 12:21:30 +0100 Alexander Potapenko <glider@google.com> wrote: > > > When aops->write_begin() does not initialize fsdata, KMSAN reports > > an error passing the latter to aops->write_end(). > > > > Fix this by unconditionally initializing fsdata. > > > > ... > > > > I'm assuming that this is not-a-bug, and that these changes are purely > workarounds for a KMSAN shortcoming? It's a weird one. It used to be not-a-bug. Then we changed from std=gnu99 to std=gnu11 or something. And in the intervening years, the C standards ctte decided that passing an uninitialised pointer to a function was UB. So we start by passing a pointer to the pointer to ->write_begin(). Some ->write_begin functions initialise that pointer; others don't. Then we pass the pointer directly to ->write_end. If ->write_begin initialised the pointer, that's fine, and if not, it's UB. Of course the ->write_end doesn't use it if the ->write_begin didn't initialise it, but it's too late because merely calling the function was UB. Thanks, Itanium!
diff --git a/fs/ext4/verity.c b/fs/ext4/verity.c index 3c640bd7ecaeb..30e3b65798b50 100644 --- a/fs/ext4/verity.c +++ b/fs/ext4/verity.c @@ -79,7 +79,7 @@ static int pagecache_write(struct inode *inode, const void *buf, size_t count, size_t n = min_t(size_t, count, PAGE_SIZE - offset_in_page(pos)); struct page *page; - void *fsdata; + void *fsdata = NULL; int res; res = aops->write_begin(NULL, mapping, pos, n, &page, &fsdata);