Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 30 Dec 2022 12:07:16 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Tudor Ambarus <tudor.ambarus@linaro.org>
Cc:     tytso@mit.edu, adilger.kernel@dilger.ca,
        linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
        joneslee@google.com,
        syzbot+0827b4b52b5ebf65f219@syzkaller.appspotmail.com,
        stable@vger.kernel.org
Subject: Re: [PATCH v2] ext4: Fix possible use-after-free in ext4_find_extent
Message-ID: <Y69E9DMEk+yEFDNQ@sol.localdomain>
References: <20221230062931.2344157-1-tudor.ambarus@linaro.org>
 <Y66LkPumQjHC2U7d@sol.localdomain>
 <cf1be149-392d-afa0-092a-c3426868f852@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cf1be149-392d-afa0-092a-c3426868f852@linaro.org>
Precedence: bulk

On Fri, Dec 30, 2022 at 01:42:45PM +0200, Tudor Ambarus wrote:
> 
> Seems that __ext4_iget() is not called on writes.

It is called when the inode is first accessed.  Usually that's when the file is
opened.

So the question is why didn't it validate the inode's extent header, or
alternatively how did the inode's extent header get corrupted afterwards.

> You can find below the sequence of calls that leads to the bug.

A stack trace is not a reproducer.  Things must have happened before that point.

- Eric