David Gstir

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.

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.

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.

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.

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.

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.

A issue in the Linux kernel has been identified where DCP trusted keys can crash during encryption and decryption of the blob encryption key via the DCP crypto driver when vmalloc stack addresses are enabled. This is caused by improper use of `sg init one()` with vmalloc'd stack buffers, specifically `plain key blob`.

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 handling of trusted keys in the Linux kernel. Specifically, when importing a trusted DCP-based key and then exporting it again, the blob encryption key (BEK) is decrypted in-place, causing the trusted key blob field to hold the BEK in plain text. As a result, every subsequent read of that key sends the plain text BEK instead of the encrypted BEK to userspace. This issue is rare and typically occurs when importing a trusted DCP-based key and then exporting it again, which is not a common use case.

The issue is related to the use of `rand()` as a fallback when `CARES RANDOM FILE` is not set, which can allow an attacker to exploit the lack of entropy by not using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). This can potentially impact the integrity of protected information. The issue is specifically observed when cross-compiling c-ares for aarch64 android using the autotools build system.

The issue arises when /dev/urandom or RtlGenRandom() are unavailable, and c-ares uses `rand()` to generate random numbers for DNS query ids. This approach is not a Cryptographically Secure PseudoRandom Number Generator (CSPRNG) and lacks seeding by `srand()`, resulting in predictable output. The input from the random number generator is then used in a non-compliant RC4 implementation, potentially weakening its strength. Modern OS-provided CSPRNGs, such as `arc4random()`, are not utilized.