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

[Richard Weinberger]

----- 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.

Thanks,
//richard