July 2026 - Sssd-maintainers - Fedora mailing-lists

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 30 Jul '26

30 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 --- Comment #8 from Noah Arcouette <kcu9626(a)gmail.com> --- Hello, I definitely do not have the right experience to fix this but from my efforts I've found two areas that may be the issue: ``` diff --git a/nscd/nscd_helper.c b/nscd/nscd_helper.c index 6319fde6f2..4dfb59291b 100644 --- a/nscd/nscd_helper.c +++ b/nscd/nscd_helper.c @@ -315,6 +315,9 @@ __nscd_get_mapping (request_type type, const char *key, int *ip = (void *) CMSG_DATA (cmsg); mapfd = *ip; + if (mapfd < 0) + goto out_close; + if (__glibc_unlikely (n != keylen && n != keylen + sizeof (mapsize))) goto out_close; diff --git a/nss/makedb.c b/nss/makedb.c index efb8f4af30..acff59a0ba 100644 --- a/nss/makedb.c +++ b/nss/makedb.c @@ -829,7 +829,7 @@ static int print_database (int fd) { struct stat64 st; - if (fstat64 (fd, &st) != 0) + if (fd < 0 || fstat64 (fd, &st) != 0) error (EXIT_FAILURE, errno, gettext ("cannot stat database file")); const struct nss_db_header *header = mmap (NULL, st.st_size, PROT_READ, ``` These are both off of glibc latest, neither check fd before use. I am not capable of testing if this patch works, though I tried. If any one in the future thinks this error is error-ish enough then hopefully this gives them a start and less of a headache tracking down fstat calls. Thanks for you guy's time, Noah -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 30 Jul '26

30 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 --- Comment #7 from Tomas Halman <thalman(a)redhat.com> --- I see, it depends on many things. Anyway as I said, we will not fix that due to our limited capacity. It should not be hard to fix even for someone outside SSSD team. We will appreciate upstream contribution. T. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 30 Jul '26

30 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 --- Comment #6 from Florian Weimer <fweimer(a)redhat.com> --- There is no conditional check in glibc. You must have looked at the wrong sources (sorry, it's complicated due to the sysdeps overrides). (gdb) disassemble fstat Dump of assembler code for function __GI___fstat64: 0x00000000000e4620 <+0>: endbr64 0x00000000000e4624 <+4>: mov $0x5,%eax 0x00000000000e4629 <+9>: syscall 0x00000000000e462b <+11>: cmp $0xfffffffffffff000,%rax 0x00000000000e4631 <+17>: ja 0xe4638 <__GI___fstat64+24> 0x00000000000e4633 <+19>: ret 0x00000000000e4634 <+20>: nopl 0x0(%rax) 0x00000000000e4638 <+24>: mov 0x1047a1(%rip),%rdx # 0x1e8de0 0x00000000000e463f <+31>: neg %eax 0x00000000000e4641 <+33>: mov %eax,%fs:(%rdx) 0x00000000000e4644 <+36>: mov $0xffffffff,%eax 0x00000000000e4649 <+41>: ret End of assembler dump. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 30 Jul '26

