grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] udf: Fix regression which is preventing symlink access


From: Daniel Kiper
Subject: Re: [PATCH v2] udf: Fix regression which is preventing symlink access
Date: Mon, 20 Sep 2021 12:41:39 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Sep 17, 2021 at 08:28:05PM +0000, Glenn Washburn wrote:
> This code was broken by commit 3f05d693 ("malloc: Use overflow checking
> primitives where we do complex allocations"), which added overflow checking
> in many areas. The problem here is that the changes update the local
> variable sz, which was already in use and which was not updated before the
> change. So the code using sz was getting a different value of than it would
> have previously for the same UDF image. This causes the logic getting the
> destination of the symlink to not realize that its gotten the full
> destination, but keeps trying to read past the end of the destination. The
> bytes after the end are generally NULL padding bytes, but that's not a
> valid component type (ECMA-167 14.16.1.1). So grub_udf_read_symlink branches
> to error logic, returning NULL, instead of the symlink destination path.
>
> The result of this bug is that the UDF filesystem tests were failing in the
> symlink test with the grub-fstest error message:
>
>     grub-fstest: error: cannot open `(loop0)/sym': invalid symlink.
>
> This change stores the result of doubling sz in another local variable s,
> so as not to modify sz. Also remove unnecessary grub_add, which increased
> the output by 1, persumably to account for a NULL byte. This isn't needed
> because an output buffer of size twice sz is already guaranteed to be more
> than enough to contain the path components converted to UTF-8. The value of
> sz contains at least 4 bytes for the path component header (ECMA-167
> 14.16.1), which means that 2*4 bytes are allocated but will not be used for
> UTF-8 characters, so the NULL byte is accounted for.
>
> Signed-off-by: Glenn Washburn <development@efficientek.com>

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]