September 2026 - Sssd-maintainers - Fedora mailing-lists

[Bug 2420946] New: sssd: Cannot log in during Kerberos infrastructure outages
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2420946 Bug ID: 2420946 Summary: sssd: Cannot log in during Kerberos infrastructure outages Product: Fedora Version: 43 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: fweimer(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Earlier today, I couldn't log in until I pulled the Ethernet plug and caused the VPN connection to go down. The journal contains a Kerberos error. This can't be a security feature because making the network go down fixed it. Dec 10 10:10:58 fweimer-oldenburg.csb.redhat.com systemd[1]: redhat-csb-metrics.service: Deactivated successfully. Dec 10 10:10:58 fweimer-oldenburg.csb.redhat.com systemd[1]: Finished redhat-csb-metrics.service - Run CSB Metrics gathering playbook. Dec 10 10:10:58 fweimer-oldenburg.csb.redhat.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=redhat-csb-metrics comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 10 10:10:58 fweimer-oldenburg.csb.redhat.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=redhat-csb-metrics comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 10 10:27:40 fweimer-oldenburg.csb.redhat.com systemd[1]: Starting sssd-kcm.service - SSSD Kerberos Cache Manager... Dec 10 10:27:40 fweimer-oldenburg.csb.redhat.com systemd[1]: Started sssd-kcm.service - SSSD Kerberos Cache Manager. Dec 10 10:27:40 fweimer-oldenburg.csb.redhat.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 10 10:27:40 fweimer-oldenburg.csb.redhat.com sssd_kcm[41444]: Starting up Dec 10 10:27:41 fweimer-oldenburg.csb.redhat.com krb5_child[41429]: Generic error (see e-text) Dec 10 10:27:41 fweimer-oldenburg.csb.redhat.com audit[41415]: AUDIT1100 pid=41415 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="fweimer" exe="/usr/libexec/gdm-session-worker" hostname=fweimer-oldenburg.csb.redhat.com addr=? terminal=/dev/tty1 res=failed' Dec 10 10:27:41 fweimer-oldenburg.csb.redhat.com gdm-password][41415]: pam_sss(gdm-password:auth): authentication failure; logname=fweimer uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=fweimer Dec 10 10:27:41 fweimer-oldenburg.csb.redhat.com gdm-password][41415]: pam_sss(gdm-password:auth): received for user fweimer: 4 (System error) Dec 10 10:27:41 fweimer-oldenburg.csb.redhat.com gdm-password][41415]: gkr-pam: unlocked login keyring Dec 10 10:27:43 fweimer-oldenburg.csb.redhat.com audit[41415]: AUDIT1112 pid=41415 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=18797 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed' Dec 10 10:27:50 fweimer-oldenburg.csb.redhat.com krb5_child[41456]: Generic error (see e-text) Dec 10 10:27:50 fweimer-oldenburg.csb.redhat.com gdm-password][41449]: pam_sss(gdm-password:auth): authentication failure; logname=fweimer uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=fweimer Dec 10 10:27:50 fweimer-oldenburg.csb.redhat.com gdm-password][41449]: pam_sss(gdm-password:auth): received for user fweimer: 4 (System error) Dec 10 10:27:50 fweimer-oldenburg.csb.redhat.com gdm-password][41449]: gkr-pam: unlocked login keyring Dec 10 10:27:50 fweimer-oldenburg.csb.redhat.com audit[41449]: AUDIT1100 pid=41449 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="fweimer" exe="/usr/libexec/gdm-session-worker" hostname=fweimer-oldenburg.csb.redhat.com addr=? terminal=/dev/tty1 res=failed' Dec 10 10:27:52 fweimer-oldenburg.csb.redhat.com audit[41449]: AUDIT1112 pid=41449 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=18797 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed' Dec 10 10:27:55 fweimer-oldenburg.csb.redhat.com gnome-shell[4737]: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Failed: Set global engine failed: Operation was cancelled (No stack trace) Dec 10 10:27:59 fweimer-oldenburg.csb.redhat.com krb5_child[41466]: Generic error (see e-text) Dec 10 10:27:59 fweimer-oldenburg.csb.redhat.com gdm-password][41461]: pam_sss(gdm-password:auth): authentication failure; logname=fweimer uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=fweimer Dec 10 10:27:59 fweimer-oldenburg.csb.redhat.com gdm-password][41461]: pam_sss(gdm-password:auth): received for user fweimer: 4 (System error) Dec 10 10:27:59 fweimer-oldenburg.csb.redhat.com gdm-password][41461]: gkr-pam: unlocked login keyring Dec 10 10:27:59 fweimer-oldenburg.csb.redhat.com audit[41461]: AUDIT1100 pid=41461 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="fweimer" exe="/usr/libexec/gdm-session-worker" hostname=fweimer-oldenburg.csb.redhat.com addr=? terminal=/dev/tty1 res=failed' Dec 10 10:28:00 fweimer-oldenburg.csb.redhat.com audit[41461]: AUDIT1112 pid=41461 uid=0 auid=18797 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=18797 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed' Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2420946 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2530989] New: CVE-2026-87853 sssd: sssd: IdP authentication prefix comparison allows cross-user impersonation [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2530989 Bug ID: 2530989 Summary: CVE-2026-87853 sssd: sssd: IdP authentication prefix comparison allows cross-user impersonation [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["dc0e67b9-019a-4a14-80c9-3961f22f3b90"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: snegrini(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2530888 (CVE-2026-87853) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. A flaw was found in SSSD's IdP authentication provider. The eval_access_token_buf() function in src/providers/idp/idp_auth_eval.c compares the authenticated user's OIDC subject identifier against the requested user's stored SYSDB_UUID using strncmp() with the authenticated identifier's length as the count. This performs a prefix comparison rather than an exact match. An attacker whose complete IdP identifier is a strict prefix of a target user's identifier can authenticate as the target, gaining full access to the target's account, files, groups, and local authorization. With Keycloak's built-in LDAP provider (Import Users disabled), the identifier format f:<federation_id>:<username> naturally produces prefix relationships for usernames like 'admin' and 'administrator'. No victim credential, interaction, or administrative role is required. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2530888 [Bug 2530888] CVE-2026-87853 sssd: sssd: IdP authentication prefix comparison allows cross-user impersonation -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2530989 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 5

[Bug 2539575] New: CVE-2026-90463 sssd: Local OOB Read in NSS Service Request Parsers (`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`) [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2539575 Bug ID: 2539575 Summary: CVE-2026-90463 sssd: Local OOB Read in NSS Service Request Parsers (`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`) [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["81f0bd2e-f1d0-4306-ad43-a0d9757f204e"]} Component: sssd Keywords: Security, SecurityTracking Severity: low Priority: low Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mbenatto(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2479268 (CVE-2026-90463) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Local OOB Read in NSS Service Request Parsers (`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`): 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 `SSS_NSS_GETSERVBYNAME` or `SSS_NSS_GETSERVBYPORT` 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/nss_protocol.c`, `sss_nss_protocol_parse_svc_name()`, `sss_nss_protocol_parse_svc_port()` 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. `sss_nss_protocol_parse_svc_name()` 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 sss_packet_get_body(pctx->creq->in, &body, &blen); /* If not terminated fail. */ if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; } /* Calculate service name length. */ for (i = 0, name_len = 0; body[i] != '\0'; i++) { name_len++; } /* Calculate protocol name length, use index from previous cycle. */ for (protocol_len = 0; body[i + 1] != '\0'; i++) { protocol_len++; } ``` `sss_nss_protocol_parse_svc_port()` 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(uint16_t) + sizeof(uint32_t)` without first checking that `blen` is large enough, and then scans for a NUL terminator from the advanced pointer. ```c sss_packet_get_body(pctx->creq->in, &body, &blen); /* If not terminated fail. */ if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; } SAFEALIGN_COPY_UINT16(&port, body, NULL); port = ntohs(port); /* Move behind the port and padding to get the protocol. */ body = body + 2 * sizeof(uint16_t) + sizeof(uint32_t); /* Calculate protocol name length. */ for (protocol_len = 0, i = 0; body[i] != '\0'; i++) { protocol_len++; } ``` These parsers are reachable through the `SSS_NSS_GETSERVBYNAME` and `SSS_NSS_GETSERVBYPORT` 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 `SSS_NSS_GETSERVBYNAME` (`0x00A1`), use body `b"a\x00"` so only one NUL-terminated string is present. 5. For `SSS_NSS_GETSERVBYPORT` (`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 `sss_nss_protocol_parse_svc_name()` or `sss_nss_protocol_parse_svc_port()` 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/nss_protocol.c b/src/responder/nss/nss_protocol.c — a/src/responder/nss/nss_protocol.c +++ b/src/responder/nss/nss_protocol.c @@ -270,6 +270,10 @@ sss_nss_protocol_parse_svc_name(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + return EINVAL; + } + /* If not terminated fail. */ if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); @@ -277,12 +281,20 @@ sss_nss_protocol_parse_svc_name(struct cli_ctx *cli_ctx, } /* Calculate service name length. */ for (i = 0, name_len = 0; body[i] != '\0'; i++) { + for (i = 0, name_len = 0; i < blen && body[i] != '\0'; i++) { name_len++; } + if (i >= blen || i + 1 >= blen) { + return EINVAL; + } + /* Calculate protocol name length, use index from previous cycle. */ for (protocol_len = 0; body[i + 1] != '\0'; i++) { + for (protocol_len = 0; (i + 1) < blen && body[i + 1] != '\0'; i++) { protocol_len++; } + + if (i + 1 >= blen) { + return EINVAL; + } @@ -326,6 +338,10 @@ sss_nss_protocol_parse_svc_port(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen < (2 * sizeof(uint16_t) + sizeof(uint32_t) + 1)) { + return EINVAL; + } + /* If not terminated fail. */ if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); @@ -336,10 +352,15 @@ sss_nss_protocol_parse_svc_port(struct cli_ctx *cli_ctx, /* Move behind the port and padding to get the protocol. */ body = body + 2 * sizeof(uint16_t) + sizeof(uint32_t); + blen -= 2 * sizeof(uint16_t) + sizeof(uint32_t); /* Calculate protocol name length. */ for (protocol_len = 0, i = 0; body[i] != '\0'; i++) { + for (protocol_len = 0, i = 0; i < blen && body[i] != '\0'; i++) { protocol_len++; } + + if (i >= blen) { + return EINVAL; + } ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2479268 [Bug 2479268] CVE-2026-90463 sssd: Local OOB Read in NSS Service Request Parsers (`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2539575 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 3

[Bug 2539561] New: CVE-2026-90996 sssd: sssd: Denial of Service in NSS responder via crafted zero-length requests [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2539561 Bug ID: 2539561 Summary: CVE-2026-90996 sssd: sssd: Denial of Service in NSS responder via crafted zero-length requests [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["2e6bd2ae-3aa5-4f89-acb8-a51d8377e588"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mbenatto(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2478986 (CVE-2026-90996) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS Risk in NSS Responder Due to Zero-Length Request Body Underflow: crafted header-only NSS requests can force `blen == 0` in parsers that inspect `body[blen - 1]`, and if the final header byte is `'\0'` the path can continue into `sss_utf8_check(body, SIZE_MAX)`, creating a local denial-of-service condition in the NSS responder. Requirements to exploit: Ability to run code as a local unprivileged user on a system where the NSS responder is enabled and reachable through its UNIX socket, and to send a crafted 16-byte request to an affected parser such as `SSS_NSS_GETPWNAM`. Component affected: `sssd-2.12.0-1.el10`; NSS responder request parsing in `src/responder/nss/nss_protocol.c` (`sss_nss_protocol_parse_name`, `sss_nss_protocol_parse_svc_name`, `sss_nss_protocol_parse_svc_port`, `sss_nss_protocol_parse_cert`, and `sss_nss_protocol_parse_sid`) Version affected: `sssd-2.12.0-1.el10` when the NSS responder is enabled and reachable through its local UNIX socket Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not yet established. 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 - Exploitation requires local access to the host and the NSS responder UNIX socket. AC:L - A single crafted 16-byte header-only request is sufficient to reach the vulnerable parsing path. PR:N - No prior privileges are required if the local user can connect to the responder socket. UI:N - No user interaction is needed. S:U - The impact is limited to the NSS responder within the same security scope. C:N - No confidentiality impact was demonstrated. I:N - No integrity impact was demonstrated. A:L - The demonstrated outcome is local responder instability or termination; broader or reliably repeatable impact was not established from the available evidence. Impact: Moderate. A local unprivileged user can affect availability of a system responder with a simple malformed request, which fits Red Hat's Moderate category for flaws that can still cause some availability compromise under constrained conditions. It does not fit Important or Critical because no remote attack path, privilege gain, confidentiality impact, or integrity impact was established. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited to denial of service in the NSS responder, and the fix is a small validation change. Acknowledgement: Aisle Research Vulnerability Details: In `src/responder/nss/nss_protocol.c`, multiple NSS request parsers obtain the request body and immediately test `body[blen - 1]` without first ensuring that `blen` is non-zero. The `SSS_NSS_GETPWNAM` path reaches `sss_nss_protocol_parse_name()`, and similar logic appears in `sss_nss_protocol_parse_svc_name()`, `sss_nss_protocol_parse_svc_port()`, `sss_nss_protocol_parse_cert()`, and `sss_nss_protocol_parse_sid()`. ```c ... sss_packet_get_body(pctx->creq->in, &body, &blen); /* If not terminated fail. */ if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated!\n"); return EINVAL; } /* If the body isn't valid UTF-8, fail */ if (!sss_utf8_check(body, blen - 1)) { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not UTF-8 string!\n"); return EINVAL; } ... ``` `sss_packet_get_body()` derives the body length directly from the packet length: ```c void sss_packet_get_body(struct sss_packet *packet, uint8_t **body, size_t *blen) { *body = packet->buffer + SSS_PACKET_BODY_OFFSET; *blen = sss_packet_get_len(packet) - SSS_NSS_HEADER_SIZE; } ``` A header-only request with `len == SSS_NSS_HEADER_SIZE` therefore yields `blen == 0`. In that case, the first `body[blen - 1]` access reads the last byte of the packet header rather than necessarily moving outside the packet allocation. However, if that header byte is `'\0'`, `sss_nss_protocol_parse_name()` continues into `sss_utf8_check(body, blen - 1)` with `blen - 1 == SIZE_MAX`, creating an effectively unbounded UTF-8 validation read. Based on the available evidence, that is sufficient for a realistic local denial of service against the NSS responder, while broader memory corruption or confidentiality/integrity impact was not established. Steps to reproduce: 1. Ensure SSSD is running with the NSS responder enabled and identify the NSS socket, commonly `/var/lib/sss/pipes/nss`. 2. Connect to that UNIX socket as an unprivileged local user. 3. Send a 16-byte header-only request using a command that reaches `sss_nss_protocol_parse_name()`, such as `SSS_NSS_GETPWNAM (0x0011)`, with `len = 16`, `status = 0`, and `reserved = 0`. 4. Observe the responder under ASan, Valgrind, or equivalent crash monitoring. The parse path reaches `body[blen - 1]` with `blen == 0` and may continue into large-length UTF-8 validation. 5. Repeating the crafted request can destabilize or terminate the NSS responder process. ```python import socket, struct sock = "/var/lib/sss/pipes/nss" # adjust if needed hdr = struct.pack("<IIII", 16, 0x0011, 0, 0) # len, cmd, status, reserved s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) s.connect(sock) s.sendall(hdr) try: print(s.recv(4096)) except Exception as e: print("recv error:", e) s.close() ``` Mitigation: The demonstrated attack path requires local access to the NSS responder UNIX socket. Environments that do not expose that socket to untrusted local users are not exposed to the demonstrated path. Where operationally acceptable, disabling the NSS responder until a fixed package is available removes the vulnerable surface. Proposed Fix: Add an explicit `blen == 0` check before any `body[blen - 1]` access in the affected NSS parsers. ```diff diff --git a/src/responder/nss/nss_protocol.c b/src/responder/nss/nss_protocol.c index 0000000..0000000 100644 — a/src/responder/nss/nss_protocol.c +++ b/src/responder/nss/nss_protocol.c @@ -112,6 +112,11 @@ sss_nss_protocol_parse_name(struct cli_ctx *cli_ctx, const char **_rawname) sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBG_CRIT_FAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated!\n"); return EINVAL; @@ -270,6 +275,11 @@ sss_nss_protocol_parse_svc_name(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBG_CRIT_FAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; @@ -326,6 +336,11 @@ sss_nss_protocol_parse_svc_port(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBG_CRIT_FAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; @@ -372,6 +387,11 @@ sss_nss_protocol_parse_cert(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBG_CRIT_FAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; @@ -416,6 +436,11 @@ sss_nss_protocol_parse_sid(struct cli_ctx *cli_ctx, sss_packet_get_body(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBG_CRIT_FAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n"); return EINVAL; ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2478986 [Bug 2478986] CVE-2026-90996 sssd: sssd: Denial of Service in NSS responder via crafted zero-length requests -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2539561 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2539560] New: CVE-2026-90995 sssd: SSSD: Local denial of service due to NULL pointer dereference in PAM responder [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2539560 Bug ID: 2539560 Summary: CVE-2026-90995 sssd: SSSD: Local denial of service due to NULL pointer dereference in PAM responder [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["69f93f55-b8f4-444f-a873-18c16da9f0e4"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mbenatto(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2479464 (CVE-2026-90995) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in PAM responder: NULL dereference in `get_domain_request_type()` when `SSS_PAM_ITEM_SERVICE` is omitted: a crafted local PAM protocol v2/v3 request that omits the service item can leave `pd->service` as `NULL` and trigger a NULL dereference in the PAM responder when `[pam] pam_app_services` is configured, causing denial of service. Requirements to exploit: Local access sufficient to connect to the PAM responder socket and send a crafted PAM protocol v2/v3 request that omits `SSS_PAM_ITEM_SERVICE`; the target must use a non-empty `[pam] pam_app_services` configuration. Component affected: `sssd-2.12.0-1.el10`, PAM responder code in `src/responder/pam/pamsrv_cmd.c`, specifically `pam_parse_in_data_v2()`, `pam_parse_in_data_v3()`, `pam_forwarder()`, and `get_domain_request_type()`. Version affected: `sssd-2.12.0-1.el10`; reachability depends on a non-empty `[pam] pam_app_services` configuration. 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:L/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - The issue is reachable only from the local system through the PAM responder's UNIX socket. AC:L - A valid request can be crafted without unusual conditions once the protocol framing and required fields are understood. PR:L - The attacker needs local access equivalent to an unprivileged user that can submit requests to the PAM responder interface. UI:N - No user interaction is required. S:U - The crash affects the same security scope as the vulnerable responder. C:N - No confidentiality impact was established. I:N - No integrity impact was established. A:H - A successful trigger can terminate the PAM responder and block authentication requests handled through it until the service recovers. Impact: Moderate. This is an availability-only issue in a security-relevant local service, but exploitation is local and depends on a non-default yet supported `pam_app_services` deployment. That places it below Important under Red Hat guidance, while remaining above Low because the NULL dereference condition is concrete and can be triggered with a crafted request rather than being purely theoretical. Embargo: no Reason: Current evidence supports a local, configuration-dependent denial of service with straightforward mitigation and no demonstrated confidentiality, integrity, or privilege-escalation impact. Acknowledgement: Aisle Research Vulnerability Details: In PAM protocol v2/v3 request parsing, `SSS_PAM_ITEM_SERVICE` is optional, so the service pointer may remain unset: ```c case SSS_PAM_ITEM_SERVICE: ret = extract_string(&pd->service, size, body, blen, &c); if (ret != EOK) return ret; break; ``` The parsed request is then forwarded unconditionally into domain selection: ```c preq->req_dom_type = get_domain_request_type(preq, pctx); ``` `get_domain_request_type()` compares configured application services against `preq->pd->service` without checking for `NULL`: ```c for (int i = 0; pctx->app_services[i]; i++) { if (strcmp(pctx->app_services[i], preq->pd->service) == 0) { req_dom_type = CACHE_REQ_APPLICATION_DOM; break; } } ``` When `[pam] pam_app_services` is non-empty and the request omits `SSS_PAM_ITEM_SERVICE`, the responder can reach `strcmp(nonnull, NULL)` and terminate with a NULL pointer dereference. The established impact from the available evidence is denial of service in the PAM responder. Relevant CWE: `CWE-476` (NULL Pointer Dereference). Steps to reproduce: 1. Configure SSSD with a non-empty `[pam] pam_app_services` value, for example `pam_app_services = app_svc`, and restart the service. 2. Connect locally to the PAM responder socket. In standard builds this is the `SSS_PAM_SOCKET_NAME` path, commonly `/var/lib/sss/pipes/pam`. 3. Send a valid PAM protocol v3 request with correct `SSS_START_OF_PAM_REQUEST` / `SSS_END_OF_PAM_REQUEST` framing, a supported command such as `SSS_PAM_AUTHENTICATE`, and the fields needed for parser success, including `SSS_PAM_ITEM_CLI_PID` and a user or logon value. 4. Omit `SSS_PAM_ITEM_SERVICE` from the request. 5. Observe the request reach `get_domain_request_type()` and dereference `preq->pd->service == NULL` via `strcmp()`, causing the PAM responder process to crash. Mitigation: Until a fix is applied, avoid configuring `pam_app_services` where it is not operationally required. If that setting must remain enabled, limit local ability to submit raw PAM responder requests as far as deployment policy allows and monitor for PAM responder crashes. Proposed Fix: Add a NULL check before comparing `preq->pd->service` against entries in `pctx->app_services[]`. This preserves the existing application-domain selection behavior for valid service names while avoiding the NULL dereference on requests that omit `SSS_PAM_ITEM_SERVICE`. ```diff diff --git a/src/responder/pam/pamsrv_cmd.c b/src/responder/pam/pamsrv_cmd.c index <old>..<new> 100644 — a/src/responder/pam/pamsrv_cmd.c +++ b/src/responder/pam/pamsrv_cmd.c @@ -1857,8 +1857,10 @@ get_domain_request_type(struct pam_auth_req *preq, /* By default, only POSIX domains are to be contacted */ req_dom_type = CACHE_REQ_POSIX_DOM; for (int i = 0; pctx->app_services[i]; i++) { if (strcmp(pctx->app_services[i], preq->pd->service) == 0) { + for (int i = 0; pctx->app_services[i]; i++) { + if (preq->pd->service != NULL + && strcmp(pctx->app_services[i], + preq->pd->service) == 0) { req_dom_type = CACHE_REQ_APPLICATION_DOM; break; } ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2479464 [Bug 2479464] CVE-2026-90995 sssd: SSSD: Local denial of service due to NULL pointer dereference in PAM responder -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2539560 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2539554] New: CVE-2026-90994 sssd: sssd: Denial of Service via malformed PAM v1 requests [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2539554 Bug ID: 2539554 Summary: CVE-2026-90994 sssd: sssd: Denial of Service via malformed PAM v1 requests [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["7eea3e86-8a87-4a43-ad9e-4c1282630edc"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mbenatto(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2479455 (CVE-2026-90994) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Local Out-of-Bounds Read in PAM v1 Parser (`pam_parse_in_data`) Causing Potential DoS: a local client that negotiates protocol v1 and sends an empty or truncated PAM request body can trigger an out-of-bounds read and may terminate the PAM responder, resulting in local denial of service. Requirements to exploit: Local access to the PAM responder UNIX socket, the ability to negotiate protocol v1 with `SSS_GET_VERSION`, and the ability to send a malformed `SSS_PAM_AUTHENTICATE` request body. No user interaction is required. If a deployment restricts PAM socket access more tightly than common configurations, practical exploitability is reduced. Component affected: `sssd-2.12.0-1.el10` PAM responder in `src/responder/pam/pamsrv_cmd.c`, function `pam_parse_in_data()` 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 issue is reachable only from a local client that can connect to the PAM responder UNIX socket. AC:L - Triggering the flaw requires only a malformed protocol v1 request body such as an empty or truncated message. PR:N - The vulnerable parser path itself does not require prior authentication, and common PAM socket deployments allow local clients to reach it; stricter socket ACLs would reduce practical risk. UI:N - No human interaction is needed once local socket access is available. S:U - The impact remains within the PAM responder's own security scope. C:N - The available evidence shows an out-of-bounds read, but not disclosure of sensitive data. I:N - No data modification, privilege gain, or integrity impact is established. A:L - The demonstrated outcome is potential local denial of service, but the available evidence does not show a consistently reliable high-impact crash in every malformed-input case. Impact: Moderate. This is a real local memory-safety flaw in a security-sensitive authentication responder, and malformed v1 requests can affect service availability. However, the available evidence supports local denial of service only, with no demonstrated confidentiality or integrity impact, and the failure appears less than maximally reliable, which places it below Red Hat's Important classification. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited to availability, and the remediation is straightforward. Based on Red Hat guidance, this does not appear to require embargoed handling. Acknowledgement: Aisle Research Vulnerability Details: In the PAM responder's protocol v1 parser, `pam_parse_in_data()` computes `last = blen - 1` before validating `blen`, then repeatedly dereferences `body[end++]` without first proving `end < blen`. This creates two supported failure modes: `blen == 0` underflows `last` to `SIZE_MAX`, and truncated v1 string fields can advance `end` to or beyond the end of the supplied body before the terminator check occurs. ```c static int pam_parse_in_data(struct pam_data *pd, uint8_t *body, size_t blen) { size_t start; size_t end; size_t last; int ret; last = blen - 1; end = 0; /* user name */ for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; pd->logon_name = (char *) &body[start]; ... } ``` The same unchecked `body[end++]` pattern is then repeated while parsing `service`, `tty`, `ruser`, and `rhost`. Protocol version 1 remains registered, and the request dispatch path still selects `pam_parse_in_data()` when v1 is negotiated, so the vulnerable parser remains reachable through the PAM responder. Based on the available evidence, the expected security effect is an out-of-bounds read that may cause responder termination or restart behavior depending on build hardening and runtime supervision; code execution, data disclosure, and privilege escalation are not established. Steps to reproduce: 1. Build or run the package with ASAN enabled, or run the PAM responder under a debugger. 2. Connect to the PAM responder UNIX socket, typically `/var/lib/sss/pipes/pam` in standard deployments. 3. Send `SSS_GET_VERSION` (`0x0001`) with body `uint32(1)` to negotiate protocol v1. 4. On the same connection, send `SSS_PAM_AUTHENTICATE` (`0x00F1`) with either an empty body (`blen == 0`) or a truncated v1 body that omits one or more required `'\0'` terminators. 5. Observe an ASAN invalid read or responder termination/restart behavior, depending on build and runtime conditions. Mitigation: Restrict local access to the PAM responder UNIX socket to trusted users where operationally possible. If protocol v1 requests can be avoided in the affected environment, that reduces exposure, but there is no complete mitigation short of patching the v1 parser to reject zero-length and truncated inputs before any out-of-bounds dereference occurs. Proposed Fix: Reject zero-length bodies before evaluating `blen - 1`, and check `end >= blen` before each `body[end]` dereference while parsing the v1 NUL-terminated fields. ```diff diff --git a/src/responder/pam/pamsrv_cmd.c b/src/responder/pam/pamsrv_cmd.c index 0000000..1111111 100644 — a/src/responder/pam/pamsrv_cmd.c +++ b/src/responder/pam/pamsrv_cmd.c @@ -475,6 +475,11 @@ static int pam_parse_in_data(struct pam_data *pd, size_t last; int ret; + /* Prevent size_t underflow and invalid first dereference */ + if (blen == 0) { + return EINVAL; + } + last = blen - 1; end = 0; @@ -482,27 +487,42 @@ static int pam_parse_in_data(struct pam_data *pd, /* user name */ for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->logon_name = (char *) &body[start]; for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->service = (char *) &body[start]; for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->tty = (char *) &body[start]; for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->ruser = (char *) &body[start]; for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->rhost = (char *) &body[start]; ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2479455 [Bug 2479455] CVE-2026-90994 sssd: sssd: Denial of Service via malformed PAM v1 requests -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2539554 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 3

[Bug 2537840] New: CVE-2026-90462 sssd: SSSD: Fail-open in LDAP ppolicy access check allows continued authorization [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2537840 Bug ID: 2537840 Summary: CVE-2026-90462 sssd: SSSD: Fail-open in LDAP ppolicy access check allows continued authorization [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["9adc4d0c-226b-470a-a3b8-69a7111c3102"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mbenatto(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2479483 (CVE-2026-90462) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Fail-open in LDAP ppolicy access check when user lookup returns zero results: missing-user LDAP ppolicy lookups can incorrectly return success and cache an allow decision, permitting continued authorization for a deleted or deprovisioned user in affected configurations. Requirements to exploit: SSSD must use `access_provider = ldap` with `ldap_access_order` including `ppolicy` or `lockout`, the target user must still have locally retained SSSD user state, the ppolicy LDAP lookup for that user must return zero entries, and a new access check must reach the online LDAP access path. Component affected: `sssd-2.12.0-1.el10`, `src/providers/ldap/sdap_access.c`, `sdap_access_ppolicy_step_done()` Version affected: `sssd-2.12.0-1.el10` when SSSD is configured with the LDAP access provider and `ldap_access_order` includes `ppolicy` or `lockout` Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N - 5.3 (MEDIUM) AV:N - The vulnerable authorization path can be reached through normal remote login or access flows that rely on SSSD. AC:L - Once the affected configuration exists, the triggering condition is a zero-result LDAP lookup for the user. PR:L - Exploitation requires prior valid account context; this is not anonymous access. UI:N - No separate user interaction is required. S:U - The flaw affects the same authorization boundary enforced by SSSD. C:L - Successful exploitation can preserve access to information that should no longer be available to the deleted account. I:L - The same stale authorization can permit limited modification of resources available to that account. A:N - The available evidence does not show a direct availability impact. Impact: Moderate. The flaw can preserve access for a deleted or deprovisioned account, which is a real confidentiality and integrity concern, but exploitation depends on a specific non-default LDAP access-control configuration and pre-existing account state. This is a meaningful security issue, but not an easily exploited default-path compromise. Embargo: no Reason: The issue is configuration-dependent, requires prior account context, and has straightforward operational mitigations pending a fix. Acknowledgement: Aisle Research Vulnerability Details: In `sdap_access_ppolicy_step_done()`, `locked` is initialized to `false`. When the base-scoped LDAP search returns zero results, the function logs that access is being denied but does not set a deny result. Execution then reaches the common tail, where `locked == false` causes `ret = EOK`, and the code writes an allow-state cache entry for future checks. ```c bool locked = false; ... if (num_results < 1) { DEBUG(SSSDBG_CONF_SETTINGS, "User [%s] was not found with the specified filter. " "Denying access.\n", state->username); } ... if (locked) { DEBUG(SSSDBG_TRACE_FUNC, "Access denied by online lookup - account is locked.\n"); ret = ERR_ACCESS_DENIED; } else { DEBUG(SSSDBG_TRACE_FUNC, "Access granted by online lookup - account is not locked.\n"); ret = EOK; } ... tret = sdap_save_user_cache_bool(state->domain, state->username, SYSDB_LDAP_ACCESS_CACHED_LOCKOUT, !locked); ``` The analogous filter path treats `num_results < 1` as a deny condition and returns `ERR_ACCESS_DENIED`, so the ppolicy handling is a fail-open inconsistency. Based on the available evidence, the security consequence is an authorization bypass for previously known users after deletion or deprovisioning, not a broader unauthenticated compromise. Steps to reproduce: 1. Configure SSSD with `access_provider = ldap` and `ldap_access_order = ppolicy` or `ldap_access_order = lockout`. 2. Ensure a test user exists, authenticates once, and remains present in SSSD state so local user lookup still succeeds. 3. Delete or move the user entry in LDAP so the base-scope lookup used by the ppolicy step returns zero results. 4. Perform a new login or access check for that username while the backend is online. 5. Observe a log sequence equivalent to `User [...] was not found with the specified filter. Denying access.` followed by `Access granted by online lookup - account is not locked.` 6. Observe that the final decision is success (`EOK`) and that the cached lockout allow flag is written as `true` (`!locked`). Mitigation: Until a fix is available, avoid using `ppolicy` or `lockout` as the sole LDAP access decision where rapid deprovisioning enforcement is required. Clearing stale SSSD cache entries when users are removed from LDAP also reduces the exposure window because the reproduced condition depends on locally retained user state. Proposed Fix: Explicitly deny access when the ppolicy lookup returns zero results so the function cannot fall through to the success path or cache an allow decision. ```diff diff --git a/src/providers/ldap/sdap_access.c b/src/providers/ldap/sdap_access.c index 0000000..0000000 100644 — a/src/providers/ldap/sdap_access.c +++ b/src/providers/ldap/sdap_access.c @@ -1953,6 +1953,8 @@ static void sdap_access_ppolicy_step_done(struct tevent_req *subreq) if (num_results < 1) { DEBUG(SSSDBG_CONF_SETTINGS, "User [%s] was not found with the specified filter. " "Denying access.\n", state->username); + locked = true; + ret = ERR_ACCESS_DENIED; } else if (results == NULL) { DEBUG(SSSDBG_CRIT_FAILURE, "num_results > 0, but results is NULL\n"); ret = ERR_INTERNAL; ``` Setting either `locked = true` or `ret = ERR_ACCESS_DENIED` is sufficient; setting both makes the intended deny behavior explicit and prevents an allow-cache write. ------ This report was generated using AI technology. Always review AI-generated content prior to use Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2479483 [Bug 2479483] CVE-2026-90462 sssd: SSSD: Fail-open in LDAP ppolicy access check allows continued authorization -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2537840 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2510309] New: CVE-2026-68744 sssd: sssd: NSS responder uninitialized heap disclosure in initgroups reply [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2510309 Bug ID: 2510309 Summary: CVE-2026-68744 sssd: sssd: NSS responder uninitialized heap disclosure in initgroups reply [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["8b3d17e9-5164-4ac0-8024-62ad1ee46a96"]} Component: sssd Keywords: Security, SecurityTracking Severity: low Priority: low Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: snegrini(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2509761 (CVE-2026-68744) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. A flaw was found in SSSD. The sss_nss_protocol_fill_initgr() function in the NSS responder (src/responder/nss/nss_protocol_grent.c) pre-allocates the reply packet for all group entries using sss_packet_grow() but does not shrink the packet when groups are skipped (non-POSIX, incomplete, or filtered groups). sss_packet_grow() uses talloc_realloc_size(), which does not zero-fill newly allocated memory. The trailing unwritten bytes therefore contain uninitialized heap data from the sssd_nss process and are transmitted to the client at the grown packet length. A local attacker can exploit this by sending SSS_NSS_INITGR (0x0026) requests to the world-writable NSS responder socket (/var/lib/sss/pipes/nss), receiving uninitialized heap content in the reply tail. Through heap grooming (for example, a preceding getpwnam query), the leak can disclose other users' cached directory records and process heap pointers. The leaked data is limited to the sssd_nss heap (directory-level information); credentials reside in separate sssd_pam and sssd_be processes. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2509761 [Bug 2509761] CVE-2026-68744 sssd: sssd: NSS responder uninitialized heap disclosure in initgroups reply -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2510309 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2510306] New: CVE-2026-68742 sssd: sssd: NSS responder out-of-bounds read via unchecked addrlen in GETHOSTBYADDR [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2510306 Bug ID: 2510306 Summary: CVE-2026-68742 sssd: sssd: NSS responder out-of-bounds read via unchecked addrlen in GETHOSTBYADDR [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["719402a5-fc23-44d6-8dae-61c246541e04"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: snegrini(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2509762 (CVE-2026-68742) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. A flaw was found in SSSD. The sss_nss_protocol_parse_addr() function in the NSS responder (src/responder/nss/nss_protocol.c) extracts a 32-bit addrlen value from the client request but only validates that the body is at least 8 bytes, without checking that addrlen fits within the remaining packet body. This unvalidated length is passed through to talloc_memdup() in cache_req_data_create(), which copies addrlen bytes from the small request buffer, causing a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable NSS responder socket (/var/lib/sss/pipes/nss) and sending a SSS_NSS_GETHOSTBYADDR (0x0053) request with a large addrlen value and a valid address family payload so that inet_ntop() succeeds. Successful exploitation crashes the sssd_nss responder, causing a denial of service for NSS name resolution. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2509762 [Bug 2509762] CVE-2026-68742 sssd: sssd: NSS responder out-of-bounds read via unchecked addrlen in GETHOSTBYADDR -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2510306 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2510305] New: CVE-2026-68743 sssd: sssd: PAM responder out-of-bounds read via unchecked auth_token_length in protocol v1 [fedora-all]
by bugzilla＠redhat.com 08 Oct '26

08 Oct '26

https://bugzilla.redhat.com/show_bug.cgi?id=2510305 Bug ID: 2510305 Summary: CVE-2026-68743 sssd: sssd: PAM responder out-of-bounds read via unchecked auth_token_length in protocol v1 [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["382316db-32a7-40a3-9028-c43356402e23"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: snegrini(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Blocks: 2509760 (CVE-2026-68743) Target Milestone: --- Classification: Fedora Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. A flaw was found in SSSD. The extract_authtok_v1() function in the PAM responder (src/responder/pam/pamsrv_cmd.c) reads a 32-bit auth_token_length from the client request but does not validate it against the remaining buffer size before passing it to sss_authtok_set_password(). When sss_authtok_set_string() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized auth_token_length value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (*c+data_size > blen), which is missing from v1. Successful exploitation crashes the sssd_pam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2509760 [Bug 2509760] CVE-2026-68743 sssd: sssd: PAM responder out-of-bounds read via unchecked auth_token_length in protocol v1 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2510305 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

2026

2025

2024

2023

2022

2021

2020

Sssd-maintainers September 2026