All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ana Bobillo <anabobillo3@gmail.com>
To: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.u-boot-project.org, Tony Dinh <mibodhi@gmail.com>,
	Simon Glass <sjg@chromium.org>
Subject: [PATCH 0/6] fs: ext4: check on-disk values in the write path
Date: Sun, 08 Nov 2026 15:11:50 +0000	[thread overview]
Message-ID: <5072bec2-e2e3-405d-91eb-58fe78ea6669@gmail.com> (raw)

When ext4write (or saveenv with the environment on ext4) writes to a
filesystem, it walks the parent directory's block and the journal by
values it reads from the image. A corrupt or crafted image can then make
it write a directory entry past the end of its block buffer, overflow
the fixed journal entry tables, or loop for ever in the journal scan
that runs before every write. The write path also takes the first data
block to be the one mke2fs makes, while ext4fs_blk_to_group() reads it
from the superblock, so that the two can disagree on the block group of
a block.

This series follows "fs: ext4: check on-disk indices before using them"
v2, which covers the read path and the delete path, and applies on top
of it:
https://patchwork.ozlabs.org/project/uboot/list/?series=530226

1. the write path refuses a first data block other than the one its
   bitmap code assumes, so that ext4fs_blk_to_group() and the bitmap
   code always agree on the group of a block
2. ext4fs_get_new_blk_no() uses ext4fs_blk_to_group(), as Simon
   suggested on that series, after a quiet check for the end of the
   filesystem
3. directory entries: one helper checks that each entry lies inside its
   block and that its length covers its name, and the three functions
   that walk a directory block (the walk that adds a name, search_dir()
   and unlink_filename()) use it
4. the journal entry tables: every function that adds an entry checks
   for room, counting the entries already used, and a transaction logs
   no more blocks than one descriptor block has tags for
5. the journal scan ends at a block without the journal magic, of an
   unknown type, unmapped or past the end of the journal, or at a revoke
   block whose count is larger than the block
6. tests in test/py for 1, 3 and 5

With sandbox_defconfig and CONFIG_ASAN, on the earlier series the new
directory test corrupts the heap (dlmalloc's check fails, "Assertion
`inuse(p)' failed"), the journal test times out in the scan, and the
first data block test replaces the file, which under valgrind reads one
byte past the end of a block bitmap in ext4fs_reset_block_bmap(); with
this series all three pass. The existing ext4 tests still pass with
--fs-type ext4. Writing files to filesystems of several block groups
until they are full, with 1 KiB and 4 KiB blocks, with and without
extents, gives the same block counts as without this series, and
e2fsck finds them clean.

The journal table limit only bites on filesystems with very many block
groups, so no test makes one; with the default of 100 entries a normal
write uses a handful.

CI: the series passes all 91 jobs of U-Boot's Azure pipeline, in build
13738 of my CI-only pull request, on top of the ext4 v2 above (Patchwork
series 530226) on main feb8913982e.
PR:    https://github.com/u-boot/u-boot/pull/1064
Build: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=13738

Ana Bobillo (6):
  fs: ext4: refuse to write with an unexpected first data block
  fs: ext4: use ext4fs_blk_to_group() in ext4fs_get_new_blk_no()
  fs: ext4: check directory entries before using them
  fs: ext4: bound the journal entry tables
  fs: ext4: stop the journal scan at the end of the log
  test: fs: ext4: add tests for the write path checks

 fs/ext4/ext4_common.c                 | 122 ++++++++++++++++----------
 fs/ext4/ext4_journal.c                | 105 +++++++++++++++-------
 fs/ext4/ext4_write.c                  |  13 ++-
 test/py/tests/test_fs/test_ext_oob.py | 115 +++++++++++++++++++++++-
 4 files changed, 270 insertions(+), 85 deletions(-)


base-commit: 8649a54d301a4d0ac526324c7a7ad2574939ff27
prerequisite-patch-id: d5a6719867877bf4c0422833eee0bf2cc5aaaab8
prerequisite-patch-id: b835c6b7cdb7863c6f71d94f725f072fffdaa24a
prerequisite-patch-id: 117c9e973a140f08733823f076375012f7f0c285
prerequisite-patch-id: 2ed9cf40521d69baa52454f829bcd1d1da991892
prerequisite-patch-id: 7fa629dd32831d8e39db5f23ab2131a84ed097af
prerequisite-patch-id: b53bdb663aab3246d5ddecf18de1ae73e30fe6a5

             reply	other threads:[~2026-11-08 15:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 15:11 Ana Bobillo [this message]
2026-11-08 15:11 ` [PATCH 1/6] fs: ext4: refuse to write with an unexpected first data block Ana Bobillo
2026-11-08 15:12 ` [PATCH 2/6] fs: ext4: use ext4fs_blk_to_group() in ext4fs_get_new_blk_no() Ana Bobillo
2026-11-08 15:12 ` [PATCH 3/6] fs: ext4: check directory entries before using them Ana Bobillo
2026-11-08 15:12 ` [PATCH 4/6] fs: ext4: bound the journal entry tables Ana Bobillo
2026-11-08 15:12 ` [PATCH 5/6] fs: ext4: stop the journal scan at the end of the log Ana Bobillo
2026-11-08 15:12 ` [PATCH 6/6] test: fs: ext4: add tests for the write path checks Ana Bobillo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5072bec2-e2e3-405d-91eb-58fe78ea6669@gmail.com \
    --to=anabobillo3@gmail.com \
    --cc=mibodhi@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.u-boot-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.