All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: YANXIN LI <fadouse@pm.me>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	security@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] ufs: use u64 for directory size in ufs_last_byte
Date: Tue, 1 Sep 2026 16:35:33 -0700	[thread overview]
Message-ID: <20260901163533.b1e7d802d709f79e10730f3e@linux-foundation.org> (raw)
In-Reply-To: <20260718190300.867109-1-fadouse@pm.me>

On Sat, 18 Jul 2026 19:03:07 +0000 YANXIN LI <fadouse@pm.me> wrote:

> ufs1_read_inode() and ufs2_read_inode() copy the untrusted 64-bit
> on-disk size into inode->i_size.  ufs_last_byte() then truncates that
> value to an unsigned int before calculating the valid extent of a
> directory folio.
> 
> A directory size of exactly 4 GiB is truncated to zero.  In
> ufs_find_entry(), subtracting the requested record length from that zero
> forms an endpoint almost 4 GiB beyond the mapped folio.  A crafted UFS2
> image produces:
> 
>   BUG: KASAN: use-after-free in ufs_find_entry+0x583/0x6e0 [ufs]
>   Read of size 1
>   ...
>   ufs_find_entry
>   ufs_inode_by_name
>   ufs_lookup
>   __lookup_slow
>   path_lookupat
> 
> The KASAN classification reflects that the adjacent physical page was
> free; the source-level operation is an out-of-folio read.  A controlled
> UFS1 test with CONFIG_UFS_FS_WRITE enabled also made ufs_find_entry()
> return a directory entry from an adjacent anonymous page.  unlink() then
> passed that pointer to ufs_delete_entry(), which cleared the adjacent
> page's 3
> 2-bit d_ino.  This write result reproduced three out of three
> times.
> 
> UFS normally requires a privileged mount path.  A relevant boundary is
> a privileged automounter or image-processing service handling an
> attacker-supplied filesystem.  The write primitive additionally requires
> UFS1 to be mounted read-write with CONFIG_UFS_FS_WRITE enabled; the read
> is reachable with read-only UFS2.
> 
> Keep the intermediate size arithmetic at 64 bits so non-final pages are
> bounded at PAGE_SIZE.  With this change, the same controlled tests reach
> the real on-disk directory entry and produce no adjacent-page write or
> KASAN report.  A reproducer and full validation logs are available on
> request.
> 
> The vulnerable helper is present in v7.2-rc3, v7.1, v6.18.38, v6.12.95,
> v6.6.111, and upstream master at 1229e2e57a5c.  Runtime reproduction and
> fix validation were performed in an x86-64 QEMU guest running v7.2-rc3
> with generic KASAN.
> 
> Fixes: b71034e5e67d ("[PATCH] ufs: directory and page cache: from blocks to pages")
> Cc: stable@vger.kernel.org

Thanks.

fs/ufs is far from my comfort zone, but since you cc'ed me ;)

I'll add this to mm.git and linux-next for testing and shall forward it
on to the relevant maintainers.


  parent reply	other threads:[~2026-09-01 23:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-18 19:03 [PATCH] ufs: use u64 for directory size in ufs_last_byte YANXIN LI
2026-07-27 11:13 ` Jan Kara
2026-09-01 23:35 ` Andrew Morton [this message]
2026-09-04 11:03 ` Christian Brauner

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=20260901163533.b1e7d802d709f79e10730f3e@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=fadouse@pm.me \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.