A privilege escalation flaw was found in FreeIPA. The uniqueness constraint enforced on Kerberos principal name attributes in the 389-ds directory server does not properly account for equivalent representations of the same principal name, allowing a user with sufficient LDAP write privileges to create a service principal that impersonates an existing privileged one. This can lead to unauthorized acquisition of Kerberos service tickets for sensitive services, potentially resulting in full domain compromise.

A flaw was found in FreeIPA. The trust-fetch-domains command, used to refresh Active Directory trust topology, is gated only by the read-level ACI on the trust object (System: Read Trust Information, granted to any authenticated IPA user by default) rather than a trust-administration-level permission. Any authenticated, non-privileged IPA user can therefore invoke ipa trust-fetch-domains, which calls a root-owned oddjobd/D-Bus helper (install/oddjob/com.redhat.idm.trust-fetch-domains.in). When the caller supplies --admin/--password, the helper calls kinitpassword() against a caller-chosen --server using attacker-supplied credentials, with no cross-check that they belong to the real trusted AD forest, then accepts whatever forest-trust topology (domain names, NetBIOS names, SIDs) that attacker-controlled server returns via ipaserver/dcerpc.py's fetchdomains()/discovertrustinstance(). This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by trust.addnewdomainsfromtrust(). The authorization gap itself (an unprivileged, non-admin user's request reaching the root-owned helper's execution with no ACI rejection) was reproduced dynamically in an isolated sandbox against ipa-server-4.13.5, confirmed against a negative control (an unrelated admin-only operation was correctly rejected in the same session). The exploiting principal holds zero delegated privilege — this is not a case of a narrow administrative delegation being used beyond its intended scope.

A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.

A configuration-dependent issue in rsyslog's optional imptcp input module can allow an unauthenticated remote peer to crash rsyslogd. The issue is not active in a default installation. Exploitation requires all of the following:

imptcp is explicitly loaded. An imptcp listener uses the non-default framing.delimiter.regex mode. An attacker can establish a TCP connection to that listener.

A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.

A flaw was found in 389 Directory Server (389-ds-base). The getruvelementfromberval() function in ldap/servers/plugins/replication/repl5ruv.c copies digit characters from a network-supplied RUV berval into a fixed 16-byte stack buffer (ridbuff[RIDSTRSIZE]) without bounds checking the loop counter. A remote unauthenticated attacker can crash the ns-slapd process by sending a crafted StartNSDS50ReplicationRequest LDAP extended operation (OID 2.16.840.1.113730.3.5.12) containing more than 16 consecutive digit characters in the replica ID field. The overflow occurs during payload decoding in decodestartreplextop(), before the replicaisupdatedn() authorization check runs, making it exploitable without credentials on default configurations where anonymous access is enabled. On production builds with stack protectors, the impact is limited to denial of service (process abort). The vulnerable code path is: decodestartreplextop() -> decoderuv() -> ruvinitfrombervals() -> getruvelementfromberval().

A flaw was found in libssh server-side SFTP directory listing. In processreaddir() in src/sftpserver.c, the server allocates a fixed stack buffer as char longname[MAXLONGNAMELEN] and passes attacker-controlled directory entry names into readdirlongname(). In the pre-patch implementation, readdirlongname() appends metadata and the filename into zlongname with repeated unbounded strcat() calls. Because zlongname points at the caller-owned fixed stack buffer, sufficiently long filenames in an attacker-controlled directory can overflow that stack buffer during SSHFXPREADDIR processing, leading to crashes and possible code execution on the server.

A flaw was found in libssh builds using the OpenSSL backend for AES-GCM. In the decrypt path in src/libcrypto.c, the return value from EVPDecryptFinal() was checked incorrectly, so authentication tag verification failures were not handled as integrity failures. This could effectively remove integrity protection for affected AES-GCM sessions and allow an in-path attacker to modify plaintext on the wire without detection.

A flaw was found in libssh server-side GSSAPIKeyExchange authorization. In sshpacketuserauthrequest() in src/messages.c, the gssapi-keyex login path granted success after Kerberos authentication without dispatching the callback that verifies whether the authenticated principal is authorized for the requested local user. On servers with GSSAPIKeyExchange enabled, an authenticated client can therefore log in as an arbitrary local user if the missing principal-to-user authorization check is relied upon for access control.

A flaw was found in libssh automatic certificate-based public key authentication. In sshuserauthpublickeyauto() in src/auth.c, the iterator over certificate candidates was not advanced correctly when configured certificates were missing or repeatedly rejected by the server. Under specific non-default certificate configurations, this could cause the client to restart the same authentication attempts indefinitely, leading to denial of service.

A flaw was found in libssh channel data handling. In channelrcvdata() in src/channels.c, incoming channel DATA messages could still be processed after the channel had already been marked as remotely closed. In SFTP-backed applications and other callback-driven consumers, this creates a path where data callbacks may observe channel-associated state after it has already been torn down or freed, leading to crashes and possible use-after-free conditions.

In the Linux kernel, the following vulnerability has been resolved:

mm/listlru: drain before clearing xarray entry on reparent

memcgreparentlistlrus() clears the dying memcg's xarray entry with xasstore(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent listlrudel() arriving for the dying memcg sees xaload() == NULL, walks to the parent in locklistlruofmemcg(), takes the parent's per-node lock, and calls listdelinit() on an item still physically linked on the dying memcg's list.

If another in-flight thread holds the dying memcg's per-node lock at the same moment (another listlrudel, or a listlruwalkone running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links.

Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent listlru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONGMIN and walks to the parent, where the items now live.

In the Linux kernel, the following vulnerability has been resolved:

