From: Richard Weinberger <richard@nod.at>
To: chengzhihao1 <chengzhihao1@huawei.com>
Cc: Ren Wei <n05ec@lzu.edu.cn>,
linux-mtd <linux-mtd@lists.infradead.org>,
yuantan098 <yuantan098@gmail.com>,
yifanwucs <yifanwucs@gmail.com>,
tomapufckgml <tomapufckgml@gmail.com>, bird <bird@lzu.edu.cn>,
rakukuip <rakukuip@gmail.com>
Subject: Re: [PATCH 1/1] ubifs: fix slab-out-of-bounds in pack_inode via xattr
Date: Thu, 4 Jun 2026 09:08:22 +0200 (CEST) [thread overview]
Message-ID: <1688028359.62549.1780556902621.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <838ee423-c57d-51a1-0524-6e0d585a2a29@huawei.com>
----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@huawei.com>
> 在 2026/6/4 0:37, Ren Wei 写道:
>> From: Luxiao Xu <rakukuip@gmail.com>
>>
>> An issue in fs/ubifs/journal.c was found where a malicious or corrupted
>> ubifs image could trigger a slab-out-of-bounds write in pack_inode().
>>
>> When an inode with extended attributes (xattrs) is being evicted or
>> deleted (i.e., 'last_reference' and 'kill_xattrs' are true),
>> ubifs_jnl_write_inode() calculates the allocation size 'write_len'
>> based on 'ui->xattr_cnt' from the disk.
>>
>> However, if 'ui->xattr_cnt' is maliciously tampered with or corrupted
>> to be smaller than the actual number of xattr entries stored in the
>> TNC (Tree Node Cache), kmalloc() will allocate an undersized buffer.
>> The subsequent 'while (1)' loop continues to iterate through all actual
>> xattr entries via ubifs_tnc_next_ent(), advancing the 'ino' pointer
>> and invoking pack_inode() for each entry. This mismatch leads to an
>> out-of-bounds memory write, corrupting the slab redzone and triggering
>> a KASAN panic.
>>
>> Fix this by introducing a strict counter 'xattrs_deleted' within the
>> deletion loop. The loop is aborted with -EUCLEAN if the number of
>> processed xattrs exceeds 'ui->xattr_cnt', preventing 'ino' from
>> overflowing the allocated kmalloc buffer.
>>
>> The bug is reachable by a non-root user via user and net namespace.
As I wrote in my reply to 0/1, I'm not so sure about that.
To load a MTD and mount UBIFS you need to be the real root.
>>
>> Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
>> Cc: stable@kernel.org
>> Reported-by: Yuan Tan <yuantan098@gmail.com>
>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>> Reported-by: Xin Liu <bird@lzu.edu.cn>
>> Signed-off-by: Luxiao Xu <rakukuip@gmail.com>
>> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
>> ---
>> fs/ubifs/journal.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>
> Hi Luxiao,
> Each metadata(inode/dentry) entry will checked with crc while loading
> from flash(see ubifs_read_node->ubifs_check_node), I don't think
> corrupted image will trigger the problem, because
> ubifs_lookup->ubifs_iget will fail after detecting crc error. Unless
> someone manually inject wong number into 'ui->xattr_cnt' fieled and
> update the whole ino node crc, and I don't think it is a real problem
> need to be fixed. In that injection method, no one filesystem is okay.
> The bitflips happen both in node field(eg. xattr_cnt) and crc field is
> an almost impossible thing.
Well, if we can easily detect this case, let's fix it. UBIFS tries hard
to make sure the underlaying data structures are correct.
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2026-06-04 7:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1780496711.git.rakukuip@gmail.com>
2026-06-03 16:37 ` [PATCH 1/1] ubifs: fix slab-out-of-bounds in pack_inode via xattr Ren Wei
2026-06-04 4:57 ` Zhihao Cheng
2026-06-04 7:08 ` Richard Weinberger [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=1688028359.62549.1780556902621.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=bird@lzu.edu.cn \
--cc=chengzhihao1@huawei.com \
--cc=linux-mtd@lists.infradead.org \
--cc=n05ec@lzu.edu.cn \
--cc=rakukuip@gmail.com \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
/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