Please consider 83f99de1b7c0 ("ext2: fix race between setxattr and write back") for 5.10.y, 5.15.y, and 6.1.y

Please consider 83f99de1b7c0 ("ext2: fix race between setxattr and write back") for 5.10.y, 5.15.y, and 6.1.y

[Michael Bommarito]

Please consider the following already-mainlined fix for the stable
series listed below.

Upstream commit: 83f99de1b7c0dcfa42b211e5e40334b7ad786b36
Subject: ext2: fix race between setxattr and write back

This is a stable option-2 request for an already-mainlined fix. The
patch fixes a security-relevant bug pattern that remains present in the
listed stable branches in my current review.

Why this belongs in stable:
ext2_xattr_set2 allocates a block via the reservation window
concurrently with writeback (ext2_get_blocks), tripping rsv_window_dump
BUG() in ext2_try_to_allocate_with_rsv (panic/DoS); fix absent in the
checked stable branches and the unguarded reservation path plus
reservation-using xattr allocation are still present there.

Requested stable series:
- 5.10.y
- 5.15.y
- 6.1.y

Fresh stable check (2026-07-08):
- 5.10.y: 738ac465e4e9
  fix shape: absent; upstream diff: needs-adjustment
- 5.15.y: c86c4726e7f0
  fix shape: absent; upstream diff: needs-adjustment
- 6.1.y: 090666d3cc90
  fix shape: absent; upstream diff: needs-adjustment
- 6.6.y and newer checked longterms already have the fixed shape

The source-shape check looked for both the EXT2_ALLOC_NORESERVE xattr
allocation call and the matching reservation guard in fs/ext2/balloc.c.
Those are absent in the requested branches and present in the checked
6.6.y, 6.12.y, and 6.18.y branches.

Backport note:
The mechanical check above reports whether the upstream diff applies to
each listed branch as-is. Branches marked needs-adjustment may need an
equivalent stable backport rather than a straight cherry-pick.
The current upstream diff fails in fs/ext2/xattr.c at the same hunk on
5.10.y, 5.15.y, and 6.1.y, so an adjusted backport is expected for all
three requested series.

Impact: a local user with write access to an already-mounted writable
ext2 filesystem with user xattrs enabled can trigger a kernel BUG/oops
through user.* xattr churn and writeback pressure. I do not have evidence
for privilege escalation, code execution, or confidentiality/integrity
impact; this is an availability issue. My current CVSS 3.1 estimate for
that mounted-ext2 scope is 5.5.

Direct-tracking exposure in my current review includes Debian 11,
Debian 12, Amazon Linux 2023, and Android 13/14/15 GKI. Vendor trees
that do not directly track the above stable branches need separate
per-tree checks.

Primary touched files: fs/ext2/balloc.c, fs/ext2/xattr.c

No reproducer is included in this public stable request. I can provide
additional details privately if needed.

Re: Please consider 83f99de1b7c0 ("ext2: fix race between setxattr and write back") for 5.10.y, 5.15.y, and 6.1.y

[Theodore Tso]

On Thu, Jul 09, 2026 at 10:31:42PM -0500, Michael Bommarito wrote:
> Fresh stable check (2026-07-08):
> - 5.10.y: 738ac465e4e9
>   fix shape: absent; upstream diff: needs-adjustment
> - 5.15.y: c86c4726e7f0
>   fix shape: absent; upstream diff: needs-adjustment
> - 6.1.y: 090666d3cc90
>   fix shape: absent; upstream diff: needs-adjustment
> - 6.6.y and newer checked longterms already have the fixed shape


And this is why the patches have not been backported.  It requires
work, and an AI generated request doesn't change the reality that
*someone* has to do that work,

I invite you to figure out a way to figure out an AI mediated tool
that can attempt the backport, and then run the moral equivalent of
"gce-xfstests -c ext4.all -g auto" to verify that the backport doesn't
result in any regressions.  (Some previous attempts to backport to
older LTS kernels have resulted in the kernels crashing as a result.)

Otherwise, I recommend that most users consider switching to a newer
LTS kernel, or if they can't to pay $$$ to an enterprise Linux
distribution that pays engineers to do that hard work.

	     	       		       	    - Ted

Re: Please consider 83f99de1b7c0 ("ext2: fix race between setxattr and write back") for 5.10.y, 5.15.y, and 6.1.y

[Michael Bommarito]

On Fri, Jul 10, 2026 at 7:28 AM Theodore Tso <tytso@mit.edu> wrote:
> I invite you to figure out a way to figure out an AI mediated tool
> that can attempt the backport, and then run the moral equivalent of
> "gce-xfstests -c ext4.all -g auto" to verify that the backport doesn't
> result in any regressions.  (Some previous attempts to backport to
> older LTS kernels have resulted in the kernels crashing as a result.)

OK, done.  The whole set of scripts and results are in a GH gist at
[1] but the most important part is the subset of relevant fstests (see
ext2-testset.txt in [1]).  Everything was green against the targets I
listed.

branch   variant   pass  fail  notrun  timeout  dmesg   failures
5.10.y   stock       40     0      27        0  clean   -
5.10.y   patched     39     0      27        1  clean   -
5.15.y   stock       39     1      26        1  clean   generic/607
5.15.y   patched     39     1      26        1  clean   generic/607
6.1.y    stock       27     1      38        1  clean   generic/607
6.1.y    patched     27     1      38        1  clean   generic/607

Regression = a test that passes on stock but fails on patched.
  5.10.y: NO NEW FAILURES
  5.15.y: NO NEW FAILURES
  6.1.y : NO NEW FAILURES
OVERALL: PASS. The backport introduces no regressions in the ext2 surface.

If you think I missed any tests or you want to add a fuzzer/syzkaller,
lemme know.

[1] https://gist.github.com/mjbommar/c8ec6b6025d054e453625a06806459fc

Thanks,
Mike