Mali GPU Kernel LPE

This article provides an in-depth analysis of two kernel vulnerabilities within the Mali GPU, reachable from the default application sandbox, which I independently identified and reported to Google. It includes a kernel exploit that achieves arbitrary kernel r/w capabilities. Consequently, it disables SELinux and elevates privileges to root on Google Pixel 7 and 8 Pro models running the following Android 14 versions:

• Pixel 8 Pro: google/husky/husky:14/UD1A.231105.004/11010374:user/release-keys
• Pixel 7 Pro: google/cheetah/cheetah:14/UP1A.231105.003/11010452:user/release-keys
• Pixel 7 Pro: google/cheetah/cheetah:14/UP1A.231005.007/10754064:user/release-keys
• Pixel 7: google/panther/panther:14/UP1A.231105.003/11010452:user/release-keys (by m4b4 (Marcel))

Vulnerabilities

This exploit leverages two vulnerabilities: an integer overflow resulting from an incomplete patch in the gpu_pixel_handle_buffer_liveness_update_ioctl ioctl command, and an information leak within the timeline stream message buffers.

Buffer Underflow in gpu_pixel_handle_buffer_liveness_update_ioctl() Due to Incorrect Integer Overflow Fix

Google addressed an integer overflow in the gpu_pixel_handle_buffer_liveness_update_ioctl ioctl command in this commit. At first, when I reported this issue, I thought the bug was caused by an issue in the patch described earlier. After reviewing the report, I came to the realization that my analysis of the a vulnerability was inaccurate. Despite my first assumption of the patch being incomplete, it effectively resolves and prevents an underflow in the calculation. This lead me to suspect that the change wasn't applied in the production builds. However, although I can cause an underflow in the calculation, it is not possible to cause an overflow. This suggests that the ioctl command has been partially fixed, although not with the above patch shown above. Looking at IDA revealed that another incomplete patch was shipped in the production releases, and this patch is not present in any git branch of the mali gpu kernel module.

This vulnerability was first discovered in the latest Android version and reported on November 19, 2023. Google later informed me that they had already internally identified it and had assigned it CVE-2023-48409 in the December Android Security Bulletin, labeling it as a duplicate issue. Although I was able to verify that the bug had been internally identified months prior to my report, (based on the commit date around August 30) there remains confusion. Specifically, it's strange that the Security Patch Levels (SPL) for October and November of the most recent devices were still affected by this vulnerability —I haven't investigated versions prior to these. Therefore, I am unable to conclusively determine whether this was truly a duplicate issue and if the appropriate patch was indeed scheduled for December prior to my submission or if there was an oversight in addressing this vulnerability.

Anyway, what makes this bug powerful is the following:

• The buffer info.live_ranges is fully user-controlled.
• The overflowing values are user-controlled input, thereby, we can overflow the calculation so the info.live_ranges pointer can be at an arbitrary offset prior to the start of the buff kernel address.
• The allocation size is also user controlled input, which gives the ability to request a memory allocation from any general-purpose slab allocator.

This vulnerability shares similarities with the DeCxt::RasterizeScaleBiasData() Buffer underflow vulnerability I found and exploited in the iOS 15 kernel back in 2022.

Leakage of Kernel Pointers in Timeline Stream Message Buffers

The GPU Mali implements a custom timeline stream designed to gather information, serialize it, and subsequently write it to a ring buffer following a specific format. Users can invoke the ioctl command kbase_api_tlstream_acquire to obtain a file descriptor, enabling them to read from this ring buffer. The format of the messages is as follows:

• A packet header
• A message id
• A serialized message buffer, where the specific content is contingent upon the message ID. For example, the __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait function serializes the kbase_kcpu_command_queue and dma_fence kernel pointers into the message buffer, resulting in leaking kernel pointers to user space process.

void __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait(
	struct kbase_tlstream *stream,
	const void *kcpu_queue,
	const void *fence
)
{
	const u32 msg_id = KBASE_TL_KBASE_KCPUQUEUE_ENQUEUE_FENCE_WAIT;
	const size_t msg_size = sizeof(msg_id) + sizeof(u64)
		+ sizeof(kcpu_queue)
		+ sizeof(fence)
		;
	char *buffer;
	unsigned long acq_flags;
	size_t pos = 0;

	buffer = kbase_tlstream_msgbuf_acquire(stream, msg_size, &acq_flags);

	pos = kbasep_serialize_bytes(buffer, pos, &msg_id, sizeof(msg_id));
	pos = kbasep_serialize_timestamp(buffer, pos);
	pos = kbasep_serialize_bytes(buffer,
		pos, &kcpu_queue, sizeof(kcpu_queue));
	pos = kbasep_serialize_bytes(buffer,
		pos, &fence, sizeof(fence));

	kbase_tlstream_msgbuf_release(stream, acq_flags);
}

The proof of concept exploit leaks the kbase_kcpu_command_queue object address by monitoring to the message id KBASE_TL_KBASE_NEW_KCPUQUEUE which is dispatched by the kbasep_kcpu_queue_new function whenever a new kcpu queue object is allocated.

Google informed me that the vulnerability was reported in March 2023 and was assigned CVE-2023-26083 in their security bulletin. Nonetheless, I was able to replicate the issue on the latest Pixel devices shipped with the Security Patch Levels (SPL) for October and November, indicating that the fix had not been applied correctly or at all. Subsequently, Google quickly addressed the issue in the December Security Update Bulletin without offering credit, and later informed me that the issue was considered a duplicate. The rationale behind labeling this issue as a duplicate, however, remains questionable.

Exploitation

---

So I have two interesting vulnerabilities. The first one offers a powerful capability to modify the content of any 16-byte aligned kernel address that comes before the allocated buff address. The second vulnerability provides hints into the potential locations of objects within the kernel memory.