From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDA6937E5ED; Mon, 14 Sep 2026 05:53:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789365203; cv=none; b=ByTk5ko2DxNKyPDgx7fdrku2yzR9f5L09hTy2ckEHGXo3FEO3ghtF9QiK5vnnbnfvReId9xeJ3kB/JZkIyf/r/EtO+ntaDkwXFgWONcGTNp5tl1mcZhmVqjL1EBc5FiU4HSC6bJiEQdDp2IHrD31IKgqaTcQyV2+Hu8XWF2krt4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789365203; c=relaxed/simple; bh=5xKfAPsDRZgRWSGT3oeGlbWjQJ8pKeZkLHnc8er54f0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HfaK7RDvUcTfd2BFxCJh6VoV9u1n7N9qHJ0OfSnh+W96lSJPP4nEY7juHudLAnEuKu/fG2nVciA2n6AAPpwVqlREG9ZsSCdngxDYjQNIpZCfTQH8lUDe5RRAHnBvFbYAU9Dd5uUWsVdsyWcjZ9+Cj9HjvK9Ws/KN+r6xJjtSML0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=UQvVZOxE; arc=none smtp.client-ip=115.124.30.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="UQvVZOxE" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1789365184; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=DGCUqYpSgp6dwqHfummvsIu0f3GHTB/sFbpAB8I2TaM=; b=UQvVZOxE96EaeRMznHKhXp5D4G2zdepOcmJ3vnpvc04vJ0b6yzZtA7rLbBOamAJ1v8Clx9pdPKOqi0+3DLQQB8tZvsf8EZr8yWyF9ih2ZF16Fj07vdjcpQFbjKzgwcrUoim45XxMPSJ0KGJuUUrICadcBN9o08u8gHujjPAwMCs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0XAqpvuP_1789365183; Received: from 30.221.129.199(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0XAqpvuP_1789365183 cluster:ay36) by smtp.aliyun-inc.com; Mon, 14 Sep 2026 13:53:03 +0800 Message-ID: Date: Mon, 14 Sep 2026 13:53:02 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ocfs2: don't let the root inode outlive a failed mount To: Farhad Alemi , Mark Fasheh , Joel Becker Cc: falemi@asu.edu, ocfs2-devel@lists.linux.dev, Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org References: From: Joseph Qi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 9/11/26 5:47 AM, Farhad Alemi wrote: > ocfs2_init_global_system_inodes() installs osb->root_inode before the > second ocfs2_iget() runs, and when that iget fails ocfs2_initialize_super() > jumps to out_dlm_out, which sits below out_system_inodes, so > ocfs2_release_system_inodes() never runs and the kfree(osb) that follows > makes the stranded root inode reference unreachable. ocfs2_fill_super() > strands the same inode a second way: nothing drops the reference igrab() > takes on osb->root_inode when an out_dismount path ahead of d_make_root() > is taken, so the ocfs2_release_system_inodes() call inside > ocfs2_dismount_volume() cannot free it and the root inode stays hashed on a > superblock whose ocfs2_super has already been freed. The reported KASAN > slab-use-after-free write hits an ocfs2_inode_cache object that > ocfs2_release_system_inodes() freed during teardown, so an ocfs2 inode > reference that survives that call is a lifetime error on those same objects > and not a bare leak. Release the system inodes at that failing > ocfs2_iget() and drop the igrab() reference on out_dismount, clearing inode > right after d_make_root(), which consumes it on success and on failure > alike, so it cannot be dropped twice. > > Closes: https://lore.kernel.org/all/CA+0ovCjAKQMn7iF8BJR-3+G9_HBRnRFtJxjr-9P9GuKSxFj+3Q@mail.gmail.com/ > Signed-off-by: Farhad Alemi > --- > --- a/fs/ocfs2/super.c > +++ b/fs/ocfs2/super.c Seems it is a corrupt patch? > @@ -450,6 +450,7 @@ static int ocfs2_init_global_system_inodes(struct > ocfs2_super *osb) > if (IS_ERR(new)) { > status = PTR_ERR(new); > mlog_errno(status); > + ocfs2_release_system_inodes(osb); > goto bail; > } > osb->sys_root_inode = new; > @@ -1110,6 +1111,8 @@ static int ocfs2_fill_super(struct super_block > *sb, struct fs_context *fc) > } > > root = d_make_root(inode); > + /* d_make_root() consumed our reference, on success and on failure. */ > + inode = NULL; > if (!root) { > status = -ENOMEM; > goto out_dismount; > @@ -1163,6 +1166,7 @@ out_dismount: > atomic_set(&osb->vol_state, VOLUME_DISABLED); > wake_up(&osb->osb_mount_event); > ocfs2_free_replay_slots(osb); Please rebase on top of the latest linux-next. The above 'ocfs2_free_replay_slots(osb)' is removed. Thanks, Joseph > + iput(inode); > ocfs2_dismount_volume(sb, 1); > goto out;