[PATCH 0/5] ubifs: harden validation of on-disk inode and node metadata
Zhihao Cheng
chengzhihao1 at huawei.com
Mon Nov 2 20:50:59 PST 2026
在 2026/11/3 12:30, shao.mingyin at 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
> .
>
More information about the linux-mtd
mailing list