diff options
author | Patrick Steinhardt <ps@pks.im> | 2018-10-29 18:32:39 +0100 |
---|---|---|
committer | Patrick Steinhardt <ps@pks.im> | 2018-11-02 13:31:09 +0100 |
commit | 7fafec0e53f8711b73912d46b43451c599aeceb3 (patch) | |
tree | 5dca2f4c35fabf0e43844a58d5792f8254153639 /src/commit.c | |
parent | f647bbc88d243a81d8771ba2fd1c346c34a3d9d7 (diff) | |
download | libgit2-7fafec0e53f8711b73912d46b43451c599aeceb3.tar.gz |
tree: fix integer overflow when reading unreasonably large filemodes
The `parse_mode` option uses an open-coded octal number parser. The
parser is quite naive in that it simply parses until hitting a character
that is not in the accepted range of '0' - '7', completely ignoring the
fact that we can at most accept a 16 bit unsigned integer as filemode.
If the filemode is bigger than UINT16_MAX, it will thus overflow and
provide an invalid filemode for the object entry.
Fix the issue by using `git__strntol32` instead and doing a bounds
check. As this function already handles overflows, it neatly solves the
problem.
Note that previously, `parse_mode` was also skipping the character
immediately after the filemode. In proper trees, this should be a simple
space, but in fact the parser accepted any character and simply skipped
over it. As a consequence of using `git__strntol32`, we now need to an
explicit check for a trailing whitespace after having parsed the
filemode. Because of the newly introduced error message, the test
object::tree::parse::mode_doesnt_cause_oob_read needs adjustment to its
error message check, which in fact is a good thing as it demonstrates
that we now fail looking for the whitespace immediately following the
filemode.
Add a test that shows that we will fail to parse such invalid filemodes
now.
Diffstat (limited to 'src/commit.c')
0 files changed, 0 insertions, 0 deletions