CVE-2026-104029: Sssd: sssd: denial of service via out-of-bounds read in autofs responder

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: OOB Read in autofsreadgetautomntentinput via unchecked effective offset (SSSAUTOFSGETAUTOMNTENT): a crafted local autofs request can trigger a small out-of-bounds read in the responder parser and may crash the autofs responder. Requirements to exploit: A local attacker must be able to connect to the autofs UNIX socket and send a crafted SSSAUTOFSGETAUTOMNTENT request. The autofs responder must be enabled. The reviewed code suggests common deployments expose this socket broadly, but actual reachability still depends on the deployed socket and directory permissions. Component affected: sssd-2.12.0-1.el10, src/responder/autofs/autofssrvcmd.c, autofsreadgetautomntentinput Version affected: sssd-2.12.0-1.el10 when the autofs responder is enabled 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.3 (LOW) AV:L - exploitation requires local access to the autofs UNIX socket. AC:L - the malformed packet layout is straightforward once the request format is known. PR:N - no additional SSSD-side privilege check for the autofs responder is established in the reviewed code beyond socket reachability. UI:N - no user interaction is required. S:U - the impact is limited to the same responder security scope. C:N - the available evidence does not establish a meaningful confidentiality impact. I:N - the available evidence does not establish an integrity impact. A:L - the technically supported outcome is responder instability or termination from a small out-of-bounds read, not reliable broader service loss. Impact: Low. Under the Red Hat severity guidance, this fits Low rather than Moderate or Important because exploitation is local-only, depends on the autofs responder being enabled and reachable, and the supported impact is limited to a likely responder-only availability issue. The current evidence does not establish privilege escalation, protected data disclosure, or system compromise. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited, and a straightforward fix and operational mitigations are available. The available evidence does not support a need for embargoed handling. Acknowledgement: Aisle Research Vulnerability Details: The parser validates namelen and checks that mapname[namelen] is NUL-terminated, but it does not advance the checked cursor c past mapname before reading cursor and maxentries. c SAFEALIGNCOPYUINT32CHECK(&namelen, body+c, blen, &c); if (namelen == 0 || namelen > blen - c) { return EINVAL; } mapname = (const char )body + c; / if not null-terminated fail / if (mapname[namelen] != '\0') { return EINVAL; } / If the name isn't valid UTF-8, fail / if (!sssutf8check((const uint8t )mapname, namelen - 1)) { return EINVAL; } SAFEALIGNCOPYUINT32CHECK(cursor, body + c + namelen + 1, blen, &c); SAFEALIGNCOPYUINT32CHECK(maxentries, body + c + namelen + 1, blen, &c); SAFEALIGNCOPYUINT32CHECK validates the current cursor value c against blen, but the actual source pointer is whatever the caller passes. In this function, the checked value remains near the start of the buffer while the effective read address includes + namelen + 1. As a result, an attacker can satisfy the macro's bounds check while forcing the first cursor read to start at body + blen. For sufficiently large inputs that also satisfy the second size check, the maxentries read is out of bounds as well. A practical shape is blen = 4 + namelen + 1, with namelen = blen - 5 and the final in-bounds byte set to '\0'. That layout passes the visible parser checks and places the first cursor read exactly at the end of the request body. The technically supported consequence is a small out-of-bounds read with possible responder crash or instability; reliable confidentiality or integrity impact is not established. The reviewed code also indicates that the autofs responder uses SSSAUTOFSSOCKETNAME with SCKTRSPUMASK (0111), and the available build/install context commonly creates the pipe directory with mode 0775. No autofs-specific alloweduids restriction is evident in the reviewed path. This suggests unprivileged local reachability in common deployments, although final exposure still depends on runtime packaging and filesystem permissions. Steps to reproduce: 1. Enable and start the autofs responder so the autofs UNIX socket is present, typically at /var/lib/sss/pipes/autofs. 2. Connect to that socket and send command SSSAUTOFSGETAUTOMNTENT (0x00D2) with a body containing uint32t namelen, mapname bytes, one trailing '\0', and no valid trailing cursor or maxentries fields. 3. Choose the body so the early checks pass but the first cursor read begins at the end of the buffer: set blen = 4 + namelen + 1, set namelen = blen - 5, and ensure the final in-bounds byte is '\0'. 4. Observe the out-of-bounds read when cursor is parsed from body + c + namelen + 1, which resolves to body + blen for the first read. Sanitized builds should report the access immediately; non-sanitized builds may terminate the responder or show instability depending on allocator and memory layout. Mitigation: Disable the autofs responder where it is not required. If it must remain enabled, restrict access to the autofs socket and its containing directory to trusted local users until a fixed build is available. Proposed Fix: Advance c past mapname and its terminating NUL before parsing cursor and maxentries. diff diff --git a/src/responder/autofs/autofssrvcmd.c b/src/responder/autofs/autofssrvcmd.c index 000000000..000000000 100644 — a/src/responder/autofs/autofssrvcmd.c +++ b/src/responder/autofs/autofssrvcmd.c @@ -574,8 +574,10 @@ autofsreadgetautomntentinput(struct clictx clictx, return EINVAL; } SAFEALIGNCOPYUINT32CHECK(cursor, body + c + namelen + 1, blen, &c);

SAFEALIGNCOPYUINT32CHECK(maxentries, body + c + namelen + 1, blen, &c); + c += namelen + 1; + + SAFEALIGNCOPYUINT32CHECK(cursor, body + c, blen, &c); + SAFEALIGNCOPYUINT32CHECK(maxentries, body + c, blen, &c); mapname = mapname;

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

— Red Hat