linux-ext4 - Re: [PATCH v2] ext4: Fix possible use-after-free in ext4_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y69E9DMEk+yEFDNQ@sol.localdomain>
Date:   Fri, 30 Dec 2022 12:07:16 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Tudor Ambarus <tudor.ambarus@...aro.org>
Cc:     tytso@....edu, adilger.kernel@...ger.ca,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        joneslee@...gle.com,
        syzbot+0827b4b52b5ebf65f219@...kaller.appspotmail.com,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] ext4: Fix possible use-after-free in ext4_find_extent

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