David Gstir

**Name of the Vulnerable Software and Affected Versions** Das U-Boot versions prior to 2025.01-rc1 **Description** 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. **Recommendations** For versions prior to 2025.01-rc1, update to version 2025.01-rc1 or later to resolve the issue. As a temporary workaround, consider restricting the use of crafted ext4 filesystems to minimize the risk of exploitation. Avoid using the `zalloc` function with untrusted input until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Das U-Boot versions prior to 2025.01-rc1 **Description** 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. **Recommendations** For versions prior to 2025.01-rc1, update to version 2025.01-rc1 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** DAS U-Boot versions prior to 2025.01-RC1 **Description** 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. **Recommendations** For versions prior to 2025.01-RC1, update to version 2025.01-RC1 or later to resolve the issue. As a temporary workaround, consider restricting access to crafted squashfs filesystems to minimize the risk of exploitation. Avoid using the `sbrk` and `request2size` functions with untrusted input until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** DAS U-Boot versions prior to 2025.01-RC1 **Description** 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. **Recommendations** For versions prior to 2025.01-RC1, update to version 2025.01-RC1 or later to resolve the issue. As a temporary workaround, consider restricting the use of crafted squashfs filesystems with deep symlink nesting to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** DAS U-Boot versions prior to 2025.01-RC1 **Description** 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. **Recommendations** For versions prior to 2025.01-RC1, update to version 2025.01-RC1 or later to resolve the issue. As a temporary workaround, consider restricting access to the `sqfs resolve symlink` function to minimize the risk of exploitation. Avoid using crafted squashfs filesystems with an inode size of `0xffffffff` until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** 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`. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

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.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** c-ares versions prior to 1.19.1 **Description** 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. **Recommendations** For versions prior to 1.19.1, update to version 1.19.1 or later to resolve the issue. As a temporary workaround, consider disabling the use of `rand()` as a fallback until a patch is available. Restrict access to sensitive information to minimize the risk of exploitation. Avoid using the `CARES RANDOM FILE` fallback in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** c-ares versions prior to 1.19.1 **Description** 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. **Recommendations** For versions prior to 1.19.1, update to version 1.19.1 to resolve the issue. As a temporary workaround, consider restricting the use of the `rand()` function in c-ares until a patch is available. Avoid using the non-compliant RC4 implementation in the affected API endpoints until the issue is resolved.