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.
GDB backtrace:
#0 sss_certmap_match_cert (ctx=ctx@entry=0x556dc124d0a0, der_cert=<optimized out>, der_size=<optimized out>) at ../src/lib/certmap/sss_certmap.c:976
#1 0x0000556dbfee56d1 in parse_p11_child_response (mem_ctx=0x556dc1295ac0,
buf=0x556dc129f520 "0\nYubiKey PIV #36610559\n/usr/lib/x86_64-linux-gnu/libykcs11.so\n01\nX.509 Certificate for PIV Authentication\nMIIChzCCAg2gAwIBAgIUPSWlMzFusPgy2vZLPrpgJ9r+ijcwCgYIKoZIzj0EAwMwQDELMAkGA1UEBhMCRlIxDzANBgNVB"..., buf_len=976, sss_certmap_ctx=0x556dc124d0a0, _cert_list=0x556dc1295af0)
at ../src/responder/pam/pamsrv_p11.c:684
#2 p11_child_done (subreq=0x0) at ../src/responder/pam/pamsrv_p11.c:1015
#3 0x00007f4b8b63cfd9 in _read_pipe_handler (ev=<optimized out>, fde=<optimized out>, flags=<optimized out>, pvt=<optimized out>)
at ../src/util/child_common.c:572
#4 0x00007f4b8b928815 in tevent_common_invoke_fd_handler (fde=0x556dc12955a0, flags=1, removed=removed@entry=0x0) at lib/tevent/tevent_fd.c:174
#5 0x00007f4b8b92fa56 in epoll_event_loop (epoll_ev=0x556dc122c710, tvalp=0x7ffc4e9f50d0) at lib/tevent/tevent_epoll.c:696
#6 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at lib/tevent/tevent_epoll.c:926
#7 0x00007f4b8b92d48b in std_event_loop_once (ev=0x556dc122c420, location=0x7f4b8b6c5d32 "../src/util/server.c:799") at lib/tevent/tevent_standard.c:110
#8 0x00007f4b8b927953 in _tevent_loop_once (ev=ev@entry=0x556dc122c420, location=location@entry=0x7f4b8b6c5d32 "../src/util/server.c:799")
at lib/tevent/tevent.c:820
#9 0x00007f4b8b927c4b in tevent_common_loop_wait (ev=0x556dc122c420, location=0x7f4b8b6c5d32 "../src/util/server.c:799") at lib/tevent/tevent.c:949
#10 0x00007f4b8b92d41b in std_event_loop_wait (ev=0x556dc122c420, location=0x7f4b8b6c5d32 "../src/util/server.c:799") at lib/tevent/tevent_standard.c:141
#11 0x00007f4b8b69f161 in server_loop (main_ctx=0x556dc122c7a0) at ../src/util/server.c:799
#12 0x0000556dbfedec8f in main (argc=<optimized out>, argv=<optimized out>) at ../src/responder/pam/pamsrv.c:487
Corruption evidence:
(gdb) p *ctx
$6 = {prio_list = 0x6543203930352e58, debug = 0x7461636966697472, debug_priv = 0x495020726f662065, default_mapping_rule = 0x6e65687475412056,
mapv = (unknown: 0x61636974), digest_list = 0x556dc1252f00}
(gdb) p *(ctx->default_mapping_rule)
Cannot access memory at address 0x6e65687475412056
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).
Suggested fix:
I’m not entirely sure what is the best course of action here. Either keep the sss_certmap_ctx somewhere instead of freeing it in p11_refresh_certmap_ctx, or ensure the child is terminated without calling the callback when the parent PAM request is freed.
[This bug report was drafted with LLM assistance.]
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.
GDB backtrace:
Corruption evidence:
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:
Suggested fix:
I’m not entirely sure what is the best course of action here. Either keep the sss_certmap_ctx somewhere instead of freeing it in p11_refresh_certmap_ctx, or ensure the child is terminated without calling the callback when the parent PAM request is freed.
[This bug report was drafted with LLM assistance.]