In the Linux kernel, design weakness (CVE-2024-41012) has been resolved.

Preface: The GFP acronym stands for “get free pages”, the underlying memory allocation function. Diversity of the allocation APIs combined with the numerous GFP flags makes the question “How should I allocate memory?” not that easy to answer, although very likely you should use. kzalloc(<size>, GFP_KERNEL);

Background: You can build a 64-bit POSIX-compliant tick-less kernel with a Linux-compatible syscall implementation using Go.

Vulnerability details: When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).

After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can’t corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts.

Official announcement: Please refer to the official announcement for details – https://nvd.nist.gov/vuln/detail/CVE-2024-41012

Preface: I believed that similar type of design weakness known last year by Arm (Feb 2023). May be it fixed it already.

Background: Linux kernel on Intel systems is susceptible to Spectre v2 attacks. CVE-2022-0001 explained Non-transparent sharing of branch predictor selectors between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. On 9th April, 2024 Dr. Elke Drennan published an article focus an attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by speculatively jumping to a chosen gadget. When you read the details, you will find that AMD and ARM are not affected. Why?

Vulnerability details: An attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by speculatively jumping to a chosen gadget.

Solution: Please update your software according to the recommendations from respective vendors with the latest mitigations available to address this vulnerability and its variants.

Official announcement: Please refer to the link for details- https://www.kb.cert.org/vuls/id/155143

Technical report shared by ETH Zurich on 4^th April 2024: Please refer to the link for details – https://arxiv.org/html/2404.03387v1

Background: Intel CPU’s inbuilt TDX Module provides an interface for the hypervisor to manage VMs indirectly and offers new instructions, VMLAUNCH-VMX and VMRESUME, for starting and resuming a VM. Instead of keeping track of the owner for each memory page on a system wide basis, TDX relies on keeping one shared extended page table for the hypervisor and multiple private extended page tables for each virtual machine (called TD by Intel).

Reference: int means interrupt, and the number 0x80 is the interrupt number. An interrupt transfers the program flow to whomever is handling that interrupt, which is interrupt 0x80 in this case. In Linux, 0x80 interrupt handler is the kernel, and is used to make system calls to the kernel by other programs.

The kernel is notified about which system call the program wants to make, by examining the value in the register %eax (AT&T syntax, and EAX in Intel syntax). Each system call have different requirements about the use of the other registers. For example, a value of 1 in %eax means a system call of exit(), and the value in %ebx holds the value of the status code for exit().

Vulnerability details: The test implement a kernel module in 150 LoC to inject interrupts into the TDX VM. Our host module uses kernel hooks to call a function in KVM that is used to deliver int 0x80 interrupts to TDX VMs. Unlike SEV-SNP, TDX does not expose the Virtual Machine Control Structure (VMCS) or the virtual APIC pages to the untrusted hypervisor. Instead, it expects the hypervisor to write into a Posted Interrupt Request (PIR) buffer. This buffer is used by hardware to inject interrupts into TDX VMs through the virtual APIC [34]. We inject two interrupts into two different cores of the CVM with this mechanism, one to gain login into the TDX VM with OpenSSH and another to get root access with sudo. During these two injects, the guest kernel does not acknowledge the interrupts. While this does not stop our attacks, it does leave the APIC with an elevated Task-Priority-Register (TPR), blocking all lower-priority interrupts on the affected vCPU. This may break CVM functionality that is noticeable by the user. To evade such detection, we implement a guest kernel module (kern_ack) that resets the APIC state. We inject this kernel module into the TDX VM as the last part of our attack after gaining root access.

Preface: AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) is a feature of AMD EPYC processors that adds strong memory integrity protection to help prevent malicious hypervisor-based attacks in order to create an isolated execution environment.

Background: Fundamentally, int means interrupt, and the number 0x80is the interrupt number. An interrupt transfers the program flow to whomever is handling that interrupt, which is interrupt 0x80 in this case. In Linux, 0x80 interrupt handler is the kernel, and is used to make system calls to the kernel by other programs.

In current Linux, 32-bit syscalls (including int 0x80 from 64-bit) eventually end up indo_syscall_32_irqs_on(struct pt_regs *regs). It dispatches to a function pointer ia32_sys_call_table, with 6 zero-extended args. This maybe avoids needing a wrapper around the 64-bit native syscall function in more cases to preserve that behaviour, so more of the ia32 table entries can be the native system call implementation directly.

Vulnerability details: Researchers from ETH Zurich have shared with AMD a paper titled “Heckler: Disrupting AMD SEV-SNP with Interrupts.”

In their paper, the researchers report that a malicious hypervisor can potentially break confidentiality and integrity of Linux® SEV-SNP guests by injecting interrupts. 

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3008.html