CVE-2026-90463: Sssd: local oob read in nss service request parsers (`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`)

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local OOB Read in NSS Service Request Parsers (sssnssprotocolparsesvcname / sssnssprotocolparsesvcport): malformed local service lookup requests can force parser reads beyond the declared packet body length and may crash the NSS responder. Requirements to exploit: Ability to run a local process that can connect to the NSS responder UNIX socket and send a crafted SSSNSSGETSERVBYNAME or SSSNSSGETSERVBYPORT request. In common NSS responder setups this is reachable by unprivileged local clients; deployments with stricter socket permissions or explicit UID restrictions reduce exposure. Component affected: sssd-2.12.0-1.el10 NSS responder, src/responder/nss/nssprotocol.c, sssnssprotocolparsesvcname(), sssnssprotocolparsesvcport() 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:L - 3.9 (LOW) AV:L - the attack requires local access to the NSS responder UNIX socket rather than remote network reachability. AC:L - constructing the malformed request body is straightforward and does not require special timing or heap shaping. PR:N - in common NSS responder deployments, an unprivileged local client can reach the socket and submit the request; tighter ACLs would reduce exposure. UI:N - no user interaction is required once the attacker can connect locally. S:U - the effect is confined to the SSSD responder process and its own security scope. C:N - the available evidence shows an invalid read, but not a returned or otherwise usable memory disclosure. I:N - no integrity impact has been demonstrated. A:L - the bug can trigger invalid reads and plausibly crash the responder, but reliability is not established and may depend on allocator layout. Impact: Low. Under the currently established facts, this is a local-only parser bug and the demonstrated effect is an out-of-bounds read with limited, non-deterministic availability impact in the NSS responder. The available evidence does not show privilege escalation, arbitrary code execution, or reliable disclosure of protected data. Under Red Hat's guidance, that best fits Low impact. Embargo: no Reason: The currently established impact is a local responder-side invalid read with at most limited denial-of-service potential. Given the low severity, straightforward validation fix, and absence of demonstrated confidentiality or integrity impact, embargoed handling does not appear necessary. Acknowledgement: Aisle Research Vulnerability Details: This is an input-validation flaw in the NSS responder service-query parsing path. sssnssprotocolparsesvcname() assumes the body contains two consecutive NUL-terminated strings within the declared body length. For a malformed GETSERVBYNAME request whose body is only b"a\x00" (blen == 2), the first scan stops at body[1], and the second scan immediately evaluates body[i + 1] as body[2], which is outside the declared body. c 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; } / Calculate service name length. / for (i = 0, namelen = 0; body[i] != '\0'; i++) { namelen++; } / Calculate protocol name length, use index from previous cycle. / for (protocollen = 0; body[i + 1] != '\0'; i++) { protocollen++; } sssnssprotocolparsesvcport() similarly trusts that the request body is large enough to contain the fixed-size port and padding fields plus a trailing protocol string. It advances the body pointer by 2 sizeof(uint16t) + sizeof(uint32t) without first checking that blen is large enough, and then scans for a NUL terminator from the advanced pointer. c 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; } SAFEALIGNCOPYUINT16(&port, body, NULL); port = ntohs(port); / Move behind the port and padding to get the protocol. / body = body + 2 sizeof(uint16t) + sizeof(uint32t); / Calculate protocol name length. / for (protocollen = 0, i = 0; body[i] != '\0'; i++) { protocollen++; } These parsers are reachable through the SSSNSSGETSERVBYNAME and SSSNSSGETSERVBYPORT command handlers. Under ASan or Valgrind, the malformed requests above produce invalid-read reports in the parser path. On non-instrumented builds, responder termination is plausible but not fully deterministic because the read may remain inside allocator slack rather than fault immediately. Steps to reproduce: 1. Build and run SSSD with ASan, or run the NSS responder under Valgrind, so the invalid read is reported deterministically. 2. Connect to the NSS responder UNIX socket, typically /var/lib/sss/pipes/nss. 3. Send one packet with the normal 16-byte SSSD header (len, cmd, status, reserved) followed by a malformed service lookup body. 4. For SSSNSSGETSERVBYNAME (0x00A1), use body b"a\x00" so only one NUL-terminated string is present. 5. For SSSNSSGETSERVBYPORT (0x00A2), use an 8-byte body such as b"\x00\x50\x00\x00\x00\x00\x00\x00" so the parser advances past the declared body and then scans for a terminator. 6. Observe the invalid read in sssnssprotocolparsesvcname() or sssnssprotocolparsesvcport() in the sanitizer or Valgrind output. A crash is possible, but may not occur on every run without instrumentation. Mitigation: Restrict access to the NSS responder UNIX socket to trusted local clients where feasible. Deployments that already enforce tighter socket permissions or explicit UID restrictions reduce exposure, but the parser bug remains until bounds checks are added. Proposed Fix: Reject zero-length or undersized bodies before dereferencing or advancing into the request, and bound each string scan by the declared body length. diff diff --git a/src/responder/nss/nssprotocol.c b/src/responder/nss/nssprotocol.c — a/src/responder/nss/nssprotocol.c +++ b/src/responder/nss/nssprotocol.c @@ -270,6 +270,10 @@ sssnssprotocolparsesvcname(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + return EINVAL; + } + / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); @@ -277,12 +281,20 @@ sssnssprotocolparsesvcname(struct clictx clictx, } / Calculate service name length. / for (i = 0, namelen = 0; body[i] != '\0'; i++) { + for (i = 0, namelen = 0; i < blen && body[i] != '\0'; i++) { namelen++; }

+ if (i >= blen || i + 1 >= blen) { + return EINVAL; + } + / Calculate protocol name length, use index from previous cycle. / for (protocollen = 0; body[i + 1] != '\0'; i++) { + for (protocollen = 0; (i + 1) < blen && body[i + 1] != '\0'; i++) { protocollen++; } + + if (i + 1 >= blen) { + return EINVAL; + } @@ -326,6 +338,10 @@ sssnssprotocolparsesvcport(struct clictx clictx,

ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen < (2 sizeof(uint16t) + sizeof(uint32t) + 1)) { + return EINVAL; + } + / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); @@ -336,10 +352,15 @@ sssnssprotocolparsesvcport(struct clictx clictx, / Move behind the port and padding to get the protocol. / body = body + 2 sizeof(uint16t) + sizeof(uint32t); + blen -= 2 sizeof(uint16t) + sizeof(uint32t); / Calculate protocol name length. / for (protocollen = 0, i = 0; body[i] != '\0'; i++) { + for (protocollen = 0, i = 0; i < blen && body[i] != '\0'; i++) { protocollen++; } + + if (i >= blen) { + return EINVAL; + }

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat