AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: OOB Read in `autofs_read_getautomntent_input` via unchecked  
effective offset (`SSS_AUTOFS_GETAUTOMNTENT`): 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 `SSS_AUTOFS_GETAUTOMNTENT` 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/autofssrv_cmd.c`, `autofs_read_getautomntent_input`
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 `_max_entries`.
```c
SAFEALIGN_COPY_UINT32_CHECK(&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 (!sss_utf8_check((const uint8_t *)mapname, namelen - 1)) {
return EINVAL;
}
SAFEALIGN_COPY_UINT32_CHECK(_cursor, body + c + namelen + 1, blen, &c);
SAFEALIGN_COPY_UINT32_CHECK(_max_entries, body + c + namelen + 1, blen, &c);
```
`SAFEALIGN_COPY_UINT32_CHECK` 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 `_max_entries` 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  
`SSS_AUTOFS_SOCKET_NAME` with `SCKT_RSP_UMASK` (`0111`), and the available  
build/install context commonly creates the pipe directory with mode `0775`.  
No autofs-specific `allowed_uids` 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 `SSS_AUTOFS_GETAUTOMNTENT`  
(`0x00D2`) with a body containing `uint32_t namelen`, `mapname` bytes, one  
trailing `'\0'`, and no valid trailing `cursor` or `max_entries` 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 `_max_entries`.
```diff
diff --git a/src/responder/autofs/autofssrv_cmd.c  
b/src/responder/autofs/autofssrv_cmd.c
index 000000000..000000000 100644
— a/src/responder/autofs/autofssrv_cmd.c
+++ b/src/responder/autofs/autofssrv_cmd.c
@@ -574,8 +574,10 @@ autofs_read_getautomntent_input(struct cli_ctx  
*cli_ctx,
return EINVAL;
}
   SAFEALIGN_COPY_UINT32_CHECK(_cursor, body + c + namelen + 1, blen, &c);

   SAFEALIGN_COPY_UINT32_CHECK(_max_entries, body + c + namelen + 1,  
blen, &c);
+    c += namelen + 1;
+
+    SAFEALIGN_COPY_UINT32_CHECK(_cursor, body + c, blen, &c);
+    SAFEALIGN_COPY_UINT32_CHECK(_max_entries, body + c, blen, &c);
      *_mapname = mapname;


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