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

[Artem Dinaburg]

Hi Ted,

A quick update on generic/045:
we ran it another 200 times on each kernel in each of ext4/4k and ext4/1k.
All 800 runs passed:

                  Unpatched       With the jbd2 series
  ext4/4k         200/200 passed   200/200 passed
  ext4/1k         200/200 passed   200/200 passed

We kept the same kernel configuration and QEMU setup, with a fresh
guest and test disks for every run.

We also reviewed the kernel logs from both earlier generic/045
failures, passing runs, and all 800 new runs. During the test they
show only the shutdown and journal-abort messages that it deliberately
triggers, with no additional warning or stack trace at the failures.

Both failed tests reported files with nonzero size but no extents.
The logs do not explain why, and neither failure recurred in the
200 additional runs on each kernel. The earlier ext4/1k failure
occurred during the full suite, so running the test alone may miss
an interaction with earlier tests.

Thanks,
Artem Dinaburg

On Thu, Oct 15, 2026 at 4:01 PM Artem Dinaburg <artem@xxxxxxxxxxxxxxx> wrote:
>
> Hi Ted,
>
> > Note that some tests can be flaky. So when you see a test failure, it
> > can be useful to run a test multiple times
>
> Thanks for the advice. We are still working through the testing and
> wanted to send you a progress update.
>
> We have completed three full iterations of
> ext4/all,xfs/4k,btrfs/4k -g auto on the same unpatched 6.6.159-rc1
> baseline (72bada21be7b), followed by one full iteration with the
> submitted two-patch jbd2 series.
>
> We used QEMU/KVM with fresh guest and test disks for each
> configuration.
>
> Following your suggestion, we also completed ten focused trials on
> each kernel for 21 suspect configuration/test pairs: 420 trials in
> total. Each trial used a separately booted guest and fresh disks.
>
> In those ten runs on each kernel, we observed the following flaky
> tests. Counts below are failures out of ten, unpatched / patched:
>
> Flaky on both kernels:
>
>   btrfs/4k btrfs/028: 3 / 3
>   btrfs/4k btrfs/192: 7 / 6
>   btrfs/4k generic/449: 4 / 7
>   ext4/1k generic/051: 3 / 5
>   ext4/1k generic/388: 2 / 3
>   ext4/1k generic/475: 5 / 3
>   ext4/adv generic/455: 5 / 5
>   ext4/adv generic/482: 4 / 2
>   ext4/ext3 generic/388: 8 / 9
>
> Flaky on the unpatched kernel only:
>
>   ext4/bigalloc_4k generic/320: 2 / 0
>
> Flaky on the patched kernel only:
>
>   ext4/4k generic/045: 0 / 1
>
> We are now running 200 additional iterations of generic/045 on each
> kernel in each of ext4/4k and ext4/1k. Ten runs leave wide confidence
> intervals: a rare failure could easily have been missed on the
> unpatched kernel. The additional runs will let us estimate failure
> rates and their 95% confidence intervals to assess whether the test
> fails more often on the patched kernel. We will finish all planned
> runs before comparing the results.
>
>
> Thanks,
> Artem Dinaburg
>
> On Sat, Oct 10, 2026 at 7:54 PM Theodore Tso <tytso@xxxxxxx> wrote:
> >
> > On Sat, Oct 10, 2026 at 06:12:10PM -0500, Artem Dinaburg wrote:
> > >
> > > 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.
> >
> > Note that some tests can be flaky.  So when you see a test failure, it
> > can be useful to run a test multiple times, so you can see if the test
> > is a reliable hard failure, or one that only fails, say, 30% of the
> > time.  So to run generic/363 10 times in the ext4/1k configuration,
> > you might do soemthing like this:
> >
> >    kvm-xfstests -c ext4/1k generic/363 -C 10
> >
> >                                                 - Ted
> >