Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
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/

      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