Linux Kernel Memory Management (MM) Vulnerability (CVE-2024-26621) resolved (4th Mar 2024)

Preface: The Memory Management (MM) subsystem is an important cornerstone of the Linux kernel. It provides the necessary utilities for the underlying memory hardware (especially RAM) to meet the different needs of other kernel components and user-space processes.

Background: About two months ago, larger anonymous mappings are now THP aligned. When a malloc library allocates a 2MB or larger arena, that arena can now be mapped with THPs right from the start, which can result in better TLB hit rates and execution time.

Ref: Align larger anonymous memory mappings on THP boundaries by going through thp_get_unmapped_area if THPs are enabled for the current process.

Vulnerability details: mm: huge_memory: don’t force huge page alignment on 32 bit.

mm: huge_memory: don’t force huge page alignment on 32 bit

(“mm: align larger anonymous mappings on THP boundaries”) caused two issues reported on 32 bit system or compat userspace. The issues shown as below:



Official announcement: Please refer to the official announcement for details –

Closer look of CVE-2023-52485 (1st Mar 2024)

Preface: DRM and KMS

DRM stands for Direct Rendering Manager and was introduced to deal with graphic cards embedding GPUs

KMS stands for Kernel Mode Setting and is a sub-part of the DRM API

Background: The AMDgpu display manager, amdgpu_dm (or even simpler, dm) sits between DRM and DC. It acts as a liaison, converting DRM requests into DC requests, and DC responses into DRM responses.

Drm[/]amd[/]display – Display Core (DC): Because it is partially shared with other operating systems, the Display Core Driver is divided in two pieces.

-Display Core (DC) contains the OS-agnostic components. Things like hardware programming and resource management are handled here.

-Display Manager (DM) contains the OS-dependent components. Hooks to the amdgpu base driver and DRM are implemented here.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: drm[/]amd[/]display: Wake DMCUB before sending a command

[Why] We can hang in place trying to send commands when the DMCUB isn’t powered on.

[How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd[/]list with code that exits idle power optimizations and reallows once we’re done with the command submission on success. For DM direct submissions the DM will need to manage the enter[/]exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock.

Official announcement: Please refer to the official announcement for details –

CVE‑2024‑0074: NVIDIA GPU display driver vulnerability for Linux, An attacker can access memory locations after the end of the buffer. (27-02-2024)

Preface: The Linux framebuffer and a GPU’s memory serve different purposes in the context of graphics processing. The Linux framebuffer is a simple, low-level graphics interface that allows applications to draw graphics directly to the screen.

Background: The DRM/KMS framework is dedicated to the management of the display, graphic and composition subsystems. With the help of other Linux multimedia frameworks and applications, the DRM/KMS framework is typically used: to compose animated contents taking advantages of the hardware acceleration.

Remark: Kernel Mode Setting (KMS) is a method for setting display resolution and depth in the kernel space rather than user space.

Vulnerability details: NVIDIA GPU Display Driver for Linux contains a vulnerability where an attacker may access a memory location after the end of the buffer. A successful exploit of this vulnerability may lead to denial of service and data tampering.

Official announcement: Please refer to the official announcement for details –

CVE-2024-22251 – Even though the risk level is moderate, don’t take it lightly. Stay alert. (27-02-2024)

Preface: Kernel extensions – VMWare as well as Qemu also enable you to install a device driver in your host operating system that enables them to speed up execution of kernel code and device accesses by directly executing in kernel mode.

Background: VMware Fusion is a software hypervisor developed by VMware for macOS systems. It allows Macs with Intel or the Apple M series of chips to run virtual machines with guest operating systems, such as Microsoft Windows, Linux, or macOS, within the host macOS operating system.

Vulnerability details: VMware Workstation and Fusion contain an out-of-bounds read vulnerability in the USB CCID (chip card interface device). VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.9.

Known Attack Vectors: A malicious actor with local administrative privileges on a virtual machine may trigger an out-of-bounds read leading to information disclosure.

Official announcement: Please refer to the official announcement for details –

CVE-2023-52474: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests (26th Feb 2024)

Preface: Compared to pageable memory, pinned memory has only 1 memory transfer. Hence memory transfer time is less for pinned memory than pageable memory. In mapped memory, the address is mapped to the device address space. Hence there is no explicit memory transfer.

Background: InfiniBand is a network architecture that is designed for the large-scale interconnection of computing and I/O nodes through a high-speed switched fabric.

Vulnerability details: hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a

Here are the specific bugs:

1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet.

2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages.

Please refer to the official announcement for details –

CVE-2024-21502: If you are using Fastecdsa for digital signature algorithm, staying alert! (26th Feb 2024)

Preface: In the modern digital world. Digital signatures replace traditional handwritten signatures for identity verification. In the past, pattern matching methods were used to confirm signature integrity through human observation. The integrity of digital signatures is ensured through the Elliptic Curve Digital Signature Algorithm (ECDSA).

Background: Elliptic Curve Digital Signature Algorithm (ECDSA) is a cryptographic algorithm used by Bitcoin to ensure that funds can only be used by their legitimate owners. The private key is a secret number known only to the person who generated it.

Is bitcoinlib popular? The python package bitcoinlib receives a total of 7,081 weekly downloads. As such, bitcoinlib popularity was classified as a recognized.

Fastecdsa efficient faster than the ecdsa package. There are several examples, how to use fastecdsa package. It proven that fastecdsa capable work with bitcoinlib.

In security point of view, fastecdsa are secure.There is no nonce reuse, no branching on secret material, and all points are validated before any operations are performed on them. Timing side challenges are mitigated via Montgomery point multiplication. Nonces are generated per RFC6979. The default curve used throughout the package is P256 which provides 128 bits of security.

Vulnerability details: Versions of the package fastecdsa before 2.3.2 are vulnerable to Use of Uninitialized Variable on the stack, via the curvemath_mul function in src/curveMath.c, due to being used and interpreted as user-defined type. Depending on the variable’s actual value it could be arbitrary free(), arbitrary realloc(), null pointer dereference and other. Since the stack can be controlled by the attacker, the vulnerability could be used to corrupt allocator structure, leading to possible heap exploitation. The attacker could cause denial of service by exploiting this vulnerability.

Official announcement: Please refer to the link for details –

CVE-2024-22250 and CVE-2024-22245: VMware Enhanced Authentication Plug-in (EAP). The aftermath is not over yet. (23rd Feb 2024)

This announcement original published on 20th Feb 2024

Preface: When two components have problems in the same place. If vendor did not specify the details in clear. In this circumstances, the design weakness looks the same.

Background: The Enhanced Authentication Plugin (EAP) is an extra software package that doesn’t come pre-installed. Administrators need to install it on client computers used for administration to allow direct login when using the VMware vSphere Client through a web browser.

The VMware EAP is a deprecated browser plugin that enables seamless single sign-on (SSO) to vSphere’s management interface from client workstations. It is an optional feature that stopped receiving support with the release of VMware vCenter Server 7.0.0u2 in March 2021.

Vulnerability details:

Session Hijack Vulnerability in Deprecated EAP Browser Plugin (CVE-2024-22250) – The VMware Enhanced Authentication Plug-in (EAP) contains a Session Hijack vulnerability. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.8.

Arbitrary Authentication Relay Vulnerability in Deprecated EAP Browser Plugin (CVE-2024-22245) – The VMware Enhanced Authentication Plug-in (EAP) contains an Arbitrary Authentication Relay vulnerability. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.6.

Official announcement: Please refer to the link for details –

CVE-2023-49100: TF-A before 2.10 has a potential read out-of-bounds in the SDEI service (21-02-2024)

Preface: Trusted Firmware-A (TF-A) provides a reference implementation of secure world software for Armv7-A, Armv8-A and Armv9-A, including a Secure Monitor executing at Exception Level 3 (EL3) and a Secure Partition Manager running at Secure EL2 (S-EL2) of the Arm architecture.

Background: Software Delegated Exception Interface (SDEI) provides a mechanism for registering and servicing system events from system firmware. This specification defines a standard interface that is vendor-neutral, interoperable, and software portable. The interface is offered by a higher Exception level to a lower Exception level, in other words, by a Secure platform firmware to hypervisor or hypervisor to OS or both.

System events are high priority events, which must be serviced immediately by an OS or hypervisor. These events are often orthogonal to normal OS operation and the events can be handled, even when the OS is executing within its own critical section with interrupts masked. System events can be provided to support: Platform error handling (RAS), Software watchdog timer, Sample-based profiling & Kernel debugger.

Vulnerability details: Trusted Firmware-A (TF-A) before 2.10 has a potential read out-of-bounds in the SDEI service. The input parameter passed in register x1 is not validated well enough in the function sdei_interrupt_bind. The parameter is passed to a call to plat_ic_get_interrupt_type. It can be any arbitrary value passing checks in the function plat_ic_is_sgi. A compromised Normal World (Linux kernel) can enable a root-privileged attacker to issue arbitrary SMC calls. Using this primitive, he can control the content of registers x0 through x6, which are used to send parameters to TF-A. Out-of-bounds addresses can be read in the context of TF-A (EL3). Because the read value is never returned to non-secure memory or in registers, no leak is possible. An attacker can still crash TF-A, however.

Official announcement: Please refer to the link for details –

CVE-2023-52439 Fix use-after-free in uio_open (20th Feb 2024)

Preface: Do you think this design flaw is risky? Yes, I think so.

Background: The UIO is a general purpose kernel driver that can be accessed from user space. The purpose of the driver is to act as a thin layer between user space programs and the hardware.

Since Linux uses a virtual address system, you cannot directly access the physical addresses of devices. You can gain a virtual address pointer to the device by using mmap() on the UIO device file for the device.

Vulnerability details:

There are two cores (processors) on a single chip, a SMP Kernel and RAM.

In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1.

But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then:

After core-1 kfree idev, the core-2 will do use-after-free for idev.

When core-2 do uio_release and put_device, the idev will be double freed.

Remedy: To address this issue, we can get idev atomic & inc idev reference with minor_lock. For details, please refer to

Official announcement: Please refer to the link for details –

Ref: mutex_unlock() returns 0 after successful operation. If any of the following conditions are detected, mutex_unlock() will fail and return the corresponding value.

EFAULT Description: The address pointed to by mp is illegal.

EPERM Description: The calling thread does not own the mutex lock.

CVE-2024-1633: Do not contempt! (19th Feb 2024)

Preface: A two-stage bootloader actually consists of two bootloaders after each other. The first being small with the sole purpose of loading the second one. The second one can then contain all the code needed for loading the kernel.

Background: Secure boot is a security standard developed to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the device starts, the firmware checks the signature of each piece of boot software. If the signatures are valid, the device boots, and the firmware gives control to the operating system.

Vulnerability details: During the secure boot, bl2 (the second stage of the bootloader) loops over images defined in the table “bl2_mem_params_descs”. For each image, the bl2 reads the image length and destination from the image’s certificate. Because of the way of reading from the image, which base on 32-bit unsigned integer value, it can result to an integer overflow. An attacker can bypass memory range restriction and write data out of buffer bounds, which could result in bypass of secure boot.


An integer overflow occurs when you attempt to store inside an integer variable a value that is larger than the maximum value the variable can hold.

A 32-bit unsigned integer. It has a minimum value of 0 and a maximum value of 4,294,967,295 (inclusive).

Official details: Please refer to the link for details –