Stephen Smoogen writes:
I am guessing the problem is really with the free(lastUname) since the rfree
Yes. Multiple execution threads will reach lastUname and try to free the same pointer. glibc rightfully complains about the double-free.
isn't referred to (but not sure if an optimization would have removed it. The comment before this code mentions that this is a hack to try and get things done.. probably from long long ago when rpm was single threaded.
The problem is in all of these functions. It's the same problem with all of them. Here's rpmugUname(), for example. You have two execution threads traversing that nest of "if" statements and all of them winding up here:
} else {
char *uname = NULL;
if (lookup_str(pwfile(), uid, 2, 0, &uname))
return NULL;
lastUid = uid;
free(lastUname);
And now both execution threads will try to free() the same pointer.
The next statement resets lastUname to the newly-allocated uname, but it's
too late. If the code that executes in parallel calls rpmugUname, then just
say good night.
All of the static variables in all of the functions here must have a mutex wrapped around them.
Or declared with a __thread attribute.The window of vulnerability is very tiny. But I have 32 cores and have 32 execution threads churning. They have about a 5% chance of hitting the double-free on every build. Worse, I can see how this race condition may not result in a crash but produce a corrupted rpm.
Attachment:
pgpnnQua_PZg7.pgp
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
