Richard Weinberger

An improper certificate validation issue exists in the `crypto/swupdate cms verify openssl.c` file. The system trusts untrusted X.509 certificates embedded in CMS SignedData during the chain building process. This allows an attacker who possesses a signing key from a sibling intermediate under the same root to embed that intermediate in the signature and install malicious updates.

A stack consumption issue occurs in the sqfs size function in DAS U-Boot through a crafted squashfs filesystem with deep symlink nesting. This issue affects the SquashFS symlink resolution function, leading to a stack-based overflow.

The issue is related to an off-by-one error in the sqfs search dir function, which leads to heap memory corruption when listing SquashFS directories. This error occurs because the path separator is not considered in a size calculation.

The issue is related to an integer overflow in the `request2size` function in `common/dlmalloc.c`.

The issue is related to an integer overflow in the `ext4fs read symlink` function when handling a crafted ext4 filesystem with an inode size of `0xffffffff`. This results in a `malloc` of zero and a subsequent memory overwrite. The problem arises from adding one to an `le32` variable, which causes the overflow.

The issue is related to an integer overflow in the `sqfs inode size` function, which occurs during the calculation of the symlink size via a crafted squashfs filesystem. This can be exploited using a specifically manipulated squashfs filesystem.

An integer overflow occurs in the `sqfs resolve symlink` function in DAS U-Boot through a crafted squashfs filesystem with an inode size of `0xffffffff`, resulting in a malloc of zero and a resultant memory overwrite. This issue can be triggered via a manipulated squashfs filesystem.

An integer overflow occurs in the ext4fs read symlink function in Das U-Boot. This happens when a crafted ext4 filesystem with an inode size of 0xffffffff is used, causing a malloc of zero and resultant memory overwrite. The issue arises from adding one to an LE32 variable in the zalloc function.

Integer overflows in memory allocation occur for a crafted squashfs filesystem via `sbrk`, via `request2size`, or because `ptrdiff t` is mishandled on x86 64. This issue affects the memory allocation in DAS U-Boot.

Name of the Vulnerable Software and Affected Versions: tgt versions prior to 1.0.93 Description: The issue is related to the Linux target framework (tgt) attempting to generate random numbers by using `rand` without `srand`, resulting in a predictable PRNG seed. This causes the sequence of challenges to be always identical. An attacker capable of recording network traffic can abuse this by replaying previous responses, potentially leading to a CHAP authentication bypass. Recommendations: For versions prior to 1.0.93, update to version 1.0.93 or later to resolve the issue. As a temporary workaround, consider restricting access to the tgt framework until a patch is applied. Avoid using the tgt framework for authentication until the issue is resolved.

The issue is related to the ubifs component of the Linux kernel, where page cache reads are lockless. This allows a simultaneous reader to see old data if the freshly allocated page is set uptodate before the new data is copied into it. The vulnerability can be exploited to cause a denial of service. The `SetPageUptodate` call has been moved to `ubifs write end()`, after the new data has been copied into the page, to resolve the issue. The functions `write begin slow()`, `ubifs write begin()`, and `ubifs write end()` in `fs/ubifs/file.c` are involved in the vulnerability.

The issue is related to the squashfs opendir function in the unsquash-2.c component of Squashfs-Tools, which incorrectly handles symbolic links before accessing a file. This allows a remote attacker to compromise data integrity and cause a denial of service. Specifically, a crafted squashfs filesystem containing a symbolic link and subsequent contents with the same filename can cause unsquashfs to create the symbolic link outside the expected directory, and then write through the symbolic link elsewhere in the filesystem.