[PATCH 1/1] ubifs: fix slab-out-of-bounds in pack_inode via xattr

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1 at huawei.com>
> 在 2026/6/4 0:37, Ren Wei 写道:
>> From: Luxiao Xu <rakukuip at 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 at kernel.org
>> Reported-by: Yuan Tan <yuantan098 at gmail.com>
>> Reported-by: Yifan Wu <yifanwucs at gmail.com>
>> Reported-by: Juefei Pu <tomapufckgml at gmail.com>
>> Reported-by: Xin Liu <bird at lzu.edu.cn>
>> Signed-off-by: Luxiao Xu <rakukuip at gmail.com>
>> Signed-off-by: Ren Wei <n05ec at 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