${lead}
${lead}
Approximately 55 kernel CVEs published every week create challenges for the prominent players in the Linux sector – necessitating increased collaboration and innovative tools.
(Source: Created with AI in Bing Image Creator by heise online / dmk)
For several months now, a wide range of administrators and developers have been voicing their frustrations: while they previously dealt with about four to six security vulnerabilities within the Linux kernel each week, this number has skyrocketed to over tenfold since February. Prominent kernel developers have been actively asserting that this new reality should be seen positively during various lectures and discussions regarding the influx of CVE markings. They imply that distributors expressing discontent are demonstrating that they may have underestimated the seriousness of security issues in the past, leading them to overlook critical corrections that were not officially categorized as security fixes.
Some larger companies seem to have acknowledged this shift and are exploring multiple initiatives to alleviate the burden of this new situation for themselves and their clients. Eventually, this should also aid hobbyist administrators. However, the breadth of work required across multiple sectors means that improvements may take some time to materialize, as a deeper examination indicates.
The changes in the landscape are primarily driven by the developers of the Linux kernel. Historically, they paid little attention to designations like CVE (Common Vulnerabilities and Exposures); they have often obscured CVE IDs or even omitted them from patch descriptions to downplay the security implications of their updates. However, as external entities were increasingly awarded CVEs for dubious kernel vulnerabilities, the developers were compelled to take on the role of the CNA (CVE Numbering Authority) at the start of the year, giving them control over the issuance of CVEs for Linux, similar to the practices of other open-source projects.
Since February, the Linux developers have assigned approximately 3,375 CVE identifiers covering various vulnerabilities that had been fixed in prior years, aligned with foundation requirements at the time. Following pushback, around one hundred of these CVEs have been retracted by the responsible parties. Nevertheless, many external stakeholders, along with various developers of the official kernel, argue that numerous remaining CVEs are unwarranted as no genuine vulnerabilities have actually been addressed.
Greg Kroah-Hartman, a pivotal figure in the Linux community and the second most significant kernel developer, consistently addresses these criticisms in the same manner: the CVE allocation guidelines necessitate that he and other responsible individuals assign a CVE label to every potential vulnerability that they resolve. He further emphasizes that the diversity of Linux use cases complicates the evaluation of whether a seemingly innocuous fix has security implications in specific contexts.
For those who wish to delve deeper, we suggest watching the presentation and video from a recent talk by Kroah-Hartman, where he elaborates on these points and shares additional insights. He mentions that the kernel is not the leader in the field, addressing approximately 55 CVEs weekly, while platforms like WordPress generate over 110 in the same timeframe. He also outlines the process, explaining that ‘allocation occurs only a few days or weeks after corrections have been included in new kernel versions available to users.
CVE assignments are made only when three developers currently participating in the public review process agree. The original developers of the changes or the maintainers of the specific kernel code are not part of this process—often, they lack security expertise, and maintainers are frequently at their limits, as Kroah-Hartman has noted in other discussions. He continues to recommend that users utilize the most recent version of the latest stable or long-term kernel series to sidestep known vulnerabilities.
In a slide from his presentation, Kroah-Hartman cites Kees Cook, whose longstanding dedication has significantly bolstered the security of the Linux kernel over the last decade. Cook asserts that users seeking the most secure kernel face two main options: they can either adopt the latest version of a current series or meticulously investigate each CVE entry and implement the fixes relevant to their specific kernel application. Both choices entail considerable effort and potential inconvenience, particularly in scenarios where reboots are challenging or unfeasible; Cook believes it is up to individuals to determine which method suits their environment best.
Comments from Cook emerged during an open discussion regarding the recent kernel CVE situation at the Linux Plumbers Conference. This panel featured kernel developers from a variety of both large and small companies that utilize Linux for their internal operations or in their products. The discussion roamed widely across various topics, leaving numerous questions unanswered. However, a few concrete insights can be drawn.
Developers from different companies showed significant intent to establish a limited set of threat models. This approach allows interested parties to explore the CVEs collaboratively based on open source principles, assessing each one’s relevance to their specific threat model.
One potential threat model could focus on “cloud providers,” characterized by modern ARM64 and x86-64 server hardware with fully trusted users, amidst virtual machines running untrusted software. Collaborative efforts between companies like Amazon/AWS, Google, IBM, and Microsoft could lead to identifying pertinent CVEs for this model, rather than each company evaluating these issues independently. The findings from these analyses might be integrated back into the JSON files that compile all relevant CVE information.
Other mentioned threat models included automotive and enterprise Linux. The latter would likely benefit Linux distributions that have a clear focus on hardware compatibility and application areas, particularly those used or offered by companies such as Amazon/AWS, Google, Meta, Microsoft, Oracle, Red Hat, or Suse. Even for these organizations, cataloging the CVEs would require significant effort. Including kernels that come with a broader set of functions and drivers, like the Debian kernel, could further escalate the workload, possibly dissuading volunteers or financial investment for the necessary tasks.
One topic that surfaced briefly in the discussion was the absence of open source tools capable of verifying whether the code affected by a CVE exists in the deployed kernel—whether directly or in a module that could be easily removed or blocked at the local level. Companies like Google, Oracle, and SuSE have been reportedly utilizing such tools internally for some time, as the community has become aware. It seems likely that it’s just a matter of time before an open source tool is released to gather efforts moving forward.
The idea of live patching was also mentioned, but there are still several unanswered questions surrounding it. It may be theoretically possible to apply a significant portion of CVE fixes in real-time, yet the practical implementation remains challenging: the process of creating and validating such intricate live patches is both labor-intensive and time-consuming. In the end, while it might allow for avoidance of reboots for several weeks, extending that duration to months would likely be unfeasible.
One panel discussion participant highlighted that the numerous CVEs pose a considerable challenge in environments where updates are hard to implement and costly due to certification regulations, such as in hospitals using Linux systems. Kroah-Hartman indicated that legislators in the US and EU are aware of this issue and are currently exploring solutions, although this process may take some time.
A recording of the discussion is available in the conference’s live stream; however, it should be noted that a few minutes of audio were missing shortly after the event commenced.
(anw)
Stay updated with the latest news by following us on
LinkedIn, or
This article was first published in
It underwent technical translation and editorial review before being published.
ChicagoVPS is your gateway to unparalleled hosting solutions. Our state-of-the-art datacenters and powerful network ensures lightning-fast speeds and uninterrupted connectivity for your websites and applications. Whether you’re a startup looking for scalable resources or an enterprise in need of enterprise-grade hosting, our range of plans and customizable solutions guarantee a perfect fit. Trust in ChicagoVPS to deliver excellence, combining unmatched reliability and top-tier support.
For Inquiries or to receive a personalized quote, please reach out to us through our contact form here or email us at sales@chicagovps.net.
