Re: [PATCH 6.6.y 0/2] jbd2: backport CVE-2026-89566, CVE-2026-89567

["Theodore Tso" <tytso@mit.edu>]

On Thu, Oct 08, 2026 at 03:20:44PM -0500, Artem Dinaburg wrote:
> Hi Greg, Sasha, and maintainers,
> 
> I'm working through the smaller CVE backports still missing from 6.6.y.
> These 2 upstream changes belong together for CVE-2026-89566,
> CVE-2026-89567. They must be applied in this order because the later change
> depends on or completes the earlier one.

Note that some of the 6.1 and 6.6 LTS backports in the past have
caused ext4 test regressions.  Since I don't have the time to track
down said ext4 regressiions (the last one took a week of my time,
because bisects are painful, and even after I bisected it down to the
guilty commit, figuring out out to safely revert it also took a lot of
time), I've largely given up on those LTS releases.

In addition, many corporate security folks are advising that it's
Simply Not Safe to use an LTS as old as 6.6, because even if you are
trying to address the 6.6 ext4 CVE's, there are plenty of other CVE's
that don't necessarily get backported, leaving those older LTS kernels
vulnerable.  But if you do have a real business need to use 6.6 LTS,
would you be interested in taking over managing the 6.6 ext4 stable
backports?

It's a lot easier to revert ext4 patches if the regressions are noted
promptly, and so the easist way to do this would be to use
gce-xfstests[1].   I can send you the results of running:

    gce-xfstests ltm -c ext4/all,xfs/4k,btrfs/4k -g auto --repo stable-rc.git --watch linux-6.6.y

... or you can run it yourself if you like.

[1] https://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/tree/master/Documentation/gce-xfstests.md

If you see failures in the latest stable-rc.git which are not in
previous test runs, then promply send a note (within 48 hours) to the
stable maintainers asking them to drop all of the ext4 and jbd2
patches that were sent to the latest stable-rc.  You can then spend
time, at your leisure, figuring out which of the ext4/jbd2 patches
caused the regressions, and then either fix them up or skip them and
send the rest to the stable maintainers.

If you see test regressions which *also* impact the xfs and btrfs
trees, then it's likely that the bug is in the vfs and mm backported
patches, so there won't be a need to request that the ext4 patches get
dropped from the stable-rc --- but if there is a test regression
impacting ext4, xfs, and btrfs, and you want to use 6.6 in production,
this might still be an issue for your company.

> The complete series is already present in 6.12.y, 6.18.y, and 7.2.y.
> These fixes also affect 6.1.y, which will need a separate backport; this
> series is only for 6.6.y.
>
> Could you please consider this series for 6.6.y?

If you haven't tried running xfstests to verify that your patches
don't cause any regressions, I strongly recommend it.  I won't NAK the
patches if you haven't, but that's because in my personal opinion, I
strongly recommend **against** using 6.1 and 6.6, and I've given up
trying to provide any ext4 support for 6.1 and 6.6 --- I just don't
have the time.  I barely have the time to pay attention to 6.12 and
6.18 LTS kernels, and those are only best efforts on my part.

Cheers,

						- Ted

P.S.  And if anyone would like to volunteer to be the ext4 stable
maintainers for 6.12 and 6.18 (and 7.3 or 7.4 when the next LTS is
declared) they would have my undying gratitude.  :-) And the newer LTS
kerenls should be much less work than the older LTS kernels, since the
chances for regressions (and the work involved in trying to track down
the regressions) are much less.

P.P.S.  It's because of the risk of regressions than XFS has opted out
from LTS backports.  A few years back, a few companies (including my
own) contributed engineering resources to test XFS patches and only
sending patches that were verified to not cause regressions to the LTS
kernels.  Unfortunately, all of the companies decided it wasn't worth
the SWE costs, and so the XFS stable backports project collapsed.  I
am happy to help provide the VM resources for a future XFS stable
backports effort, since the VM costs are relatively modest.  It's the
SWE time which is significant burden, whether it's coming out of
company funded time, or out of volunteer time late at night or on
weekends....