[PATCH 0/2] md: fix bblog_size-driven OOB read in md_write_metadata()

[zjamg <ndaugoing@gmail.com>]

Hi,

This series fixes an out-of-bounds read in the md badblocks log (bblog)
write path. The on-disk bblog_size field is taken verbatim from the
member device superblock and used as the bio length in
md_write_metadata(), without any check against the size of the page that
actually backs the write.

This is a different issue from CVE-2026-89557, which fixed the
bblog_shift overflow. The bblog_size path is still unfixed.

Introduced by commit 2699b67223ac ("md: load/store badblock list from v1.x metadata").

Mechanism:

  super_1_load() reads sb->bblog_size (__le16) from the member device
  and stores it in rdev->badblocks.size via super_1_sync() (md.c:2316).
  md_update_sb() then calls

      md_write_metadata(mddev, rdev, rdev->badblocks.sector,
                        rdev->badblocks.size << 9, rdev->bb_page, 0);

  (md.c:2944-2948). bb->size is sector_t, so 0xFFFF << 9 = 33553920
  does not wrap. md_write_metadata() passes that length to
  __bio_add_page() with a single 4 KiB page:

      __bio_add_page(bio, page, size, 0)

  __bio_add_page() is the no-check variant: after a WARN_ON_ONCE() it
  unconditionally records bvec_set_page(page, size, offset) and bumps
  bi_size/bi_vcnt. bio_full()'s second clause is
  "bi_size > BIO_MAX_SIZE - len", with bi_size == 0 and
  BIO_MAX_SIZE == UINT_MAX, so it is false and not even the WARN fires.
  The 4 KiB page is recorded as a bvec with bv_len == 33553920.

Downstream bvec iteration (nth_page, bio_split_to_limits, etc.) then
reads past the end of the page, into whatever follows in the linear
map. KASAN reports slab-out-of-bounds or slab-use-after-free, and the
data is written to the attacker-controlled member device.

Reproducer (CONTROL/ATTACK, only bblog_size differs):

  CONTROL bblog_size = 8      -> 4096 bytes land, out-of-range stays
                                 at the fill pattern
  ATTACK  bblog_size = 0xFFFF -> 33553920 bytes land, KASAN reports
                                 slab-out-of-bounds in
                                 copy_folio_from_iter_atomic(), and
                                 ~33.5 MB of kernel memory is copied
                                 into the member device image

The harness creates the on-disk superblock by hand, attaches the loop
device, binds it to a new md array via sysfs, adds one bad block, and
then writes "writemostly" to the member state attribute to force an
md_update_sb(). Both runs share the same kernel, the same md module and
the same code path; the only difference is the bblog_size field in the
on-disk superblock.

Patch 1 adds an upper bound for bb->size in super_1_sync(), matching
the existing guard in super_1_load().

Patch 2 is a defensive check in md_write_metadata() itself, so that
any future caller that passes an oversized length is caught before the
bio is built. Only one of the two is strictly needed to fix the
immediate issue; I'm sending both because the checks cover different
layers.

I can send the harness and full dmesg logs if useful.

Thanks.


zjamg (2):
  md: fix bblog_size-driven OOB read in super_1_load() and
    super_1_sync()
  md: add defensive bounds check for bio in md_write_metadata()

 drivers/md/md.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

-- 
2.53.0