30 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Tomas Halman <thalman(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |CLOSED Last Closed| |2026-07-30 10:42:23 --- Comment #5 from Tomas Halman <thalman(a)redhat.com> --- To be precise we do not pass that to kernel but to glibc. First thing that fstat in glibc does is a check `fd < 0`. Checking it on SSSD is of course possible but this will be done just for the sake of debugging tools to make them happy. It simply means that fd is checked 2 times for every valid fd. Considering our capacity, we will not work on this issue but you could submit a patch upstream if you think that it is worth the effort. Regards Tomas -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2497651] New: CVE-2026-14474 sssd: sssd: sudo LDAP provider searches entire directory tree for sudoRole objects by default, enabling privilege escalation [fedora-all]
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2497651 Bug ID: 2497651 Summary: CVE-2026-14474 sssd: sssd: sudo LDAP provider searches entire directory tree for sudoRole objects by default, enabling privilege escalation [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["58986166-cf06-41ca-a3ec-716c8928d097"]} Component: sssd Keywords: Security, SecurityTracking Severity: high Priority: high 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: 2496556 (CVE-2026-14474) 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. When ldap_sudo_search_base is not explicitly configured (the default), SSSD falls back to the domain's root DN and searches the entire LDAP directory tree for objects matching (objectClass=sudoRole) with SUBTREE scope. Any LDAP principal with write access to any subtree can create a sudoRole object granting arbitrary sudo privileges on every SSSD-enrolled host. This affects sudo_provider = ldap and sudo_provider = ad (which delegates to sdap_sudo_init()). sudo_provider = ipa is NOT affected. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2496556 [Bug 2496556] CVE-2026-14474 sssd: sssd: sudo LDAP provider searches entire directory tree for sudoRole objects by default, enabling privilege escalation -- 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=2497651 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 10

[Bug 2497650] New: CVE-2026-14476 sssd: sssd: GPO cache path traversal via unsanitized gPCFileSysPath allows Kerberos authentication bypass [fedora-all]
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2497650 Bug ID: 2497650 Summary: CVE-2026-14476 sssd: sssd: GPO cache path traversal via unsanitized gPCFileSysPath allows Kerberos authentication bypass [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["0c66f03b-252f-48f9-9e00-10588a9a2e5b"]} 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: 2496581 (CVE-2026-14476) 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. The ad_gpo_extract_smb_components() function in SSSD's AD GPO provider converts backslashes to forward slashes in the gPCFileSysPath LDAP attribute but does not sanitize .. path components. A differential between libsmbclient's path clamping (resolves .. at the share root) and the kernel's path resolution (resolves .. fully) allows an attacker with AD GPO management access to write files outside the GPO cache directory as root. On SELinux-enforcing systems (the default on RHEL), the traversal can target /var/lib/sss/pubconf/krb5.include.d/ (labeled sssd_public_t), enabling Kerberos KDC redirection and authentication bypass. On SELinux-permissive or disabled systems, arbitrary file write as root is possible. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2496581 [Bug 2496581] CVE-2026-14476 sssd: sssd: GPO cache path traversal via unsanitized gPCFileSysPath allows Kerberos authentication bypass -- 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=2497650 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 10

[Bug 2494777] New: CVE-2026-12610 sssd: Use-after-free crash in SSSD' 'sssd_pam' process [fedora-all]
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2494777 Bug ID: 2494777 Summary: CVE-2026-12610 sssd: Use-after-free crash in SSSD' 'sssd_pam' process [fedora-all] Product: Fedora Version: rawhide Status: NEW Whiteboard: {"flaws": ["a698ddf8-512e-456f-90fe-129fe3b4753a"]} Component: sssd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: sbalasub(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: 2490288 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. When authenticating with a YubiKey, the SSSD PAM responder crashes inside sss_certmap_match_cert because the sss_certmap_ctx pointer passed to it has already been freed and reused for string data from the p11_child response. The pointer value 0x6e65687475412056 decodes to ASCII "V Auth en" which is part from the certificate label "X.509 Certificate for PIV Authentication" returned by p11_child. This confirms that the freed sss_certmap_ctx memory was reused during response parsing. Root cause: sss_certmap_ctx is owned by the PAM request state. If the request is cancelled or completes while the asynchronous p11_child process is still running, the request state (and the context) is freed. When the child eventually returns and p11_child_done / parse_p11_child_response run, they call sss_certmap_match_cert with a dangling pointer. The certificate data (token name, label, or certificate contents) then occupies the freed memory. Impact: Denial of service: The PAM responder crashes, breaking authentication in some cases. Potential privilege escalation: Because an attacker controls the smartcard/YubiKey contents, they can influence the data that replaces the freed sss_certmap_ctx structure, turning this into a controlled use-after-free in a privileged, long-running process (although this looks hard to exploit). -- 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=2494777 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 13

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Noah Arcouette <kcu9626(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kcu9626(a)gmail.com | |) | --- Comment #4 from Noah Arcouette <kcu9626(a)gmail.com> --- Hello, no this does not cause any security issues, but it certainly shouldn't be expected behaviour. I encountered this while using valgrind and originally thought something terrible had occurred because my program raised a system call fault within valgrind because -1 was being passed to fstat. I never used fstat in the program and barely allocated any data. But, the issue was being raised and data was left allocated. The data is fine, though annoying because I prefer my apps freeing everything and I can't free data I didn't allocate, but that's all normal behaviour as it wasn't leaked data just unfreed data. What isn't normal behaviour is passing -1 to a system call. Why exactly are you doing it this way? Why are you checking if a value is -1 by passing it to the kernel and letting it yell at you? In my opinion, passing -1 as an fd to the kernel should never be expect. It causes debuggers -- specifically valgrind -- to raise one of its deepest faults; no stack trace could be built, it was just a ghost error in my program that made no sense to be there. If this truly is expected behaviour, and you really do want the kernel to check an integer for you, then you should at least create a valgrind suppression file so people don't freak out when their program's passing -1 to a system call. Thank you for your time, Noah -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Florian Weimer <fweimer(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fweimer(a)redhat.co | |m) | --- Comment #3 from Florian Weimer <fweimer(a)redhat.com> --- (In reply to Tomas Halman from comment #2) > Does it actually causes any problems? I think it may cause problems with certain file descriptor debugging tools because using -1 as a file descriptor certainly looks like a missed error check somewhere else. System calls are also a bit slow even if all what they is to report an error. But I haven't reported this. Hopefully Noah can provide some context. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

[Bug 2505515] nss_sss: getpwnam results in a -1 fd being passed to fstat
by bugzilla＠redhat.com 24 Jul '26

24 Jul '26

https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Tomas Halman <thalman(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(kcu9626(a)gmail.com | |) | |needinfo?(fweimer(a)redhat.co | |m) --- Comment #2 from Tomas Halman <thalman(a)redhat.com> --- Hello Noah and Florian, I have checked the code and the described behavior is expected. We leverage the fact that fstat fails for us in such case. Code example: ret = fstat(sss_cli_sd_get(), &mypid_sb); if (ret == 0) { if (S_ISSOCK(mypid_sb.st_mode) && mypid_sb.st_dev == sss_cli_sb->st_dev && mypid_sb.st_ino == sss_cli_sb->st_ino) { sss_cli_close_socket(); } } sss_cli_sd_set(-1); Does it actually causes any problems? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2505515 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 0

2026

2025

2024

2023

2022

2021

2020

Sssd-maintainers July 2026