June 29th, 2024

CVE-2021-4440: A Linux CNA Case Study

The Linux CNA mishandled CVE-2021-4440 in the 5.10 LTS kernel, causing information leakage and KASLR defeats. The issue affected Debian Bullseye and SUSE's 5.3.18 kernel, resolved in version 5.10.218.

Read original articleLink Icon
CVE-2021-4440: A Linux CNA Case Study

This case study delves into the impact of the Linux CNA on Linux kernel vulnerability management, focusing on a mishandled vulnerability (CVE-2021-4440) in the upstream 5.10 LTS kernel. The vulnerability stemmed from a flawed backport of patches aimed at enhancing the kernel's defense against MDS attacks, resulting in information leakage and KASLR defeats. Affected kernels included Debian Bullseye and SUSE's 5.3.18 kernel in SLE15 SP2/SP3. The issue was swiftly reported and fixed in the 5.10 LTS kernel version 5.10.218. The fix involved dropping the USERGS_SYSRET64 paravirt call and adding the VERW instruction before userspace transition. However, the CVE announcement for this vulnerability exhibited several inaccuracies, including an incorrect CVE year and a misleading description. These discrepancies highlight challenges in CVE generation and information accuracy within the Linux CNA.

Related

A buffer overflow in the XNU kernel

A buffer overflow in the XNU kernel

CVE-2024-27815 is a buffer overflow bug in XNU kernel affecting macOS, iOS, and visionOS. Apple swiftly released xnu-10063.121.3 to fix the issue, impacting kernels with CONFIG_MBUF_MCACHE. The bug allows attackers to trigger a crash by copying data beyond allocated space.

Memory sealing for the GNU C Library

Memory sealing for the GNU C Library

The GNU C Library introduces mseal() system call for enhanced security by preventing address space changes. Adhemerval Zanella's patch series adds support, improving memory manipulation protection in upcoming releases.

Vulnerability in Popular PC and Server Firmware

Vulnerability in Popular PC and Server Firmware

Eclypsium found a critical vulnerability (CVE-2024-0762) in Intel Core processors' Phoenix SecureCore UEFI firmware, potentially enabling privilege escalation and persistent attacks. Lenovo issued BIOS updates, emphasizing the significance of supply chain security.

The Dirty Pipe Vulnerability

The Dirty Pipe Vulnerability

The Dirty Pipe Vulnerability (CVE-2022-0847) in Linux kernel versions since 5.8 allowed unauthorized data overwriting in read-only files, fixed in versions 5.16.11, 5.15.25, and 5.10.102. Discovered through CRC errors in log files, it revealed systematic corruption linked to ZIP file headers due to a kernel bug in Linux 5.10. The bug's origin was pinpointed by replicating data transfer issues between processes using C programs, exposing the faulty commit. Changes in the pipe buffer code impacted data transfer efficiency, emphasizing the intricate nature of kernel development and software component interactions.

OpenSSL CVE-2024-5535: `SSL_select_next_proto` buffer overread

OpenSSL CVE-2024-5535: `SSL_select_next_proto` buffer overread

A bug, CVE-2024-5535, in OpenSSL since 2011 allows heap data leakage. Impacts Python <= 3.9, Node.js <= 9. NPN support removal in newer versions reduces risk. Bug affects SSL_select_next_proto in OpenSSL, BoringSSL, LibreSSL. Memory safety risks demand caution and updates.

Link Icon 7 comments
By @nikic - 4 months
Huh, this is interesting. Normally the reason to become a CNA is to reduce the amount of bogus CVEs that are issued for your project due to security researchers trying to pad their portfolio.

Linux seems to have taken the reverse approach, by just filing their own bogus CVEs instead. One for every bug fix going into the kernel, rendering the CVE system useless.

By @kchr - 4 months
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions,

Is this related to the fact that the NIST NVD have had a huge backlog of unprocessed CVE:s since February?

https://www.nist.gov/itl/nvd

By @kchr - 4 months
Related LWN article from one of the kernel team members (Lee Jones):

How kernel CVE numbers are assigned: https://lwn.net/Articles/978711/ (June 19, 2024)

By @creatonez - 4 months
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions, vulnerability management companies, and end-users who noticed recently their previously-informative distribution security advisories got replaced with auto-generated lists of hundreds of CVEs with minimal user-understandable/actionable information.

Good! We have environmental CVSS scores now, use them.

By @hvenev - 4 months
(2024).

Assigning a CVE to every second commit and refusing to assign CVEs to unfixed issues doesn't seem like correct usage of the CVE system. I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.

To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel. Given how dependent on context the impact of some kernel bugs can be, if we were assigning CVSS scores for the worst case, practically all kernel bugs would be at least a 9.8/10.

By @progbits - 4 months
> This oversight meant that in affected kernels with the bad backport [...] not only was the MDS mitigation against the newer attacks turned into a no-op [...]

And this is why we write unit tests folks.