diff options
author | Aidan MacDonald <amachronic@protonmail.com> | 2022-04-01 11:53:17 +0100 |
---|---|---|
committer | Aidan MacDonald <amachronic@protonmail.com> | 2022-04-09 15:20:57 +0100 |
commit | 32f1418c5ad1becd829b65628f9f6ec32b6dda79 (patch) | |
tree | 6f598f4927f4da64a79e5b8add3a4c0cb5134ca5 /firmware | |
parent | 5aa0fc3b008e976a0d61a55814666229f2da47c8 (diff) | |
download | rockbox-32f1418c5ad1becd829b65628f9f6ec32b6dda79.tar.gz rockbox-32f1418c5ad1becd829b65628f9f6ec32b6dda79.zip |
buffering: fix buffer overflows with bitmap loading
In some circumstances it was possible for a bitmap to overflow its
buffer and overwrite the next handle. The easiest way to trigger it
is with a highly compressed JPEG that is decoded to a large bitmap.
Because the JPEG file size is used to determine how much to allocate
this would cause an obvious buffer overflow when the JPEG is smaller
than the decoded bitmap. Fix this by using the decoded bitmap size as
the allocation size. Some overhead must be added to deal with JPEGs,
but it will be freed once the image is loaded.
A less obvious possibility is the fact that add_handle() will allow
a handle to be added even if there's not enough space for the entire
allocation. This is generally beneficial because it allows the first
part of a file to be loaded while waiting for space to free up, but
for bitmaps it is not valid because the whole image is loaded at once.
Hence if there is not actually enough space in the buffer, the bitmap
load can again overflow the actual free space and overwrite the next
handle.
The buffering code supports an H_ALLOCALL flag for allocations that
need the free space available immediately, so use it for bitmaps to
avoid that bug.
load_image() had a sketchy-looking check for free space which stopped
me from triggering the bug with simple tests, but since guessing the
free space is obviously a bad idea when the caller *knows* how much
free space there really is, remove that guess and let the caller tell
load_image() the real deal.
Change-Id: If62a58759705d83c16ee5b50f26bcbccc3f6c01f
Diffstat (limited to 'firmware')
0 files changed, 0 insertions, 0 deletions