Google Project Zero Discloses CentOS Linux Kernel Flaws
Google Project Zero discloses CentOS Linux kernel flaws after failing to release timely fixes before the 90-day deadline.
Google Project Zero is a security team that is in charge of identifying security vulnerabilities in not only Google’s products but also software created by other vendors. Once the issues are detected, they are privately reported to the vendors, who have 90 days to correct them before issues are made public.
Depending on how complicated the solution is, a 14-day grace period may also be provided in some instances.
CentOS Kernel Vulnerabilities Discovered
As explained in this technical document, Jann Horn, a security researcher at Google Project Zero, discovered that fixes made to stable trees of the kernel were not backported to numerous enterprise versions of Linux.
To verify it, Horn compared the CentOS stream 9 kernels to the stable linux-5.15.y tree. For those who don’t know, CentOS is a Linux distribution that is most closely related to Red Hat Enterprise Linux (RHEL), and its version is based on the linux-5.14 release.
As expected, it was discovered that various kernel changes had not been implemented in older, yet still supported versions of CentOS Stream/RHEL. Horn added that Project Zero had given a deadline of 90 days for the release of a fix in this instance. However, in the future, more stringent deadlines may be imposed for missing backports.
All three of Horn’s reported bugs were approved by Red Hat and assigned CVE numbers. Nevertheless, the company did not resolve these issues within 90 days, and thus, Google Product Zero is disclosing these vulnerabilities.
Vulnerabilities Details
A use-after-free vulnerability was detected in qdisc_graft located in net/sched/sch_api.c within the Linux Kernel, resulting from a race condition issue. This vulnerability results in a denial of service problem.
A use-after-free vulnerability was discovered in the Ext4 File System of the Linux kernel. This flaw enables a local user to cause a system crash or potentially escalate their privileges. It is possibly only triggered when an Ext4 filesystem is mounted.
The Linux kernel’s core dump subsystem contains a use-after-free vulnerability that can cause the system to crash. The severity of this flaw is considered to be low, as it is difficult for an attacker to execute it. This is because the attacker must race the vulnerable code twice in order to exploit the flaw.
CentOS aims to provide a stable, secure, and free alternative to commercial operating systems like Red Hat Enterprise Linux (RHEL). It has been widely used by organizations and individuals worldwide, including various businesses and government agencies.
Discoveries of vulnerabilities in the CentOS kernel are therefore a cause for concern. It remains to be seen if Red Hat will be under pressure to patch these security problems as quickly as possible now that the details of those vulnerabilities in Linux kernels are public.
CentOS Kernel Patching
The CentOS community must act urgently to address the vulnerabilities and avoid further exploitation. This involves releasing patches for the vulnerabilities at the earliest and adopting measures to enhance the speed and efficiency of the patching process in the future.
One of the best methods for kernel patching is TuxCare’s KernelCare Enterprise, which is also the recipient of a Gold award in the Security Automation category in the 2023 Cybersecurity Excellence Awards. KernelCare Enterprise automatically delivers the latest CVE patches on all popular Linux distributions without needing to reboot the kernel. So your team never needs to restart systems or wait for scheduled maintenance windows to apply a vulnerability patch.
To know how KernelCare deploys vulnerability patches, view the live patching process.
Conclusion
The identification of vulnerabilities in the CentOS Linux kernel acts as a wake-up call for the open-source community. It underscores the importance of a collaborative and concentrated approach to identifying and resolving vulnerabilities promptly and efficiently. Furthermore, it is vital for other open-source projects to draw lessons from this incident and establish robust procedures for addressing vulnerabilities and providing timely fixes.
The sources for this article include a story from Neowin.