u-boot.git/fs/squashfs, branch v2022.07

fs/squashfs: Use kcalloc when relevant

2022-06-28T19:51:56Z

A crafted squashfs image could embed a huge number of empty metadata blocks in order to make the amount of malloc()'d memory overflow and be much smaller than expected. Because of this flaw, any random code positioned at the right location in the squashfs image could be memcpy'd from the squashfs structures into U-Boot code location while trying to access the rearmost blocks, before being executed. In order to prevent this vulnerability from being exploited in eg. a secure boot environment, let's add a check over the amount of data that is going to be allocated. Such a check could look like: if (!elem_size || n > SIZE_MAX / elem_size) return NULL; The right way to do it would be to enhance the calloc() implementation but this is quite an impacting change for such a small fix. Another solution would be to add the check before the malloc call in the squashfs implementation, but this does not look right. So for now, let's use the kcalloc() compatibility function from Linux, which has this check. Fixes: c5100613037 ("fs/squashfs: new filesystem") Reported-by: Tatsuhiko Yasumatsu Signed-off-by: Miquel Raynal Tested-by: Tatsuhiko Yasumatsu

fs/squashfs: sqfs_read: Prevent arbitrary code execution

2022-06-16T19:22:55Z

Following Jincheng's report, an out-of-band write leading to arbitrary code execution is possible because on one side the squashfs logic accepts directory names up to 65535 bytes (u16), while U-Boot fs logic accepts directory names up to 255 bytes long. Prevent such an exploit from happening by capping directory name sizes to 255. Use a define for this purpose so that developers can link the limitation to its source and eventually kill it some day by dynamically allocating this array (if ever desired). Link: https://lore.kernel.org/all/CALO=DHFB+yBoXxVr5KcsK0iFdg+e7ywko4-e+72kjbcS8JBfPw@mail.gmail.com Reported-by: Jincheng Wang Signed-off-by: Miquel Raynal Tested-by: Jincheng Wang

squashfs: Fix compilation on big endian systems

2022-06-03T15:15:24Z

Signed-off-by: Pali Rohár Reviewed-by: Miquel Raynal

fs/squashfs: use lldiv function for math

2022-05-23T13:33:10Z

When compling for x86: ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read': u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4' ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4' Signed-off-by: Sean Nyekjaer Reviewed-by: Miquel Raynal Reviewed-by: Pali Rohár

fs/squashfs: simplify sqfs_read()

2022-04-19T18:51:11Z

* Don't check argument of free(). Free does this itself. * Reduce scope of data_buffer. Remove duplicate free(). * Avoid superfluous NULL assignment. Signed-off-by: Heinrich Schuchardt Reviewed-by: Miquel Raynal

squashfs: show an error message if the inode_table can't be, allocated

2022-01-29T12:46:46Z

Signed-off-by: Lars Weber

sqfs: Suppress the message about missing filesystem

2021-09-16T17:19:25Z

This message comes up a lot when scanning filesystems. It suggests to the user that there is some sort of error, but in fact there is no reason to expect that a particular partition has a sqfs filesystem. Other filesystems don't print this error. Turn it into a debug message. Signed-off-by: Simon Glass Reviewed-by: Miquel Raynal

fs/squashfs: Fix some hardlinks reading the wrong inode

2021-08-04T19:58:31Z

In SquashFS, the contents of a directory is stored by squashfs_directory_entry structures which contain the file's name, inode and position within the filesystem. The inode number is not stored directly; instead each directory has one or more headers which set a base inode number, and files store the offset from that to the file's inode number. In mksquashfs, each inode is allocated a number in the same order as they are written to the directory table; thus the offset from the header's base inode number to the file's inode number is usually positive. Hardlinks are simply stored with two directory entries referencing the same file. This means the second entry will thus have an inode number much lower than the surrounding files. Since the header's base inode number comes from the first entry that uses the header, this delta will usually be negative. Previously, U-Boot's squashfs_directory_entry.inode_offset field was declared as an unsigned value. Thus when a negative value was found, it would either resolve to an invalid inode number or to that of an unrelated file. A squashfs image to test this can be created like so: echo hi > sqfs_test_files/001-root-file mkdir sqfs_test_files/002-subdir touch sqfs_test_files/002-subdir/003-file ln sqfs_test_files/{001-root-file,002-subdir/004-link} mksquashfs sqfs_test_files/ test.sqfs -noappend Note that squashfs sorts the files ASCIIbetacally, so we can use the names to control the order they appear in. The ordering is important - the first reference to the file must have a lower inode number than the directory in which the second reference resides, and the second reference cannot be the first file in the directory. Listing this sample image in U-Boot results in: => sqfsls virtio 2 002-subdir 0 003-file Inode not found. 0 004-link Signed-off-by: Campbell Suter Reviewed-by: Miquel Raynal

fs/squashfs: fix reading of fragmented files

2021-06-10T00:58:20Z

The fragmented files were not correctly read because of two issues: - The squashfs_file_info struct has a field named 'comp', which tells if the file's fragment is compressed or not. This field was always set to 'true' in sqfs_get_regfile_info and sqfs_get_lregfile_info. It should actually take sqfs_frag_lookup's return value. This patch addresses these two assignments. - In sqfs_read, the fragments (compressed or not) were copied to the output buffer through a for loop which was reading data at the wrong offset. Replace these loops by equivalent calls to memcpy, with the right parameters. I tested this patch by comparing the MD5 checksum of a few fragmented files with the respective md5sum output in sandbox, considering both compressed and uncompressed fragments. Signed-off-by: Joao Marcos Costa Tested-by: Richard Genoud Reviewed-by: Miquel Raynal

fs/squashfs: zero out unused fields in fs_dirent

2021-05-26T21:26:07Z

When reading directories the UEFI sub-system must supply file attributes and timestamps. These fields will have to be added to struct fs_dirent. SquashFS should not fill these fields with random data. Ensure that they are zeroed out. Signed-off-by: Heinrich Schuchardt Reviewed-by: Miquel Raynal