Re: [edk2-platforms][PATCH v1 00/12] Ext4Pkg: Code correctness and security improvements

["Savva Mitrofanov" <savvamtr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

Hi! 

Thanks for your review, I did changes in my branch of edk2-platforms and will send corrected patchset soon.

Best regards,
Savva Mitrofanov

> On 10 Dec 2022, at 04:28, Pedro Falcato <pedro.falcato@gmail.com> wrote:
> 
> On Fri, Dec 9, 2022 at 4:11 PM Savva Mitrofanov <savvamtr@gmail.com <mailto:savvamtr@gmail.com>> wrote:
> Hi all,
> 
> This patchset fixes several code problems found by fuzzing Ext4Dxe like
> buffer and integer overflows, memory leaks, logic bugs and so on.
> 
> REF: https://github.com/savvamitrofanov/edk2-platforms/tree/master <https://github.com/savvamitrofanov/edk2-platforms/tree/master>
> 
> Cc: Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>>
> Cc: Pedro Falcato <pedro.falcato@gmail.com <mailto:pedro.falcato@gmail.com>>
> Cc: Vitaly Cheptsov <vit9696@protonmail.com <mailto:vit9696@protonmail.com>>
> 
> Savva Mitrofanov (12):
>   Ext4Pkg: Fix memory leak in Ext4RetrieveDirent
>   Ext4Pkg: Move EXT4_NAME_MAX definition to Ext4Disk.h
>   Ext4Pkg: Fix global buffer overflow in Ext4ReadDir
>   Ext4Pkg: Fix incorrect checksum metadata feature check
>   Ext4Pkg: Fix division by zero by adding check for s_inodes_per_group
>   Ext4Pkg: Add comparison between Position and FileSize in
>     Ext4SetPosition
>   Ext4Pkg: Add inode number validity check
>   Ext4Pkg: Fix shift out of bounds in Ext4OpenSuperblock
>   Ext4Pkg: Correct integer overflow check on multiplication in DiskUtil
>   Ext4Pkg: Check that source file is directory in Ext4OpenInternal
>   Ext4Pkg: Check VolumeName allocation correctness in Ext4GetVolumeName
>   Ext4Pkg: Add missing exit Status in Ext4OpenDirent
> 
> Hi!
> 
> Thanks for the patches (and the fuzzing!). They all mostly lgtm, just some small nits. Please fix them so I can test and merge.
> 
> Also, could you add a Fixes tag to each patch (like in the LKML and elsewhere in OVMF) so we can more easily track what each patch fixes? Using something simple like the oldest git blame of what you're fixing should be enough in this case, no need for git bisect. I just want to establish a good, clean track record here for me and for downstream users to better know what they need to pick up!
> 
> Thanks,
> Pedro


[-- Attachment #2: Type: text/html, Size: 3841 bytes --]