| Age | Commit message (Collapse) | Author |
|---|
|
free should be called before the function exit abnormally.
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
... and friends. Again, PPC never cared about the difference, while
ARM had to add an explicit cast to work around it, which we can remove
now.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This was only ever used on PPC, where they are equivalent and we
never saw the resulting -Wpointer-sign warnings.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We carefully avoid the realloc() API trap by *not* using the
'ptr = realloc(ptr, new_size)' idiom which can lead to leaks on
failure. Very commendable, even though all we're going to do is
exit() on failure so it wouldn't have mattered.
What *does* matter is that we then ask zlib to continue
decompression... just past the end of the *old* buffer that just
got freed. Oops.
Apparently nobody has *ever* tested this code by booting a uImage
with a compressed payload larger than 10MiB.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.
kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
int', but argument 2 has type 'off_t' [-Wformat]
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Teach uImage_probe_xxx() to return the information about
a corrupted image. This is required to prevent the loading
of a corrupted ramdisk, where we don't have strict checking
for the other formats, unlike the kernel. So, we should abort
the operation than causing a problem with the new kernel.
Without this patch, a corrupted uImage ramdisk is treated as
a plain ramdisk where there is no format check involved.
# kexec -l uImage --initrd romfs-initrd.corrupt
The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
# echo $?
0
# kexec -e
Starting new kernel
Bye!
Reserving 55MB of memory at 70MB for crashkernel (System RAM: 256MB)
Using Xilinx Virtex440 machine description
Linux version 3.6.0-rc3 (root@suzukikp) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC) ) #66 Tue Apr 16 06:36:56 UTC 2013
Found initrd at 0xcf5f8000:0xcfff8040
...
NET: Registered protocol family 17
RAMDISK: Couldn't find valid RAM disk image starting at 0.
List of all partitions:
No filesystem could mount root, tried: ext2 cramfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
With this patch :
# kexec -l uImage --initrd romfs-initrd.corrupt
uImage: The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
uImage: Corrupted ramdisk file romfs-initrd
With a corrupted kernel image(the behaviour remains the same) :
# kexec -l uImage.corrupt --initrd romfs-initrd
uImage: The data CRC does not match. Computed: 285787b7 expected e37f65ad
Cannot determine the file type of uImage.corrupt
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add IH_TYPE_RAMDISK as a recognized image type.
uImage_load shouldn't decompress the RAMDISK type images, since
uboot doesn't do it.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For payloads without any compression, the image->len
is set to the length of the entire uImage which includes
the uImage header. This should be filled in from
ih_size field of the uImage header.
This can cause a buffer overflow, leading the sha256_process
to overrun the initrd buffer. Also, prevents a vulnerability
where the image has been appended with additional data. The
crc check is performed only when compiled with zlib.
TODO: Implement CRC check if ZLIB is not compiled in.
Reported-by: Nathan Miller <nathanm2@us.ibm.com>
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
uImage supports different types of payloads, including kernel,
ramdisks etc. uImage_probe() as of now checks whether the supplied
payload is of type KERNEL ( i.e, IH_TYPE_KERNEL or IH_TYPE_KERNEL_NOLOAD ).
Change this behaviour to return the image type, if it is one of the supported
payloads. This change is in prepartion to support ramdisks in uImage format.
Introduce a uImage_probe_kernel() which can be used by the archs to check if
the supplied payload is one of the KERNEL types.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Do not trigger an error when loading a uImage with the
IH_TYPE_KERNEL_NOLOAD type. These images do not need to be copied to
their load address before being executed.
All archs (excepted PPC) do not use the uImage load and entry point
parameters, so their current behavior needs not be changed further than
just accepting the image type.
Tested and validated on ARM.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Instead of calulating the CRC on the whole file just calculate the CRC
on the actual uImage length as given by the uImage header. This fixes
loading padded uImages, for example from a mtd partition.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
|
|
This avoids out of range comparisons (for values >= 128)
and an unnecessary cast.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The check and uncompress code could be split and recycled by other arch.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
|
