SSSD autofs responder: memory from successful requests is held until disconnect, allowing local memory exhaustion

CVSS 5.5CVE-2026-104031Kernel, userspace & hypervisorcurated

Impact

With the autofs responder enabled, memory allocated while handling successful requests is not freed until the client connection closes. A local user who holds one connection open and keeps submitting valid requests drives SSSD's memory use up until the process or the node runs out of memory. This is a resource-exhaustion denial of service rather than a parsing bug, so it needs no malformed input and nothing to go wrong - just a loop. On a shared GPU node, memory pressure from the identity daemon can take down co-resident workloads too, not only automount, and recovering may require restarting SSSD or the node.

Who can reach it

Any local unprivileged user on the node that can connect to the SSSD autofs responder UNIX socket and issue ordinary, valid requests. Local access only.

What to do

Install the fixed sssd packages and restart sssd to reclaim the leaked memory; the record does not name a fixed version, so take it from the Red Hat advisory. Daemon restart is enough - no node reboot - though a node already pushed into OOM may need more. If the node does not consume SSSD-provided automount maps, disabling the autofs responder removes the exposure.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-104031 https://access.redhat.com/security/cve/CVE-2026-104031 https://bugzilla.redhat.com/show_bug.cgi?id=2479418

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.