[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