While investigating the upstream fix of the recent CVE-2021-33574, i've found following problem:
Helper thread frees copied attribute on NOTIFY_REMOVED message received from the OS kernel. Unfortunately, it fails to check whether copied attribute actually exists (data.attr != NULL). This worked earlier because free() checks passed pointer before actually attempting to release corresponding memory. But __pthread_attr_destroy assumes pointer is not NULL. So passing NULL pointer to __pthread_attr_destroy will result in segmentation fault. This scenario is possible if notification->sigev_notify_attributes == NULL (which means default thread attributes should be used).
Affected file: sysdeps/unix/sysv/linux/mq_notify.c
Affected function: helper_thread
Affected lineno: 137
Created attachment 13606 [details]
Pushed to master and 2.34.
Test case for the fix.
commit 4cc79c217744743077bf7a0ec5e0a4318f1e6641 (HEAD -> master, origin/master, origin/HEAD)
Author: Nikita Popov <firstname.lastname@example.org>
Date: Thu Aug 12 16:09:50 2021 +0530
librt: add test (bug 28213)
This test implements following logic:
1) Create POSIX message queue.
Register a notification with mq_notify (using NULL attributes).
Then immediately unregister the notification with mq_notify.
Helper thread in a vulnerable version of glibc
should cause NULL pointer dereference after these steps.
2) Once again, register the same notification.
Try to send a dummy message.
Test is considered successfulif the dummy message
is successfully received by the callback function.
Signed-off-by: Nikita Popov <email@example.com>
Reviewed-by: Siddhesh Poyarekar <firstname.lastname@example.org>