Re: [PATCH 0/5] ubifs: harden validation of on-disk inode and node metadata

[Zhihao Cheng <chengzhihao1@huawei.com>]

在 2026/11/3 12:30, shao.mingyin@zte.com.cn 写道:
>>   From my perspective, I'm not really interested in the problem scenarios
>> triggered by malicious fs image, let Richard decide whether to merge it.
>> This series does not seem to introduce any issues, there are two small
>> nits in patch 2&3.
> 
> Thanks for the review.  The threat model in the cover is the only one the
> series claims: mounting such an image needs CAP_SYS_ADMIN in the mounting
> namespace or access to the flash.
> 
> Two of the five are not strictly "malicious image only", in case that is
> useful for Richard's call:
> 
> - 4/5 is replay: a node that was corrupted on flash or written wrong would
>    otherwise let ubifs_recover_size() extend an inode to a bogus size.
> - 5/5 leaves the image unmountable after a single removexattr(): the
>    underflowed counters are written back to flash, so it survives remount.
> 
> The other three are mount-time validation of fields that validate_inode()
> and validate_master() already range-check for other values, so they change
> nothing for a valid image.  The patches are independent and any subset
> applies, so dropping some is fine -- I will leave the decision to Richard.
> 
> Both nits are taken: patch 2 folds the size check into the existing
> ui->xattr block, patch 3 merges the lower bound into the highest_inum
> check (that one then reports error 3 for both bounds).
> 
> For the series: I will repost only those two as [PATCH v2] in a new
> thread, each noting that it supersedes 2/5 or 3/5 of the v1 series.  1/5,
> 4/5 and 5/5 are untouched, so I would rather not resend them -- say the
> word if you would prefer the whole series as v2.
Resend v2 series please.
> 
> Thanks,
> Shao
> .
>