Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
Follow Us on Social
The TuxCare Team is responsible for performing in-depth analyses of new CVEs. This is done for every new CVE that pops up, which affects, directly or indirectly, the Linux ecosystem. We check to see if the distributions we provide services for are affected. When one such CVE does affect the supported distributions, the Team members roll up their sleeves and start digging into the code.
While performing this work on CVE-2021-33574, Nikita Popov, one of our Team members, identified a problem with the upstream glibc. It turns out that it is possible to cause a situation where a segmentation fault could be triggered in a specific code path within the library. This can, in turn, lead to the application using the library to crash, resulting in a Denial-of-Service issue.
Bear in mind that glibc provides the main system primitives and is linked with most, if not all, other Linux applications, including other language compilers and interpreters. It is the second most important component of a system after the Kernel itself.
This problem was introduced with the original upstream fix for CVE-2021-33574, specifically in the file mq_notify.c:
@@ -133,8 +133,11 @@ helper_thread (void *arg)
(void) __pthread_barrier_wait (¬ify_barrier);
else if (data.raw[NOTIFY_COOKIE_LEN – 1] == NOTIFY_REMOVED)
– /* The only state we keep is the copy of the thread attributes. */
– free (data.attr);
+ /* The only state we keep is the copy of the thread attributes. */
+ pthread_attr_destroy (data.attr);
+ free (data.attr);
While the free() call is immune to NULL pointers being passed to it, pthread_attr_destroy() is not. It was possible to identify two situations where the Linux Kernel would use the message NOTIFY_REMOVED while passing copied thread attributes along the way in the data.attr field. Unfortunately, a host application is able to pass a NULL value there if it wants glibc to spawn a thread with default attributes. In this case, glibc would dereference a NULL pointer in pthread_attr_destroy, leading to a crash of the entire process.
Following responsible disclosure guidelines, both the vulnerability and code fix were submitted to the team responsible for glibc, and a CVE was requested at Mitre (CVE-2021-38604). In glibc, it was assigned as bug 28213. This has already been incorporated into upstream glibc.
A new test was also submitted to glibc’s automated test suite to pick up this situation and prevent it from happening in the future. Sometimes, changes in unrelated code paths can lead to behaviours changing elsewhere in the code and the programmer not being aware of it. This test will catch this situation.
For context, the family of “mq_” functions provide POSIX compliant message queue API functionality and asynchronous notifications of incoming messages and are typically used for inter-process communications.
TALK TO A CYBERSECURITY EXPERT
Stay updated with the latest news and announcements from TuxCare.com
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...
In a symphony orchestra, instruments harmonize to create one pleasing...
We are pleased to announce that a new updated ePortal version...
We are pleased to announce that a new updated KernelCare agent...