[BUG] ufs: crafted writable mount can overflow cylinder summary buffer

[이상호]

Hello,

I am reporting a UFS/FFS mount-time memory corruption issue in
ufs_read_cylinder_structures().

A crafted UFS/FFS filesystem image can set inconsistent cylinder-summary
geometry so that the kernel allocates kmalloc(s_cssize) but copies more than
that allocation while reading cylinder summary blocks during a writable UFS
mount.

Relevant vulnerable code shape:

    size = uspi->s_cssize;
    blks = (size + uspi->s_fsize - 1) >> uspi->s_fshift;
    base = space = kmalloc(size, GFP_NOFS);
    ...
    memcpy(space, bh->b_data, uspi->s_fsize);
    space += uspi->s_fsize;

ufs_fill_super() validates fs_fsize, but the current path does not reject
inconsistent fs_fshift / fs_cssize before the copy loop. With a crafted image I
can trigger a KASAN-confirmed slab out-of-bounds write.

Observed KASAN evidence:

    BUG: KASAN: slab-out-of-bounds in ufs_read_cylinder_structures+0x22e/0xdf0
    Write of size 1024 at addr ffff888019837800 by task init/1
    allocated 520-byte region [ffff888019837800, ffff888019837a08)
    which belongs to the cache kmalloc-1k of size 1024

The tested image geometry causes a 520-byte logical allocation and a 1024-byte
copy, so the observed overflow is 504 bytes beyond the allocation.

Trigger requirements:

    - CONFIG_UFS_FS=y or CONFIG_UFS_FS=m
    - CONFIG_UFS_FS_WRITE=y
    - writable UFS mount of attacker-supplied media
    - normally CAP_SYS_ADMIN or equivalent mount exposure

Impact assessment:

    - Kernel memory corruption is confirmed by KASAN.
    - The copied source bytes are attacker-influenced through filesystem block
      contents.
    - The write is a forward contiguous overflow from the allocated
      cylinder-summary buffer, not an arbitrary address write.
    - I have not demonstrated arbitrary write, control-flow control, or
      privilege escalation.
    - In a derived non-KASAN UFS-write test kernel, the same image reached the
      end of the trigger program without visible panic/oops/hang in 3/3 runs,
      so this exact reproducer is not a stable non-KASAN crash reproducer in my
      local VM.

Patch validation:

    - A local patch that rejects inconsistent s_fshift and s_cssize before
      ufs_read_cylinder_structures() prevents the issue.
    - With the patch, the malformed image is rejected with:

          ufs: ufs_fill_super(): invalid cylinder summary size 520
          mount ret=-1 errno=22 (Invalid argument)

    - The same rejection was observed in both KASAN and non-KASAN local VM
      replays.
    - The patch applies cleanly to my checked mainline/stable trees.

Disclosure/context:

    - I found a public third-party writeup that appears to describe the same
      UFS issue:

          https://psn.af/k/17/

    - Because of that public collision, I am treating this as public/fix-first
      rather than embargoed.
    - I am not attaching the crafted filesystem image to this initial mail, but
      I can provide the full KASAN log, local replay logs, and reproducer image
      privately to maintainers if requested.

Suggested conservative impact wording:

    A crafted UFS/FFS filesystem image can trigger a KASAN-confirmed slab
    out-of-bounds write in ufs_read_cylinder_structures() when mounted writable
    on kernels built with CONFIG_UFS_FS_WRITE=y. The issue is reachable by a
    mount-capable attacker or by environments that otherwise expose writable
    UFS mounting of attacker-supplied images. Practical privilege escalation
    was not demonstrated.

I have a proposed patch prepared locally:

    patches/ufs-cssize-fshift-oob-reject.patch

If preferred, I can resend this as a proper inline [PATCH] generated with
git send-email.

Thanks,