drm/gem: Try to fix changehandle ioctl, attempt 4

[airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far:

5e28b7b94408 ("drm: Set old handle to NULL before prime swap in changehandle") tried to fix a race condition between the gemclose and gemchangehandle ioctls, but got a few things wrong:

- There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between changehandle and handledelete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong.

- dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix.

We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out:

- Rename the local variable to newhandle, the old aliasing with args->handle is just too dangerously confusing.

- Merge the gem obj lookup with the two-stage idrreplace so that we avoid getting ourselves confused there.

- This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gemclose on the newhandle could steal that. Fix that with the same two-stage approach createtail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia.

- Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idrreplace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit.

- While at it, also replace the 7 space indent with 1 tab.

And finally, because I flat out don't trust my abilities here at all anymore:

- Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus.

v2:

Sashiko noticed that I didn't handle the error path for idrreplace correctly, it must be checked with ISERRORNULL like in gemhandledelete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky.

Also add the Fixes: line for the original ioctl, I forgot that too.

A flaw was found in GLib. The D-Bus client-side implementation of the DBUSCOOKIESHA1 SASL authentication mechanism does not validate the cookiecontext parameter received from the server. A malicious D-Bus server can supply a cookiecontext containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.

A flaw was found in GLib. An off-by-one error can occur in the gkeyfilegetlocalestringlist function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.

A flaw was found in GLib. A buffer over-read can occur in giochannelreadlinebackend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.

A flaw was found in GLib. A buffer over-read can occur in the gregexreplace function when used with the GREGEXRAW compile flag and case-change replacement escapes because the stringappend function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.

A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the gdatetimegetymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the gdatetimeaddfull function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.

ice: fix double-free of txbuf skb

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nat: use kfreercu to release ops

Florian Westphal says:

"Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nfhookops that are used to register the callbacks.

However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.

This code will peek back into the nfhookops that are available at the tail of the pointer-array blob used by the datapath.

The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.

But once that changes the nat ops structures have to be deferred too."

Update nfnatregisterfn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlinkhook.

A flaw was found in GLib. An off-by-one error can occur in the gvstupleisnormal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.

A flaw was found in 389 Directory Server. The dereference control plugin does not check for allocation failure before using a BER structure, allowing an unauthenticated remote attacker to crash the LDAP server when the system is under memory pressure.

A client that requests multiple DRI2BufferBackLeft attachments and one DRI2BufferFrontLeft can trigger an out-of-bounds heap write in DRIGetBuffers/DRIGetBuffersWithFormat.

Any local X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/339c279514326134b0878fc23ce6e9520440ce7f

Identified by Peter Hutterer, Red Hat. Tracking: PSIRTSUPT-16950.

A client that sets up multiple SyncCounters can trigger a use-after-free when destroying those counters via a second client connection while changing those counters in SyncChangeCounter().

Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bdd7bf57af208b1ddf57d4683d67104443b44812

Reported via ZDI-CAN-30164 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.

XkbSetMapChecks() declares a fixed-size stack buffer mapWidths[256] indexed by key type index. The helper function CheckKeyTypes() writes to this buffer at a client-controlled offset, allowing a stack buffer overflow.

Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/867b59b33bee669cb412f1314e47c52eacf6e00b

Reported via ZDI-CAN-30161 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.

A client that sets up multiple fence triggers can trigger a use-after-free function pointer call in miSyncDestroyFence(). An attacker connects to the X server to set up a fence and awaits that fence, then a second X connection destroys the fence, causing the use-after-free.

Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/f5abfb61994471023d8c6470428c8e30c411cc0b

Reported via ZDI-CAN-30159 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.

A client that sets up multiple SyncCounters and awaits on those triggers can trigger a use-after-free when destroying those counters via a second client connection in FreeCounter().

Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/f5abfb61994471023d8c6470428c8e30c411cc0b

Reported via ZDI-CAN-30163 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.

A stack-based buffer overflow flaw was found in the X.Org X server and Xwayland. The X server has multiple stack buffers sized XkbMaxShiftLevel XkbNumKbdGroups but CheckKeyTypes() does not verify or clamp non-canonical key types to XkbMaxShiftLevel. A client can change key types to excessive shift levels and trigger stack overflows. This is caused by an incomplete fix of CVE-2025-26597. This may be used to crash the server, or for privilege escalation if the X server runs as root.

A mismatch between the X server and the libXfont2 library's maximum font name length can cause a stack buffer overflow during font alias resolution. The server allocates a 256 byte stack buffer but libXfont2's alias target name length is 1024 bytes. A font alias name between 257 and 1023 bytes causes the X server to copy that name into the undersized stack buffer without further checks.

Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bb5158f962dc935e58ef8b4b5fcb31be201a6e07

Reported via ZDI-CAN-30136 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.

389-ds-base security assessment finding 021 (2026-04-22).

Pre-auth LDAP filter injection in CleanAllRUV status-check extop (OID 2.16.840.1.113730.3.6.8). Handler multisupplierextopcleanruvcheckstatus() in replextop.c passes attacker-supplied filter unsanitized to internal cn=config search with replication plugin identity. No auth checks (unlike other replication extops).

With default nsslapd-allow-anonymous-access: on, anonymous bind suffices. Boolean oracle extracts 31 cn=config attributes (replication bind DN, password storage scheme, paths, ACI keywords). Password hashes not extractable via substring.

PoC confirmed: RHEL 7 (389-ds-base-1.3.11.1-5.el79), Fedora 42 (389-ds-base-3.1.4-6.fc42).

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5). Red Hat impact: Moderate. CWE-90, CWE-306, CWE-20.