On Tue, Aug 16, 2022 at 10:45:50AM +0200, Carlos Maiolino wrote:
> Prevent uninitialized data in the stack by initializing getbmap structure
> to zero.
The kernel should fill out all the bmap[1..BMAP_LEN-1] entries, right?
The only part of the array that's critical to initialize to a known
value is bmap[0], since that's what the kernel will read to decide what
to do, right?
Or, zooming out a bit, why did you decide to initialize the struct? Was
it valgrind complaining about uninitialized ioctl memory, or did someone
report a bug?
(I'm actually fine with this change, I just want to know how you got
here. ;))
--D
> Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
> ---
>
> There is already a patch on the list to remove remaining DMAPI stuff from
> xfsdump:
> xfsdump: remove BMV_IF_NO_DMAPI_READ flag
>
> This patch though, does not initialize the getbmap structure, and although
> the
> first struct in the array is initialized, the remaining structures in the
> array are not, leaving garbage in the stack.
>
>
> dump/inomap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dump/inomap.c b/dump/inomap.c
> index f3200be..c4ea21d 100644
> --- a/dump/inomap.c
> +++ b/dump/inomap.c
> @@ -1627,7 +1627,7 @@ static off64_t
> quantity2offset(jdm_fshandle_t *fshandlep, struct xfs_bstat *statp, off64_t qty)
> {
> int fd;
> - struct getbmap bmap[BMAP_LEN];
> + struct getbmap bmap[BMAP_LEN] = {0};
> off64_t offset;
> off64_t offset_next;
> off64_t qty_accum;
>
>
