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

[Artem Dinaburg]

Hi Ted,

Thanks for pointing us to xfstests and gce-xfstests. We had not
included this regression coverage in our validation, and we appreciate
you explaining both the testing approach and the stable-rc review
process.

We are going to start including filesystem regression testing to our
backport checks, and started your recommended ext4/all, XFS/4k and
Btrfs/4k auto matrix locally under QEMU/KVM.

Our initial unpatched/patched runs showed some differences in both
directions. We cannot yet attribute those to the series, so we have
paused the patched comparison and are running three complete
iterations on the same unpatched baseline to assess repeatability.

We will follow up once we have firmer results.

Thanks,
Artem Dinaburg

On Fri, Oct 9, 2026 at 2:30 PM Theodore Tso <tytso@xxxxxxx> wrote:
>
> 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....