CVE-2026-104045: 
NixOS vulnerability analysis and mitigation

CVE-2026-104045 is a Denial of Service (DoS) vulnerability in SSSD (System Security Services Daemon) caused by a race condition in the autofs responder between asynchronous enumeration completion and map invalidation. A local user can exploit this flaw by repeatedly sending concurrent map enumeration and invalidation requests, causing memory to leak and leading to excessive memory consumption that can disrupt or crash the autofs service. Affected products include SSSD (sssd-2.12.0-1.el10 confirmed), Red Hat Enterprise Linux, and Red Hat OpenShift (ose-rhel-coreos-8 and ose-rhel-coreos-9); Fedora's sssd package is also estimated to be affected. The vulnerability was reported on 2026-05-18 and publicly disclosed on 2026-10-06. It carries a CVSS v3.1 base score of 4.7 (Medium) (Red Hat Advisory, GitHub Advisory).

The root cause is classified as CWE-772 (Missing Release of Resource after Effective Lifetime), manifesting as a memory leak triggered through race-dependent behavior (also consistent with CWE-401). In src/responder/autofs/autofssrv_cmd.c, autofs_setent_send() creates an enumeration context and inserts it into autofs_ctx->maps. If SSS_AUTOFS_SETAUTOMNTENT("auto.master") triggers autofs_orphan_maps() — which deletes all hash entries — before the async lookup finishes, the subsequent autofs_setent_done() unconditionally reparents the now-orphaned enum_ctx back under maps without restoring the hash entry. The timer cleanup path then attempts to delete by key from a table that no longer contains that key, leaving the context and its attached result data allocated indefinitely. Exploitation requires local access to a system where the autofs responder is enabled, plus the ability to issue repeated concurrent SSS_AUTOFS_GETAUTOMNTENT and SSS_AUTOFS_SETAUTOMNTENT("auto.master") requests to win the race; larger maps increase retained memory per leaked context (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation results in unbounded memory growth in the sssd_autofs process, ultimately disrupting or crashing the autofs responder daemon. There is no confidentiality or integrity impact — the vulnerability is strictly an availability issue confined to the autofs responder's own security scope. In typical Red Hat deployments, the autofs responder is only active when SSSD is explicitly configured to manage automount maps, limiting the blast radius; however, systems relying on automount for network filesystem access could experience service disruption (Red Hat Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0, indicating very low probability of exploitation in the near term, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access, the autofs responder to be enabled, and sustained concurrent request timing to win the race condition, making opportunistic exploitation unlikely (GitHub Advisory, Red Hat Advisory).

1. Verify preconditions: Confirm local access to a target system running SSSD with the autofs responder enabled (check /etc/sssd/sssd.conf for [sssd] section listing autofs in services, and verify sssd_autofs is running).
2. Identify a large automount map: Use a map with many entries (e.g., a large auto.master or subordinate map) to maximize memory retained per leaked enumeration context.
3. Launch parallel enumeration loop: In one loop, repeatedly issue SSS_AUTOFS_GETAUTOMNTENT requests for the target map to force asynchronous enumeration (e.g., using sss_autofs client calls or direct socket interaction with the autofs responder socket).
4. Launch parallel invalidation loop: Simultaneously, in a second loop, repeatedly issue SSS_AUTOFS_SETAUTOMNTENT("auto.master") requests to trigger autofs_orphan_maps(), which deletes all hash entries from autofs_ctx->maps.
5. Sustain the race: Run both loops concurrently for several minutes so that enumeration completions regularly race with map invalidations, causing autofs_setent_done() to reparent orphaned contexts without restoring hash entries.
6. Observe memory growth: Monitor sssd_autofs resident memory (e.g., via ps, /proc/<pid>/status, or top) — memory should grow steadily and not return to baseline. Debug logs may show messages such as Unable to remove key '%s' from table (Red Hat Bugzilla).

• Logs: SSSD debug logs (typically /var/log/sssd/sssd_autofs.log) showing repeated messages such as Unable to remove key '<mapname>' from table, indicating cleanup failures against missing hash keys.
• Process: Steadily increasing resident set size (RSS) of the sssd_autofs process observable via ps aux, top, or /proc/<pid>/status that does not return to baseline after map lifetimes expire.
• Logs: High-frequency repeated SSS_AUTOFS_GETAUTOMNTENT and SSS_AUTOFS_SETAUTOMNTENT request entries in SSSD logs from the same local user or process within short time windows.
• File System: Unexpected sssd_autofs process crashes or core dumps in /var/lib/systemd/coredump/ or configured core dump directories (Red Hat Bugzilla).

No released package fix has been established as of the disclosure date; a proposed patch is available in the Red Hat Bugzilla report that guards the reparenting step in autofs_setent_done() to only steal the enumeration context under maps if its hash key is still present. As a workaround, Red Hat recommends disabling the autofs responder where it is not required (remove autofs from the services line in /etc/sssd/sssd.conf and restart SSSD). Where the autofs responder must remain enabled, restrict local access to the responder interface to trusted users and avoid repeated invalidation and enumeration cycles against large maps until a fixed build is available (Red Hat Advisory, Red Hat Bugzilla).

Red Hat has rated this vulnerability as Moderate impact for Red Hat Enterprise Linux, noting that exploitation is limited to a local denial of service against the SSSD autofs responder and requires winning a race condition under sustained concurrent requests. Red Hat also notes that in typical deployments the autofs responder is only active when explicitly configured, further limiting real-world impact. The vulnerability was discovered by the AISLE research team in partnership with Red Hat (Red Hat Advisory).