Lee Jones

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the `usb string copy()` function in the Linux kernel's USB gadget configfs module. It involves an out-of-bounds (OOB) read and write when a userspace-provided string has a length of zero. This can lead to a denial of service. The vulnerability arises from the lack of a check for invalid strings that are too short, although there is already a validating check for strings that are too long. The OOB read and write occur in the forms `if (str[0 - 1] == ' ')` and `str[0 - 1] = '0'`, respectively. **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** Linux kernel (affected versions not specified) **Description** A bug in the Linux kernel has been resolved, specifically in the ext4 file system. The issue occurs when pages are dirtied without properly warning the file system in advance, which can lead to a BUG or potential data loss. This problem can be triggered by the process vm writev(2) system call. The kernel will now issue a warning and mark the page as clean to prevent unprivileged denial of service attacks. **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** Linux kernel (affected versions not specified) **Description** The issue is related to a use-after-free vulnerability in the sctp sock dump function. This vulnerability occurs when the asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock sock(sk). To prevent the sk free, the patch uses call rcu() and moves sock put and ep free into sctp endpoint destroy rcu(), making it safe to hold the ep under rcu read lock in sctp transport traverse process(). **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** Jenkins Active Directory Plugin versions 1.44 through 2.19 Jenkins Active Directory Plugin versions prior to 2.16.1 and 2.20 **Description** The issue allows attackers to log in as any user if a magic constant is used as the password. This is due to the shared code between user lookup and user authentication in the LDAP-based mode, where the magic constant is used in place of a real password to distinguish between these behaviors. **Recommendations** For Jenkins Active Directory Plugin versions 1.44 through 2.19, update to version 2.20 or later. For Jenkins Active Directory Plugin versions prior to 2.16.1, update to version 2.16.1 or later. As a temporary workaround, consider restricting access to the LDAP-based mode until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Jenkins Active Directory Plugin versions 2.19 and earlier **Description** The issue allows attackers to log in to Jenkins as any user by providing an empty password, depending on the configuration of the Active Directory server. This is possible because the Windows/ADSI mode does not specifically prohibit the use of empty passwords. If the Active Directory server allows the unauthenticated bind operation, attackers can exploit this to gain unauthorized access. **Recommendations** For Jenkins Active Directory Plugin versions 2.19 and earlier, update to version 2.20 or 2.16.1 to prohibit the use of empty passwords and prevent unauthorized logins.

**Name of the Vulnerable Software and Affected Versions** Jenkins Active Directory Plugin versions 2.19 and earlier Jenkins Active Directory Plugin versions prior to 2.20 and 2.16.1 **Description** The issue allows attackers to log in as any user with any password while a successful authentication of that user is still in the optional cache when using Windows/ADSI mode. The plugin implements two separate modes: Integration with ADSI on Windows, and an OS agnostic LDAP-based mode. A cache can be configured to remember user lookups and user authentications, which is the source of the problem. In Windows/ADSI mode, the provided password was not used when looking up an applicable cache entry. **Recommendations** For Jenkins Active Directory Plugin versions 2.19 and earlier, update to version 2.20 or 2.16.1 to resolve the issue. For Jenkins Active Directory Plugin versions prior to 2.20 and 2.16.1, update to version 2.20 or 2.16.1 to resolve the issue. As a temporary workaround, consider disabling the cache to prevent exploitation. Alternatively, set the Java system property `hudson.plugins.active directory.CacheUtil.noCacheAuth` to `true` to no longer cache user authentications.