The first problem wasn’t that bad. As Siddhesh Poyarekar, a Red Hat principal software engineer wrote, “In order to mount a minimal attack using this flaw, an attacker needs many pre-requisites to be able to even crash a program using this mq_notify bug.” Still, it needed patching and so it was fixed. Alas, the fix contained an even nastier bug. While checking the patch, Nikita Popov, a member of the CloudLinux TuxCare Team, found the problem. It turns out that it is possible to cause a situation where a segmentation fault could be triggered within the library. This can lead to any application using the library crashing. This, of course, would cause a Denial-of-Service (DoS) issue. This problem, unlike the earlier one, would be much easier to trigger. Whoops. Red Hat gives the problem in its Common Vulnerability Scoring System (CVSS) a score of 7.5, which is “high.” An attack using it would be easy to build and requires no privileges to be made. In short, it’s bad news. Popov himself thinks “every Linux application including interpreters of other languages (python, PHP) is linked with glibc. It’s the second important thing after the kernel itself, so the impact is quite high.” Popov found the problem while doing “his usual routine of porting CVE-2021-33574 fix to our supported distros.” He found that null pointers could be passed in certain situations. Technically, the problem lay in the ‘mq_’ function family. These provide POSIX compliant message queue application programming interface (API) functionality. Typically these are used for inter-process communications (IPC) processes. Every Linux application including interpreters of other languages (Python, PHP) is linked with glibc library. Popov found “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.” The C programmers among you are already closing their eyes and shaking their heads ruefully. One of the common rules of C programming is to never, ever dereference a null pointer. The question isn’t “Will it crash the program?” It’s “How badly will it crash the program?” The good news is both the vulnerability and code fix have been submitted to the glibc development team. It has already been incorporated into upstream glibc. In addition, a new test has been submitted to glibc’s automated test suite to pick up this situation and prevent it from happening in the future. The bottom line is sometimes changed in unrelated code paths can lead to behaviors changing elsewhere without the programmer realizing what’s going on. This test will catch this situation. The Linux distributors are still working out the best way to deploy the fix. In the meantime, if you want to be extra careful – and I think you should be – you should upgrade to the newest stable version of glibc 2.34 or higher. Related Stories:
It’s time to improve Linux’s securityQualys partners with Red Hat to improve Linux and Kubernetes securityPatch now: Linux file system security hole, dubbed Sequoia, can take over systems
