September 17th, 2024

Race conditions in Linux Kernel perf events

A vulnerability in the Linux Kernel's perf events subsystem, existing since version 4.1, allows race conditions but is ineffective on major distributions with certain configurations. No CVE assigned yet.

Read original articleLink Icon
Race conditions in Linux Kernel perf events

A recently disclosed vulnerability in the Linux Kernel's perf events subsystem has been identified, which appears to have existed since the introduction of auxiliary buffers in version 4.1, approximately nine years ago. The vulnerability allows for race conditions that can be exploited, although it has been confirmed that the exploit does not work on major distributions when certain configurations are enabled. The vulnerability affects the struct perf_buffer, which is used for performance measurement, and involves improper locking mechanisms that fail to prevent concurrent access to shared resources. The authors have provided a proof of concept demonstrating the exploit on kernel version 6.x, but it is believed to be applicable to older versions as well. The technical details of the vulnerability and its exploitability have been shared to raise awareness, although no CVE number has been assigned yet, as the kernel security team only issues these after a fix is available. The authors emphasize that while the vulnerability affects major distributions, they are not providing a detailed exploit blueprint to prevent misuse.

- A vulnerability in the Linux Kernel's perf events subsystem has been disclosed.

- The issue has existed since kernel version 4.1 and is related to race conditions in auxiliary buffers.

- The exploit is not effective on major distributions with specific configurations enabled.

- A proof of concept has been tested on kernel version 6.x but may apply to older versions.

- No CVE number has been assigned yet, pending a fix from the kernel security team.

Related

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.

CVE-2021-4440: A Linux CNA Case Study

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.

Linux VFS Fix for 5 Year Old Bug That Could Cause Corruption, Security or Crash

Linux VFS Fix for 5 Year Old Bug That Could Cause Corruption, Security or Crash

A significant fix for a five-year-old Linux VFS bug, discovered by Microsoft engineer Christian Brauner, addresses potential on-disk corruption and security vulnerabilities, enhancing kernel stability and security.

New SLUBStick Attack Makes Linux Kernel Vulnerabilities More Dangerous

New SLUBStick Attack Makes Linux Kernel Vulnerabilities More Dangerous

Researchers from Graz University of Technology developed SLUBStick, a technique that exploits Linux kernel heap vulnerabilities with over 99% success, enabling privilege escalation and container escapes against modern defenses.

Researchers discover potentially catastrophic exploit present in AMD chips

Researchers discover potentially catastrophic exploit present in AMD chips

Researchers have found a serious vulnerability in AMD processors, affecting chips since 2006, allowing deep firmware access. AMD is developing patches, with risks primarily for corporations and government entities.

Link Icon 3 comments
By @vlovich123 - 4 months
> We disclosed this vulnerability to the kernel security team through responsible disclosure. The patch on the mailing list is visible here.

The patch is dated today. Isn’t responsible disclosure to wait a bit until the security update can work its way into some actual distributions (or heck even a kernel release) and not publish a detailed 0-day for all Linux kernels?

Edit: reading the exploit description more fully:

> On most (or even all) distributions this strategy doesn’t work.

Only impacts vanilla builds using the default config.

By @jeffbee - 4 months
perf_event_open is already privileged.