From: Chao Yu <chao@kernel.org>
To: hexlabsecurity@proton.me, Jaegeuk Kim <jaegeuk@kernel.org>
Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] f2fs: bound i_inline_xattr_size for non-inline-xattr inodes
Date: Tue, 16 Jun 2026 16:55:01 +0800 [thread overview]
Message-ID: <4e9c61d4-c942-4291-96cb-02455da05257@kernel.org> (raw)
In-Reply-To: <20260611-b4-disp-155e8807-v1-1-5d14dcc72b15@proton.me>
On 6/12/26 12:00, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> When the flexible_inline_xattr feature is enabled, do_read_inode() loads
> the on-disk i_inline_xattr_size unconditionally:
>
> if (f2fs_sb_has_flexible_inline_xattr(sbi))
> fi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size);
>
> but sanity_check_inode() only range-checks it when the inode also has the
> FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline
> data but not FI_INLINE_XATTR -- the normal layout for an inline
> directory -- therefore keeps a fully attacker-controlled
> i_inline_xattr_size from a crafted image.
>
> get_inline_xattr_addrs() returns that value with no flag gating, so it
> feeds the inode geometry:
>
> MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)
> NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)
> addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size
>
> A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY()
> negative, so make_dentry_ptr_inline() sets d->max (int) to a negative
> value. The inline directory walk then compares an unsigned long bit_pos
> against that negative d->max, which is promoted to a huge unsigned bound,
> and reads far past the inline area:
>
> while (bit_pos < d->max) /* fs/f2fs/dir.c */
> ... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ...
>
> Mounting a crafted image and reading such a directory triggers an
> out-of-bounds read in f2fs_fill_dentries(); the same underflow also
> corrupts ADDRS_PER_INODE for regular files.
>
> Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the
> flexible_inline_xattr feature is enabled -- i.e. whenever the value is
> loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE
> bound gated on inodes that actually carry an inline xattr, so legitimate
> inodes with i_inline_xattr_size == 0 are still accepted.
>
> Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
prev parent reply other threads:[~2026-06-16 8:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 4:00 Bryam Vargas via B4 Relay
2026-06-16 2:50 ` [f2fs-dev] " patchwork-bot+f2fs
2026-06-16 8:55 ` Chao Yu [this message]
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=4e9c61d4-c942-4291-96cb-02455da05257@kernel.org \
--to=chao@kernel.org \
--cc=hexlabsecurity@proton.me \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®