From nobody Mon Apr 13 15:52:30 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEA78C4332F for ; Mon, 14 Nov 2022 21:23:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237731AbiKNVXn (ORCPT ); Mon, 14 Nov 2022 16:23:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237635AbiKNVXk (ORCPT ); Mon, 14 Nov 2022 16:23:40 -0500 Received: from mail-wr1-x44a.google.com (mail-wr1-x44a.google.com [IPv6:2a00:1450:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB39B3898 for ; Mon, 14 Nov 2022 13:23:39 -0800 (PST) Received: by mail-wr1-x44a.google.com with SMTP id r22-20020adfa156000000b0023660e969ddso2277305wrr.19 for ; Mon, 14 Nov 2022 13:23: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:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2s5p7qUTZoX+xCiO6iUkhANRSk/2v5qgG9igFsxp65M=; b=S2Kj3NDMntV93G0ZGOxCLd15RWQhiWng/uuFCMn+z5aAJGDLzXGR6qRQ47yO+p98ro F72bMYkbKOngtGU2MEr3YF9SERzf8wjuRoXDxhAAiO84bP8i5xdMDr8MvkxipXuhi2Ns YALre42dFlZ/SoncAScMZXjCC5WuhU//Zjb6Sqss5iRz47cj3LVzKEjEMPR8xiTy8A6O zw0ONphrScEMXVCo1d5q59zibgd2n/UfGY8jlqxanJgf265SdsZzvJWVVdbn0hF/vds8 LqmifXWvjIqfLLnvNwZJ8cw+qMzGjg/JfksX2547mWdENWGrvPMl3tz3bwligeBBi3G3 9rTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2s5p7qUTZoX+xCiO6iUkhANRSk/2v5qgG9igFsxp65M=; b=mJTpMGe9baxmXPM/9uuCuzEIHAb9nsF+cnQ5Y8n4ciip/oc/QfVz22lGZMpSrIDqLp 7f7fuPJ7ANQaAJexTBGGHNRtqD3vPq5EkUXvX5Jfi0sjEKsXDnEysXG++eNlNLwzfYvV QUNTpEIDIK1zcugCuPRzSZFCmbByVmWJU7MzvT0HhuJHso1WRNHMFM/KHMD2HYRTTQ6A mM5s0N5A/L94RbYQEbQj82QDtvzYQLJShiirGb2ff2F9ntjioeALiD7rHTV1JRh52uru zbv1K+4v2V3RKgOAQt4BFppbMzYibHLtrhxiUhozdEv/89XnJ+cF9VzYaNUlr4JKBXSS LDew== X-Gm-Message-State: ANoB5pnXl1AUlXi/ebnXJ4JZlrM62UQUgcgFHP/dSOJbc6DSdvnUDwdI oDnu/V97VqWsvGwdbGhIIPE6vvazr1Naj4oR X-Google-Smtp-Source: AA0mqf5EKCmkWZGF7y09cx0NacbNwoDjdVtNzN9rOEgej1Z8TUySZKlbZtnG1/6nuy2Hj79ADAXRNWdMt6C1GGPQ X-Received: from fkdev.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:3506]) (user=feldsherov job=sendgmr) by 2002:a05:600c:35c6:b0:3c2:7211:732e with SMTP id r6-20020a05600c35c600b003c27211732emr9326994wmq.191.1668461018405; Mon, 14 Nov 2022 13:23:38 -0800 (PST) Date: Mon, 14 Nov 2022 21:21:55 +0000 In-Reply-To: <20221114192129.zkmubc6pmruuzkc7@quack3> Mime-Version: 1.0 References: <20221114192129.zkmubc6pmruuzkc7@quack3> X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221114212155.221829-1-feldsherov@google.com> Subject: [PATCH v2] fs: do not update freeing inode io_list From: Svyatoslav Feldsherov To: Alexander Viro , Lukas Czerner , "Theodore Ts'o" , Jan Kara Cc: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com, oferz@google.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Svyatoslav Feldsherov Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE") writeiback_single_inode can push inode with I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with I_DIRTY_TIME set this can happened after deletion of inode io_list at evict. Stack trace is following. evict fat_evict_inode fat_truncate_blocks fat_flush_inodes writeback_inode sync_inode_metadata(inode, sync=3D0) writeback_single_inode(inode, wbc) <- wbc->sync_mode =3D=3D WB_SYNC_NONE This will lead to use after free in flusher thread. Similar issue can be triggered if writeback_single_inode in the stack trace update inode->io_list. Add explicit check to avoid it. Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_D= IRTY_INODE") Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com Signed-off-by: Svyatoslav Feldsherov Reviewed-by: Jan Kara --- V1 -> V2:=20 - address review comments - skip inode_cgwb_move_to_attached for freeing inode=20 fs/fs-writeback.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 443f83382b9b..c4aea096689c 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *ino= de, wb =3D inode_to_wb_and_lock_list(inode); spin_lock(&inode->i_lock); /* - * If the inode is now fully clean, then it can be safely removed from - * its writeback list (if any). Otherwise the flusher threads are - * responsible for the writeback lists. + * If the inode is freeing, it's io_list shoudn't be updated + * as it can be finally deleted at this moment. */ - if (!(inode->i_state & I_DIRTY_ALL)) - inode_cgwb_move_to_attached(inode, wb); - else if (!(inode->i_state & I_SYNC_QUEUED)) { - if ((inode->i_state & I_DIRTY)) - redirty_tail_locked(inode, wb); - else if (inode->i_state & I_DIRTY_TIME) { - inode->dirtied_when =3D jiffies; - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); + if (!(inode->i_state & I_FREEING)) { + /* + * If the inode is now fully clean, then it can be safely + * removed from its writeback list (if any). Otherwise the + * flusher threads are responsible for the writeback lists. + */ + if (!(inode->i_state & I_DIRTY_ALL)) + inode_cgwb_move_to_attached(inode, wb); + else if (!(inode->i_state & I_SYNC_QUEUED)) { + if ((inode->i_state & I_DIRTY)) + redirty_tail_locked(inode, wb); + else if (inode->i_state & I_DIRTY_TIME) { + inode->dirtied_when =3D jiffies; + inode_io_list_move_locked(inode, + wb, + &wb->b_dirty_time); + } } } =20 --=20 2.38.1.431.g37b22c650d-goog