Thoughts on Linux CNA’s Approach and the Resulting CVE Flood

Recently, the Linux Kernel Project attained the status of a CNA¹ (CVE Numbering Authority), granting it the capability to independently issue CVEs (Common Vulnerabilities and Exposures). While this development may seem unremarkable, the substantial increase in the number of newly assigned CVEs raises many questions. I’ve received numerous inquiries from people seeking clarification and expressing concern about the apparent surge in the issuance of CVE numbers for almost every non-trivial patch applied to the maintained stable kernel trees.

It appears that there is a diversity of interpretations regarding what qualifies as a CVE and what does not. In this blog post, I aim to articulate some personal reflections on this situation.

Understanding Vulnerabilities

Assigning a CVE doesn’t always mean a critical issue that every user must quickly address.

Let’s take a look at what cve.org says about what qualifies as a vulnerability. The CNA rules² are:

7.1.1 If a product owner considers an issue to be a vulnerability in its product, then the issue MUST be considered a vulnerability, regardless of whether other parties (e.g., other vendors whose products share the affected code) agree.

7.1.2 If the CNA determines that an issue violates the security policy of a product, then the issue SHOULD be considered a vulnerability.

7.1.3 If a CNA receives a report about a new vulnerability that has a negative impact, then the reported vulnerability MAY be considered a vulnerability.

The Linux Kernel CNA³ itself states:

As part of the normal stable release process, kernel changes that are potentially security issues are identified by the developers responsible for CVE number assignments and have CVE numbers automatically assigned to them. These assignments are published on the linux-cve-announce mailing list as announcements on a frequent basis.

Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

So, the Kernel CNA adheres to rule 7.1.3 of cve.org, indicating that any patch addressing a bug with potential negative impacts receives a CVE. This doesn’t necessarily imply that the bug is exploitable, but it could be exploited by someone with malicious intent as part of an exploit chain. Modern exploits often consist of a complex chain that utilizes numerous small bugs.

It’s important to note that the Kernel CNA lacks context on individual system usage or threat models. Therefore, the CNA cannot determine if you prioritize bugs that can be triggered remotely or care about those only the root user can activate. The ultimate decision on whether a CVE is relevant to your system lies with you or your Linux vendor.

Let’s Take a Closer Look

Many people express concern that almost every bug fix receives a CVE, suggesting that the Kernel CNA should limit CVE assignments to bug fixes addressing security issues. However, distinguishing between a regular bug fix and a security bug fix can be challenging, especially for a foundational component like the monolithic UNIX kernel. Let’s examine the last few CVEs in my linux-cve-announce mailbox.

CVE-2023-52589: media: rkisp1: Fix IRQ disable race issue

The rkisp1 media driver for RockChip SoCs suffers from a bug in interrupt handling which can lockup (deadlock) the kernel. If the attacker can control the driver or the media stream a DoS situation could occur.

CVE-2023-52591: reiserfs: Avoid touching renamed directory if parent does not change

The bug fix addresses a locking issue in the reiserfs filesystem. It does not correctly use the Linux VFS interface which could lead to a corrupted filesystem. A local attacker could trigger this and corrupt data on disk.

CVE-2023-52590: ocfs2: Avoid touching renamed directory if parent does not change

Fixes the same as CVE-2023-52591 but in the ocfs2 filesystem.

CVE-2024-26626: ipmr: fix kernel panic when forwarding mcast packets

This fix addresses a potential kernel panic caused by a NULL pointer dereference when forwarding multicast IP packets. The NULL pointer dereference could result in a simple denial-of-service (DoS) attack, but it could escalate to something more serious if it is a use-after-free issue. Despite multicast routing is typically disabled by default on Linux, this case still qualifies for a CVE due to its potential impact when enabled.

CVE-2024-26628: drm/amdkfd: Fix lock dependency warning

Linux’s lock checker identified an invalid lock state within a GPU driver, and the patch addresses this issue by restructuring certain code paths. While this problem is probably not exploitable on its own, it could potentially assist a local attacker in exploiting undefined behavior resulting from the invalid lock state. It’s important to note that for this to be a concern, the specific GPU driver in question must be in use on the target system.

CVE-2024-26627: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler

In this scenario, a bug within the SCSI library in the kernel is addressed. This bug has the potential to cause a kernel lockup, akin to a deadlock, especially when there is an abundance of SCSI requests in progress in a specific configuration. This situation could result in a Denial of Service (DoS) scenario if an attacker can control the amount of SCSI requests.

Arguably, except for CVE-2024-26626, none of the aforementioned CVEs appear particularly dangerous at first glance. However, it’s crucial to recognize that each bug fix behind these CVEs addresses an issue resulting in undefined behavior. For a skilled attacker, any of these bugs could serve as a useful building block.

Linux’s Approach

As I see it, the approach adopted by the Linux Kernel CNA is refreshingly honest. It may be surprising because other projects or vendors, especially proprietary ones, often take the opposite approach, attempting to avoid assigning a CVE unless it’s unequivocally clear that a bug is exploitable. The reluctance of some vendors to assign new CVEs has led to the emergence of projects like !CVE. This highlights a conceptual challenge with CVEs—they are a somewhat generic tool, and various interpretations exist regarding what qualifies as a CVE. For those accustomed to few CVEs being issued, each describing an independently exploitable bug, the Linux kernel CNA’s approach may be unexpected.

Dealing with the CVE Flood

CVEs serve as a widely-used metric to signal when a specific software component has received a security fix, prompting the need for an update in products or software built upon it. However, as a vendor, delivering updates can be challenging, and customers may not always be enthusiastic about installing them unless absolutely necessary. This reluctance often leads product maintainers to prefer CVEs for severe and demonstrably exploitable issues. Furthermore, security scanners tend to flag any CVE associated with a particular software version, but they lack awareness of your kernel configuration or loaded drivers, just like the kernel CNA. Ultimately, determining the relevance of a CVE rests with you. When in doubt, it’s prudent to consider yourself affected.

To effectively manage the influx of CVEs, consider the following:

• Always use a recent and supported kernel, such as a Long-Term Support (LTS) version.
• Establish a robust update strategy with rollback capabilities.
• Keep your customizations atop the kernel minimal and well maintained to minimize disruptions during upgrades.
• Whenever possible, contribute your changes upstream to keep your patch queue slim.
• Familiarize yourself with your kernel configuration, including enabled config options and used drivers. For instance, if you’re not using reiserfs, CVE-2023-52591 may not be applicable to your system…
• Understand your threat model; Can you trust local users or even the root user? This knowledge informs your risk assessment and response to potential vulnerabilities.

It should also be noted that the increased number of CVEs does not necessarily imply that Linux is less secure than before. The surge simply provides greater insight and transparency into issues that could potentially impact security. Previously, you would have had to monitor each bug fix manually.

Is My Kernel Affected by a CVE? - A Rough Metric

The Linux kernel is highly configurable at build time, there is a good chance that many CVEs affect code your kernel build doesn’t has enabled. By looking at the affected files list of a bug fix for a CVE you can check whether the patched files are actually part of your kernel build. If they are not, the bug fix is unlikely to affect you.

Let’s use CVE-2024-26628 as example. The Affected files section states drivers/gpu/drm/amd/amdkfd/kfd_svm.c, so if this file is part of your kernel build, you’re affected.

Recent kernels allow creating a compile_commands.json file like many other build systems do. By checking this JSON file it is possible to see whether a particular file will be build.

$ make compile_commands.json
$ jq '.[] | .file' compile_commands.json | grep drivers/gpu/drm/amd/amdkfd/kfd_svm.c

Ideally, you store compile_commands.json after every build somewhere, then you can quickly check without needing the kernel build directory.

In case your kernel is too old to have compile_commands.json, you can still check after a build by searching for the object file. Replace the .c suffix with .o and search in the build directory for it.

Please keep in mind that this all works only if you’re using a kernel version that is still supported.

Conclusion

The Linux CNA intentionally adopts an overly cautious approach and assigns a new CVE when in doubt. While this may surprise many, it is a perfectly legitimate and entirely honest strategy. In contrast, vendors of proprietary software often tend to take the opposite approach, minimizing the assignment of CVEs whenever possible. Effectively managing the substantial number of CVEs involves understanding your kernel configuration, having a clear threat model, and ensuring the ability to update the kernel as needed. I hope that other large projects will eventually adopt Linux’s approach.