Description of problem: Running 'sudo -s' crashes with free(): double free detected in tcache 2 Version-Release number of selected component (if applicable): sudo-1.9.2-1.fc32.x86_64 sssd-2.3.1-2.fc32.x86_64 How reproducible: Always (on one machine) Steps to Reproduce: 1. sudo -s Actual results: free(): double free detected in tcache 2 Expected results: Root superpowers Additional info: This is a freeipa enrolled machine. Backtrace: (gdb) bt #0 0x00007fdb051ae9e5 in raise () from /lib64/libc.so.6 #1 0x00007fdb05197895 in abort () from /lib64/libc.so.6 #2 0x00007fdb051f2857 in __libc_message () from /lib64/libc.so.6 #3 0x00007fdb051f9d7c in malloc_printerr () from /lib64/libc.so.6 #4 0x00007fdb051fb38d in _int_free () from /lib64/libc.so.6 #5 0x00007fdb056fa205 in sss_sudo_free_values () from /usr/lib64/libsss_sudo.so #6 0x00007fdaf779faaf in sss_rule_to_priv (rc_out=<synthetic pointer>, rule=0x564ee50595d0, handle=0x564ee5055690) at ./sssd.c:336 #7 sss_to_sudoers (sss_result=0x564ee5057d50, handle=0x564ee5055690) at ./sssd.c:398 #8 sudo_sss_query (nss=<optimized out>, pw=<optimized out>) at ./sssd.c:684 #9 0x00007fdaf778f9b9 in sudoers_lookup (snl=<optimized out>, pw=0x564ee5054d78, validated=validated@entry=96, pwflag=pwflag@entry=0) at ./parse.c:297 #10 0x00007fdaf77994ca in sudoers_policy_main (argc=argc@entry=1, argv=argv@entry=0x564ee504aa80, pwflag=pwflag@entry=0, env_add=env_add@entry=0x0, verbose=verbose@entry=false, closure=closure@entry=0x7fff1050fc70) at ./sudoers.c:368 #11 0x00007fdaf7792090 in sudoers_policy_check (argc=1, argv=0x564ee504aa80, env_add=0x0, command_infop=0x7fff1050fd30, argv_out=0x7fff1050fd38, user_env_out=0x7fff1050fd40, errstr=0x7fff1050fd58) at ./policy.c:974 #12 0x0000564ee349b14d in policy_check (user_env_out=0x7fff1050fd40, argv_out=0x7fff1050fd38, command_info=0x7fff1050fd30, env_add=0x0, argv=0x564ee504aa80, argc=1) at ./sudo.c:1162 #13 main (argc=<optimized out>, argv=<optimized out>, envp=0x7fff1050ffd0) at ./sudo.c:267 (gdb)
│ 332 cleanup: │ │ 333 if (cn_array != NULL) │ │ 334 handle->fn_free_values(cn_array); │ │ 335 if (cmnds != NULL) │ │ >336 handle->fn_free_values(cmnds); │ │ 337 if (hosts != NULL) │ │ 338 handle->fn_free_values(hosts); │ │ 339 if (runasusers != NULL) │ │ 340 handle->fn_free_values(runasusers); │ │ 341 if (runasgroups != NULL) │ │ 342 handle->fn_free_values(runasgroups); │ │ 343 if (opts != NULL) │ │ 344 handle->fn_free_values(opts); │ │ 345 if (notbefore != NULL) │ │ 346 handle->fn_free_values(notbefore); │ │ 347 if (notafter != NULL) │ │ 348 handle->fn_free_values(notafter); │ │ 349
Update: a reinstall+re-enroll of the client system (e.g. regformatting everything) did not fix the problem. Removing the host entry from the ipa server and re-enrolling fixed it. So it looks like bad data from the server gets the client very confused.
Are you still able to reproduce it? Can you share how the sudo rules are defined?
> Are you still able to reproduce it? No, I dropped the host in ipa and re-created it, and now the client does not crash. > Can you share how the sudo rules are defined? The sudo rules allow all without password for a group of users to a group of hosts, to which that host belonged (and I belong to the list of users). If you tell me how to export the rules to text form, I can do that.
To be clear: you kept the rule in the IPA server, you destroyed, re-created and re-enrolled the host (where sudo runs) and this fixed the issue? So you did not changed the sudo rule?
I destroyed, re-created, and re-enrolled the host, but this did NOT fix the problem. The newly installed host still crashed in `sudo -s` and similar. I then removed the host entry from the ipa server, and then re-re-enrolled the host. It then started working.
(after re-enrolling the host in the second iteration, which worked, I also had to re-add the host to the host group, of course).
Thank you, from what you are saying it looks like some property of the host caused it. This seems like a valid bug, however I will close it for insufficient information since you can no longer reproduce it and we have nothing to catch on. Please, if you do reproduce it reopen the issue and attach the sudo and sssd-sudo logs (see https://sssd.io/docs/users/troubleshooting/sudo_troubleshooting.html#obtaining-logs).
I did reproduce it - looks like I was mistaken and fiddling with the ipa server did not help.
Created attachment 1729597 [details] sudo logs
Hmm. Can you also provide sssd-sudo logs with full debug level? i.e. set debug_level = 0xfff0 to [sudo] in /etc/sssd/sssd.conf, restart sssd and reproduce the issue.
Created attachment 1730580 [details] sssd_sudo.log with debug level 0xfff0
Thank you, this was helpful.The problem is that the rule "allow sudo" does not have any commands set. So as a workaround, make sure that a command is associated with this rule or disable the rule. Nevertheless, this is a sudo bug which was already fixed in sudo upstream: https://www.sudo.ws/repos/sudo/rev/a3fe4615f039 I'm switching the component to sudo.
Thanks. The workaround worked around the bug.
The fix above is part of sudo versions 1.9.4 and later.
FEDORA-2021-a84b7821cd has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-d6630e0c7d has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-324479472c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-324479472c
FEDORA-2021-234d14bfcc has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-234d14bfcc
FEDORA-2021-234d14bfcc has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-234d14bfcc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-234d14bfcc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-324479472c has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-324479472c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-324479472c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-324479472c has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-234d14bfcc has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.