Rockbox
32f1418c5a
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 |
||
|---|---|---|
| android | ||
| apps | ||
| backdrops | ||
| bootloader | ||
| debian | ||
| docs | ||
| firmware | ||
| fonts | ||
| gdb | ||
| icons | ||
| lib | ||
| manual | ||
| packaging | ||
| tools | ||
| uisimulator | ||
| utils | ||
| wps | ||
| .gitattributes | ||
| .gitignore | ||
| .gitreview | ||
__________ __ ___.
Open \______ \ ____ ____ | | _\_ |__ _______ ___
Source | _// _ \_/ ___\| |/ /| __ \ / _ \ \/ /
Jukebox | | ( <_> ) \___| < | \_\ ( <_> > < <
Firmware |____|_ /\____/ \___ >__|_ \|___ /\____/__/\_ \
\/ \/ \/ \/ \/
Build Your Own Rockbox
1. Clone 'rockbox' from git (or extract a downloaded archive).
$ git clone git://git.rockbox.org/rockbox
or
$ tar xjf rockbox.tar.bz2
2. Create a build directory, preferably in the same directory as the firmware/
and apps/ directories. This is where all generated files will be written.
$ cd rockbox
$ mkdir build
$ cd build
3. Make sure you have mips/m68k/arm-elf-gcc and siblings in the PATH. Make sure
that you have 'perl' in your PATH too. Your gcc cross compiler needs to be
a particular version depending on what player you are compiling for. These
can be generated using the rockboxdev.sh script in the /tools/ folder of the
source.
$ which arm-elf-eabi-gcc
$ which perl
4. In your build directory, run the 'tools/configure' script and enter what
target you want to build for and if you want a debug version or not (and a
few more questions). It'll prompt you. The debug version is for making a
gdb version out of it. It is only useful if you run gdb towards your target
Archos.
$ ../tools/configure
5. *ploink*. Now you have got a Makefile generated for you.
6. Run 'make' and soon the necessary pieces from the firmware and the apps
directories have been compiled, linked and scrambled for you.
$ make
$ make zip
7. unzip the rockbox.zip on your music player, reboot it and
*smile*.
If you want to build for more than one target, just create several build
directories and create a setup for each target:
$ mkdir build-fuzeplus
$ cd build-fuzeplus
$ ../tools/configure
$ mkdir build-xduoox3
$ cd build-xduoox3
$ ../tools/configure
Questions anyone? Ask on the mailing list or on IRC. We'll be happy to help you!