Two bug fix commit fixes in the ubi_resize_volume() were fixed by a patch in the mailing list

[Guo Xuenan]

Hi Richard，

On 2023/4/6 4:48, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "chengzhihao1" <chengzhihao1 at huawei.com>
>>>       I'd like to know why patch[1] didn't get into the mainline.
>>>
>>> [1] http://patchwork.ozlabs.org/project/linux-mtd/patch/20220124024056.1996763-1-guoxuenan@huawei.com/
> Sorry, it fell through the cracks.
>
>> I find there were three problems in ubi_resize_volume():
>>
>> 1. Memleak  - fixed by 1e591ea072df ("ubi: Fix unreferenced object
>> reported by kmemleak in ubi_resize_volume()")
> Agreed.
>
>> 2. UAF in error handling path  - fixed by 9af31d6ec1a4 ("ubi: Fix
>> use-after-free when volume resizing failed")
> Agreed.
>
>> 3. UAF in concurrent shring volume and writing
>> fastmap(vol->reserved_pebs iteration)  - fixed by [1]
>> 4. Potentional data lost in failed shrinking(failed after unmapping
>> lebs)  - mentioned in [1], which is not a big problem, we can add some
>> comments to explain it.
>> 5. Too many lebs used if expanding volume failed after [1] applied:
>> If we update vol->reserved_pebs together with vol->eba_tbl, then other
>> writing process could take lnum bigger than old vol->reserved_pebs.
>> There will be zombie logical pebs(lnum greater than vol->reserved_pebs,
>> could not be accessed or reclaimed) if resizing failed.
>> Maybe we should fix that by holding 'leb_write_lock' while expanding volume?
>> 6. In error handling path 'out_acc', UBI should recover 'ubi->rsvd_pebs'
>> and 'ubi->avail_pebs' in 'pebs > 0' case, otherwise UBI will display
>> wrong available peb count.
>>
>> Richard, How do you think?
> I agree, we should apply this patch. Guo Xuenan, can you please rebase your patch
> on the latest kernel and resend?
> vmt.c saw some changes and the patch does not longer apply.
OK，I will ask my colleagues Zhaolong Wang to help me rebase and resend 
it as soon as
possible，he is currently more focused on ubifs :)

Thanks
Xuenan
> Thanks,
> //richard
>