CVE-2026-104043: Sssd: sssd: denial of service via undersized packet parsing in nss responder

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: NSS responder length underflow in packet parsing (ssspacketgetbody) enables local OOB read / crash: undersized client-controlled packet lengths can underflow the computed body length and drive an out-of-bounds read in NSS request parsing, likely crashing the responder. Requirements to exploit: An attacker needs the ability to run a local process on a system running the NSS responder and to connect to its UNIX socket and send a request with len < 16. In the reviewed tree, NSS is initialized with SCKTRSPUMASK, and the peer-UID gate is only applied when alloweduids is configured; deployment-specific socket ACLs or socket-activation settings may still reduce which local users can reach the socket. Component affected: sssd-2.12.0-1.el10, NSS responder packet parsing in src/responder/common/responderpacket.c (ssspacketrecv(), ssspacketgetbody()) and src/responder/nss/nssprotocol.c (sssnssprotocolparsename()) Version affected: sssd-2.12.0-1.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - Exploitation requires local access to the NSS responder UNIX socket. AC:L - The trigger is a short packet header with a client-controlled len smaller than the 16-byte protocol header; no race or uncommon precondition is established. PR:N - Where the NSS socket is reachable, the reviewed tree does not require responder-specific privileges before sending the malformed request; deployment-specific ACLs can reduce reachability. UI:N - No user interaction is required. S:U - The impact stays within the SSSD responder's security scope. C:N - The available materials show an out-of-bounds read but do not demonstrate practical data disclosure. I:N - No integrity impact is demonstrated. A:H - The established effect is a likely responder crash or denial of service in the NSS path. Impact: Moderate. The available evidence supports a low-complexity local denial of service against the NSS responder, not remote compromise, privilege escalation, or a demonstrated confidentiality breach. Under Red Hat's guidance this is more than Low because it can disrupt availability of NSS account lookup functionality on exposed systems, but it is below Important because the currently supported impact is local and availability-focused. Embargo: no Reason: The demonstrated impact is a local responder crash / denial of service with straightforward remediation and practical exposure reduction through local socket access controls. Acknowledgement: Aisle Research Vulnerability Details: The directly observed path is request receipt in ssspacketrecv() followed by NSS request parsing in sssnssprotocolparsename(). ssspacketrecv() accepts a packet once packet->iop >= newlen, but there is no lower-bound check that newlen = SSSNSSHEADERSIZE. ssspacketgetbody() then subtracts SSSNSSHEADERSIZE unconditionally, and the NSS name parser dereferences body[blen - 1] before any length check. With a crafted header such as len=8, blen underflows as sizet and the null-termination test becomes an out-of-bounds read. c int ssspacketrecv(struct ssspacket packet, int fd) { ... packet->iop += rb; if (packet->iop < SSSPACKETCMDOFFSET) { return EAGAIN; } newlen = ssspacketgetlen(packet); if (newlen > packet->memsize) { enum sssclicommand cmd = ssspacketgetcmd(packet); sizet maxrecvsize; ... } if (packet->iop < newlen) { return EAGAIN; } return EOK; } void ssspacketgetbody(struct ssspacket packet, uint8t body, sizet blen) { body = packet->buffer + SSSPACKETBODYOFFSET; blen = ssspacketgetlen(packet) - SSSNSSHEADERSIZE; } errnot sssnssprotocolparsename(struct clictx clictx, const char rawname) { ... ssspacketgetbody(pctx->creq->in, &body, &blen); / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated!\n"); return EINVAL; } ... } The likely consequence is responder termination or request failure in the NSS path. The available materials do not establish a reliable confidentiality disclosure, integrity impact, or code execution primitive. The behavior is confirmed in the reviewed sssd-2.12.0 source tree; the available materials do not establish a narrower introduction point or a released fix. Steps to reproduce: 1. Run a system with SSSD active and the NSS responder enabled. 2. As a local user that can reach the NSS responder UNIX socket, connect to the runtime NSS socket path. A common path is /var/lib/sss/pipes/nss. 3. Send an 8-byte request header with len=8 and cmd=SSSNSSGETPWNAM (0x0011): python import socket, struct s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.connect("/var/lib/sss/pipes/nss") s.sendall(struct.pack("<II", 8, 0x0011)) 4. Observe that the responder may close the connection unexpectedly or crash. Under ASAN or Valgrind, the invalid read is expected in the NSS parse path around the body[blen - 1] check. Mitigation: Until a fixed package is available, restrict access to the NSS responder UNIX socket to trusted local users where operationally possible. Where deployment configuration supports it, apply peer-UID restrictions such as alloweduids or equivalent socket ACLs. This reduces reachability but does not correct the parser flaw. Proposed Fix: Add a minimum-length guard in ssspacketrecv() before the packet is accepted as complete. diff diff --git a/src/responder/common/responderpacket.c b/src/responder/common/responderpacket.c index 0000000..0000000 100644 — a/src/responder/common/responderpacket.c +++ b/src/responder/common/responderpacket.c @@ -217,6 +217,12 @@ int ssspacketrecv(struct ssspacket packet, int fd) newlen = ssspacketgetlen(packet); + if (newlen < SSSNSSHEADERSIZE) { + DEBUG(SSSDBGOPFAILURE, + "Refusing undersized packet from fd %d (length %zu bytes)\n", + fd, newlen); + return EINVAL; + } + if (newlen > packet->memsize) { enum sssclicommand cmd = ssspacketgetcmd(packet); sizet maxrecvsize; ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat