| Age | Commit message (Collapse) | Author |
|---|
|
Due to the change in directory size accounting, the checksums no
longer matched.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
If rdsquashfs unpacks a directory tree that contains a symlink,
followed by something else with the exact same name, it will
follow the symlink and can be tricked into writing to an
arbitrary filesystem location controlled by the SquashFS image.
Because there might actually be a reasonable use case, where an
image is unpacked into an directory existing directory tree, with
symlinks that should be followed, this is solved as follows:
- Before unpacking, recursively sort the directory by filename.
- FAIL if (after sorting) two consequtive entries at the same
hierarchy level have the same name.
This solution is more generic and prevents the unpacker from accessing
the same thing twice in generall, thus also excluding the symlink issue.
Hardlinks are already unfolded into duplicate tree nodes by the tree
reader (with loop detection) so that should not prompt further issues.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Licensed under 0BSD: https://opensource.org/licenses/0BSD
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
|
|
|
|
This is to allow git to recognize that format.txt "moves" to format.adoc
in the next commit (with -M20, at least), which should allow easier
comparison for what has changed (and more importantly, what hasn't) in
converting to asciidoc. For instance, doing the diff with the following
options:
```
-M20 --ignore-all-space --word-diff
```
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
The squashfs readdir() implementation in the Linux kernel returns
non-existing "." and ".." entries for offsets 0 and 1, and after
that reads from disk. For convenience, it was decided to store an
off-by-3 value on disk instead of doing complex primary school math
to adjust for this. This didn't show up until now, because the kernel
implementation trusts the value from the directory header more than
the actual size in the inode and happily reads 3 more than the inode
would allow it to. This only showed up with 7-zip which subtracts 3
from the size and expects the result to be exact and bails if the
directory headers suggest otherwise.
And yes, I did consider making a "Holy Hand Granade of Antioch"
reference, but consciously decided not to.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
The data is processed 2G at a time to avoid this exact issue, but the
check was skipped on 64 bit systems, since the function *used to* use
size_t instead of sqfs_u32.
This commit removes the second check.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
When processing files > 4G, using "%o" truncates the result and the
tarball is not readable. This should have been discovered when
auto-patching the printf format specifiers, but a cast was added
instead and the issue was overlooked.
This commit replaces the down-cast and printf format specifiers.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
- Store the return value of the page allocation directly into the
pool variable instead of an intermediate unsigned char pointer.
- Make the blob[] array the same type as the bitmap, this saves us
manual alignment trickery.
- Cleanup the pointer arithmetic, let the compiler do the
sizeof() multiplication.
- Use uintptr_t for the manual alignment of the data pointer, so we
don't run into signdness problems there.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
The same problem with the meta data header again, 16 bit read from
a buffer: copy the buffer data into a 16 bit variable instead of
casting to something potentially unaligned.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
When accessing the 16 bit header, don't cast the buffer pointer to an
uint16_t pointer, the result might not be aligned propperly. Instead
memcpy to and from an uint16_t.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
*in theory*, say on a 32 bit system, we could have a 32 bit size_t and
a 64 bit off_t. If the filesystem permitted this, we *could* then have
a symlink with a target > 4G. Or the target is exacetely 4G, but
adding a null-terminator could exceed addressable memory.
This commit adds a check to guard against such an overflow and throw
an error, instead of silently wrapping around.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
If the hard link counter or the inode number counter overflow the
maximum representable value (for SquashFS 16 bit and 32 bit
respecitively), abort with an error message.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
The differen compressor libraries use differnt integer types to tally
the buffer sizes. The libfstream library uses size_t, which may be
bigger than the actualy types, potentially causing an overflow if
trying to compress to much at once.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Apparentyl it bricks *some* of the GNU/Linux builds, plus MacOS X that
get stuck at a password prompt.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Currently, when the block processor aggreagtes fragments into a
fragment block, it applies the "don't compress" flag if any of the
original framgnets has it set, but the "align to device block" flag
is lost.
This commit ensures that both flags get applied to the fragment block
if set.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
1) If the block alignment flag is set, the padding bytes must be
inserted _before_ recording the start position, otherwise the
resulting image is not readable.
2) Also perform alignment if the flag is set on a fragment block.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
This is a followup to dd4e6ead142e58568aec89d76b0b2e867ee983f2.
Basically the same problem occours with Bzip2, but it so far it wasn't
possible to find a sampel that reproduces it.
Unlike libxz, the libbz2 API does not support concatenated streams by
itself and will choke when trying to decompress after the stream end,
so this commit adds a workaround to simply initialize the decompressor
on-the-fly and tear it down again when and end-of-stream is returned.
The end-of-file condition is only set when there actually is no more
data to read. Otherwise, the decompressor will be re-initialized in
the next round.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Let it run (and fail) even if we don't have zstd support at all, so
that the conditional is set propperly.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
In addition to the preprocessor define, use an Automake conditional
for optional compilation of the zstd stream tests.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
|
|
A modified version of the libfstream XZ stream uncompress test case
is added that deliberately chops the compressed data up into two
independend XZ streams to test the behaviour where the decompressor
has to read across stream boundaries, like those resulting from
parallel compression.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
|
Some xz compressed tarballs (e.g. from kernel.org) are not made up of
a single xz stream, but rather contain several, independendly
compressed streams. In that case, the xz decompressor hits
an LZMA_STREAM_END early on and reports EOF. If you are lucky, the tar
reader bails (premature end-of-file). If you are unlucky, it happens
exactely between two records and is interpeted as regular end-of-file.
As this seems to be a normal use case for xz, it has a flag to just
read across the seams and only report end-of-stream if the action
is set to finish.
This commit adds the flag to the initialization propperly sets the
lzma_action depending on whether the underlying stream hit EOF or not.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
|
