linux-kernel - Re: kernel BUG in ext4_free

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: <Y5ylNxoN2p7dmcRD@mit.edu>
Date:   Fri, 16 Dec 2022 12:04:55 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     Lee Jones <lee@...nel.org>,
        syzbot <syzbot+15cd994e273307bf5cfa@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, gregkh@...uxfoundation.org,
        lczerner@...hat.com, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, sashal@...nel.org,
        stable@...r.kernel.org, syzkaller-android-bugs@...glegroups.com,
        tadeusz.struk@...aro.org
Subject: Re: kernel BUG in ext4_free_blocks (2)

On Fri, Dec 16, 2022 at 03:09:04PM +0100, Aleksandr Nogikh wrote:
> 
> Syzbot is actually reacting here to this bug from the Android namespace:
> 
> https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c

Thanks for the clarification; stupid question, though -- I see
"upstream" is listed on the dashboard link above.  Assuming that
"usptream" is "Linus's tree", why was it still saying, "I can't find
this patch in any of my trees"?  What about the upstream tree?

> > Although this does appear to be a Stable candidate, I do not see it
> > in any of the Stable branches yet.  So I suspect the answer here is to
> > wait for the fix to filter down.

The reason why it's not hit any of the long-term stable trees is
because the patch doesn't apply cleanly, because there are
pre-requisite commits that were required.  Here are the required
commits for 5.15:

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git ext4_for_5.15.83

% git log --reverse --oneline  v5.15.83..
96d070a12a7c ext4: refactor ext4_free_blocks() to pull out ext4_mb_clear_bb()
    [ Upstream commit 8ac3939db99f99667b8eb670cf4baf292896e72d ]
2fa7a1780ecd ext4: add ext4_sb_block_valid() refactored out of ext4_inode_block_valid()
    [ Upstream commit 6bc6c2bdf1baca6522b8d9ba976257d722423085 ]
8dc76aa246b1 ext4: add strict range checks while freeing blocks
    [ Upstream commit a00b482b82fb098956a5bed22bd7873e56f152f1 ]
deb2e1554497 ext4: block range must be validated before use in ext4_mb_clear_bb()
    [ Upstream commit 1e1c2b86ef86a8477fd9b9a4f48a6bfe235606f6 ]

Further backports to LTS kernels for 5.10, 5.4, etc., are left as an
exercise to the reader.  :-)

	     	   	      	       	     - Ted

P.S.  I have not tried to run gce-xfstests regressions yet. so the
only QA done on these backports is "it builds, ship it!"  (And it
fixes the syzbot reproducers.)  Then again, we're not running this
kind of regression tests on the LTS kernels.

P.P.S.  If anyone is willing to volunteer to be an ext4 backports
maintainer, please contact me.  The job description is (a) dealing
with the stable backport failures and addressing the patch conflicts,
potentially by dragging in patch prerequisites, and (b) running
"gce-xfstests ltm -c ext4/all -g auto" and making sure there are no
regressions.

	     	   		  	      - Ted