{"id":88178,"date":"2025-05-23T03:00:00","date_gmt":"2025-05-23T10:00:00","guid":{"rendered":"https:\/\/github.blog\/?p=88178"},"modified":"2025-05-22T16:39:22","modified_gmt":"2025-05-22T23:39:22","slug":"bypassing-mte-with-cve-2025-0072","status":"publish","type":"post","link":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/","title":{"rendered":"Bypassing MTE with CVE-2025-0072"},"content":{"rendered":"\n

Memory Tagging Extension (MTE)<\/a> is an advanced memory safety feature that is intended to make memory corruption vulnerabilities almost impossible to exploit. But no mitigation is ever completely airtight—especially in kernel code that manipulates memory at a low level.<\/p>\n\n\n\n

Last year, I wrote<\/a> about CVE-2023-6241, a vulnerability in ARM’s Mali GPU driver, which enabled an untrusted Android app to bypass MTE and gain arbitrary kernel code execution. In this post, I’ll walk through CVE-2025-0072: a newly patched vulnerability that I also found in ARM’s Mali GPU driver. Like the previous one, it enables a malicious Android app to bypass MTE and gain arbitrary kernel code execution.<\/p>\n\n\n\n

I reported the issue to Arm on December 12, 2024. It was fixed in Mali driver version r54p0<\/a>, released publicly on May 2, 2025, and included in Android’s May 2025 security update<\/a>. The vulnerability affects devices with newer Arm Mali GPUs that use the Command Stream Frontend (CSF<\/a>) architecture, such as Google’s Pixel 7, 8, and 9 series. I developed and tested the exploit on a Pixel 8 with kernel MTE enabled,<\/a> and I believe it should work on the 7 and 9 as well with minor modifications.<\/p>\n\n\n\n

What follows is a deep dive into how CSF queues work, the steps I used to exploit this bug, and how it ultimately bypasses MTE protections to achieve kernel code execution.<\/p>\n\n\n\n

How CSF queues work—and how they become dangerous<\/h2>\n\n\n\n

Arm Mali GPUs with the CSF feature communicate with userland applications through command queues, implemented in the driver as kbase_queue<\/code> objects. The queues are created by using the KBASE_IOCTL_CS_QUEUE_REGISTER<\/code><\/a> ioctl<\/code>. To use the kbase_queue<\/code> that is created, it first has to be bound to a kbase_queue_group<\/code>, which is created with the KBASE_IOCTL_CS_QUEUE_GROUP_CREATE<\/a> ioctl<\/code>. A kbase_queue<\/code> can be bound to a kbase_queue_group<\/code> with the KBASE_IOCTL_CS_QUEUE_BIND<\/a> ioctl<\/code>. When binding a kbase_queue<\/code> to a kbase_queue_group<\/code>, a handle is created from get_user_pages_mmap_handle<\/code><\/a> and returned to the user application.<\/p>\n\n\n

\n
int kbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind)\n{\n            ...\n\tgroup = find_queue_group(kctx, bind->in.group_handle);\n\tqueue = find_queue(kctx, bind->in.buffer_gpu_addr);\n            …\n\tret = get_user_pages_mmap_handle(kctx, queue);\n\tif (ret)\n\t\tgoto out;\n\tbind->out.mmap_handle = queue->handle;\n\tgroup->bound_queues[bind->in.csi_index] = queue;\n\tqueue->group = group;\n\tqueue->group_priority = group->priority;\n\tqueue->csi_index = (s8)bind->in.csi_index;\n\tqueue->bind_state = KBASE_CSF_QUEUE_BIND_IN_PROGRESS;\n\nout:\n\trt_mutex_unlock(&kctx->csf.lock);\n\n\treturn ret;\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
In addition, mutual references are stored between the kbase_queue_group<\/code> and the queue<\/code>. Note that when the call finishes, queue->bind_state<\/code> is set to KBASE_CSF_QUEUE_BIND_IN_PROGRESS<\/code>, indicating that the binding is not completed. To complete the binding, the user application must call mmap<\/code> with the handle returned from the ioctl<\/code> as the file offset. This mmap<\/code> call is handled by kbase_csf_cpu_mmap_user_io_pages<\/code><\/a>, which allocates GPU memory via kbase_csf_alloc_command_stream_user_pages<\/code><\/a> and maps it to user space.<\/p>\n\n\n
\n
int kbase_csf_alloc_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue)\n{\n\tstruct kbase_device *kbdev = kctx->kbdev;\n\tint ret;\n\n\tlockdep_assert_held(&kctx->csf.lock);\n\n\tret = kbase_mem_pool_alloc_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO],\n\t\t\t\t\t KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, false,                 \/\/<------ 1.\n\t\t\t\t\t kctx->task);\n  ...\n\tret = kernel_map_user_io_pages(kctx, queue);\n  ...\n\tget_queue(queue);\n\tqueue->bind_state = KBASE_CSF_QUEUE_BOUND;\n\tmutex_unlock(&kbdev->csf.reg_lock);\n\n\treturn 0;\n  ...\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
In 1. in the above snippet, kbase_mem_pool_alloc_pages<\/code> is called to allocate memory pages from the GPU memory pool, whose addresses are then stored in the queue->phys<\/code> field. These pages are then mapped to user space and the bind_state<\/code> of the queue is set to KBASE_CSF_QUEUE_BOUND<\/code>. These pages are only freed when the mmapped area is unmapped from the user space. In that case, kbase_csf_free_command_stream_user_pages<\/code><\/a> is called to free the pages via kbase_mem_pool_free_pages<\/code>.<\/p>\n\n\n
\n
void kbase_csf_free_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue)\n{\n\tkernel_unmap_user_io_pages(kctx, queue);\n\n\tkbase_mem_pool_free_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO],\n\t\t\t\t  KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, true, false);\n  ...\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
This frees the pages stored in queue->phys<\/code>, and because this only happens when the pages are unmapped from user space, it prevents the pages from being accessed after they are freed.<\/p>\n\n\n\n
An exploit idea<\/h2>\n\n\n\n
The interesting part begins when we ask: what happens if we can modify queue->phys<\/code> after mapping them into user space. For example, if I can trigger kbase_csf_alloc_command_user_pages<\/code> again to overwrite new pages to queue->phys<\/code>, and map them to user space and then unmap the previously mapped region, kbase_csf_free_command_stream_user_pages<\/code> will be called to free the pages in queue->phys<\/code>. However, because queue->phys<\/code> is now overwritten by the newly allocated pages, I ended up in a situation where I free the new pages while unmapping an old region:<\/p>\n\n\n\n
\"A<\/figure>\n\n\n\n
In the above figure, the right columns are mappings in the user space, green rectangles are mapped, while gray ones are unmapped. The left column are backing pages stored in queue->phys<\/code>. The new queue->phys<\/code> are pages that are currently stored in queue->phys<\/code>, while old queue->phys<\/code> are pages that are stored previously but are replaced by the new ones. Green indicates that the pages are alive, while red indicates that they are freed. After overwriting queue->phys<\/code> and unmapping the old region, the new queue->phys<\/code> are freed instead, while still mapped to the new user region. This means that user space will have access to the freed new queue->phys<\/code> pages. This then gives me a page use-after-free vulnerability.<\/p>\n\n\n\n
The vulnerability<\/h2>\n\n\n\n
So let’s take a look at how to achieve this situation. The first obvious thing to try is to see if I can bind a kbase_queue<\/code> multiple times using the KBASE_IOCTL_CS_QUEUE_BIND ioctl<\/code>. This, however, is not possible because the queue->group<\/code> field is checked before binding:<\/p>\n\n\n
\n
int kbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind)\n{\n  ...\n\tif (queue->group || group->bound_queues[bind->in.csi_index])\n\t\tgoto out;\n  ...\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
After a kbase_queue<\/code> is bound, its queue->group<\/code> is set to the kbase_queue_group<\/code> that it binds to, which prevents the kbase_queue<\/code> from binding again. Moreover, once a kbase_queue<\/code> is bound, it cannot be unbound via any ioctl<\/code>. It can be terminated with KBASE_IOCTL_CS_QUEUE_TERMINATE<\/code>, but that will also delete the kbase_queue<\/code>. So if rebinding from the queue is not possible, what about trying to unbind from a kbase_queue_group<\/code>? For example, what happens if a kbase_queue_group<\/code> gets terminated with the KBASE_IOCTL_CS_QUEUE_GROUP_TERMINATE<\/a> ioctl<\/code>? When a kbase_queue_group<\/code> terminates, as part of the clean up process, it calls kbase_csf_term_descheduled_queue_group<\/code><\/a> to unbind queues that it bound to:<\/p>\n\n\n
\n
void kbase_csf_term_descheduled_queue_group(struct kbase_queue_group *group)\n{\n  ...\n\tfor (i = 0; i < max_streams; i++) {\n\t\tstruct kbase_queue *queue = group->bound_queues[i];\n\n\t\t\/* The group is already being evicted from the scheduler *\/\n\t\tif (queue)\n\t\t\tunbind_stopped_queue(kctx, queue);\n\t}\n  ...\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
This then resets the queue->group<\/code> field of the kbase_queue<\/code> that gets unbound:<\/p>\n\n\n
\n
static void unbind_stopped_queue(struct kbase_context *kctx, struct kbase_queue *queue)\n{\n  ...\n\tif (queue->bind_state != KBASE_CSF_QUEUE_UNBOUND) {\n    ...\n\t\tqueue->group->bound_queues[queue->csi_index] = NULL;\n\t\tqueue->group = NULL;\n    ...\n\t\tqueue->bind_state = KBASE_CSF_QUEUE_UNBOUND;\n\t}\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
In particular, this now allows the kbase_queue<\/code> to bind to another kbase_queue_group<\/code>. This means I can now create a page use-after-free with the following steps:<\/p>\n\n\n\n
    \n
  1. Create a kbase_queue<\/code> and a kbase_queue_group<\/code>, and then bind the kbase_queue<\/code> to the kbase_queue_group<\/code>.<\/li>\n\n\n\n
  2. Create GPU memory pages for the user io pages in the kbase_queue<\/code> and map them to user space using a mmap<\/code> call. These pages are then stored in the queue->phys<\/code> field of the kbase_queue<\/code>.<\/li>\n\n\n\n
  3. Terminate the kbase_queue_group<\/code>, which also unbinds the kbase_queue<\/code>.<\/li>\n\n\n\n
  4. Create another kbase_queue_group<\/code> and bind the kbase_queue<\/code> to this new group.<\/li>\n\n\n\n
  5. Create new GPU memory pages for the user io pages in this kbase_queue<\/code> and map them to user space. These pages now overwrite the existing pages in queue->phys<\/code>.<\/li>\n\n\n\n
  6. Unmap the user space memory that was mapped in step 2. This then frees the pages in queue->phys<\/code> and removes the user space mapping created in step 2. However, the pages that are freed are now the memory pages created and mapped in step 5, which are still mapped to user space.<\/li>\n<\/ol>\n\n\n\n
    This, in particular, means that the pages that are freed in step 6 of the above can still be accessed from the user application. By using a technique<\/a> that I used previously, I can reuse these freed pages as page table global directories (PGD)<\/a> of the Mali GPU.<\/p>\n\n\n\n
    To recap, let’s take a look at how the backing pages of a kbase_va_region<\/code> are allocated. When allocating pages for the backing store of a kbase_va_region<\/code>, the kbase_mem_pool_alloc_pages<\/code><\/a> function is used:<\/p>\n\n\n
    \n
    int kbase_mem_pool_alloc_pages(struct kbase_mem_pool *pool, size_t nr_4k_pages,\n    struct tagged_addr *pages, bool partial_allowed)\n{\n    ...\n  \/* Get pages from this pool *\/\n  while (nr_from_pool--) {\n    p = kbase_mem_pool_remove_locked(pool);     \/\/<------- 1.\n        ...\n  }\n    ...\n  if (i != nr_4k_pages && pool->next_pool) {\n    \/* Allocate via next pool *\/\n    err = kbase_mem_pool_alloc_pages(pool->next_pool,      \/\/<----- 2.\n        nr_4k_pages - i, pages + i, partial_allowed);\n        ...\n  } else {\n    \/* Get any remaining pages from kernel *\/\n    while (i != nr_4k_pages) {\n      p = kbase_mem_alloc_page(pool);     \/\/<------- 3.\n            ...\n        }\n        ...\n  }\n    ...\n}<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
    The input argument kbase_mem_pool<\/code> is a memory pool managed by the kbase_context object associated with the driver file that is used to allocate the GPU memory. As the comments suggest, the allocation is actually done in tiers. First the pages will be allocated from the current kbase_mem_pool<\/code> using kbase_mem_pool_remove_locked<\/code><\/a> (1 in the above). If there is not enough capacity in the current kbase_mem_pool<\/code> to meet the request, then pool->next_pool<\/code>, is used to allocate the pages (2 in the above). If even pool->next_pool<\/code> does not have the capacity, then kbase_mem_alloc_page<\/code><\/a> is used to allocate pages directly from the kernel via the buddy allocator (the page allocator in the kernel).<\/p>\n\n\n\n
    When freeing a page, the same happens in the opposite direction: kbase_mem_pool_free_pages<\/code><\/a> first tries to return the pages to the kbase_mem_pool<\/code> of the current kbase_context<\/code>, if the memory pool is full, it’ll try to return the remaining pages to pool->next_pool<\/code>. If the next pool is also full, then the remaining pages are returned to the kernel by freeing them via the buddy allocator.<\/p>\n\n\n\n
    As noted in my post “Corrupting memory without memory corruption”<\/a>, pool->next_pool<\/code> is a memory pool managed by the Mali driver and shared by all the kbase_context. It is also used for allocating page table global directories (PGD)<\/a> used by GPU contexts. In particular, this means that by carefully arranging the memory pools, it is possible to cause a freed backing page in a kbase_va_region<\/code> to be reused as a PGD of a GPU context. (Read the details<\/a> of how to achieve this.)<\/p>\n\n\n\n
    Once the freed page is reused as a PGD of a GPU context, the user space mapping can be used to rewrite the PGD from the GPU. This then allows any kernel memory, including kernel code, to be mapped to the GPU, which allows me to rewrite kernel code and hence execute arbitrary kernel code. It also allows me to read and write arbitrary kernel data, so I can easily rewrite credentials of my process to gain root, as well as to disable SELinux.<\/p>\n\n\n\n
    See the exploit for Pixel 8<\/a> with some setup notes.<\/p>\n\n\n\n
    How does this bypass MTE?<\/h2>\n\n\n\n
    Before wrapping up, let’s look at why this exploit manages to bypass Memory Tagging Extension (MTE)—despite protections that should have made this type of attack impossible.<\/p>\n\n\n\n
    The Memory Tagging Extension (MTE) is a security feature on newer Arm processors that uses hardware implementations to check for memory corruptions.<\/p>\n\n\n\n
    The Arm64 architecture uses 64 bit pointers to access memory, while most applications use a much smaller address space (for example, 39, 48, or 52 bits). The highest bits in a 64 bit pointer are actually unused. The main idea of memory tagging is to use these higher bits in an address to store a “tag” that can then be used to check against the other tag stored in the memory block associated with the address.<\/p>\n\n\n\n
    When a linear overflow happens and a pointer is used to dereference an adjacent memory block, the tag on the pointer is likely to be different from the tag in the adjacent memory block. By checking these tags at dereference time, such discrepancy, and hence the corrupted dereference can be detected. For use-after-free type memory corruptions, as long as the tag in a memory block is cleared every time it is freed and a new tag reassigned when it is allocated, dereferencing an already freed and reclaimed object will also lead to a discrepancy between pointer tag and the tag in memory, which allows use-after-free to be detected.<\/p>\n\n\n\n
    \"A
    Image from Memory Tagging Extension: Enhancing memory safety through architecture<\/a> published by Arm<\/figcaption><\/figure>\n\n\n\n
    The memory tagging extension is an instruction set introduced in the v8.5a version<\/a> of the ARM architecture, which accelerates the process of tagging and checking of memory with the hardware. This makes it feasible to use memory tagging in practical applications. On architectures where hardware accelerated instructions are available, software support in the memory allocator is still needed to invoke the memory tagging instructions. In the linux kernel, the SLUB allocator<\/a>, used for allocating kernel objects, and the buddy allocator<\/a>, used for allocating memory pages, have support for memory tagging.<\/p>\n\n\n\n
    Readers who are interested in more details can, for example, consult this article<\/a> and the whitepaper<\/a> released by Arm.<\/p>\n\n\n\n
    As I mentioned in the introduction, this exploit is capable of bypassing MTE. However, unlike a previous vulnerability<\/a> that I reported, where a freed memory page is accessed via the GPU, this bug accesses the freed memory page via user space mapping. Since page allocation and dereferencing is protected by MTE, it is perhaps somewhat surprising that this bug manages to bypass MTE. Initially, I thought this was because the memory page that is involved in the vulnerability is managed by kbase_mem_pool<\/code>, which is a custom memory pool used by the Mali GPU driver. In the exploit, the freed memory page that is reused as the PGD is simply returned to the memory pool managed by kbase_mem_pool<\/code>, and then allocated again from the memory pool. So the page was never truly freed by the buddy allocator and therefore not protected by MTE. While this is true, I decided to also try freeing the page properly and return it to the buddy allocator. To my surprise, MTE did not trigger even when the page is accessed after it is freed by the buddy allocator. After some experiments and source code reading, it appears that page mappings created by mgm_vmf_insert_pfn_prot<\/code><\/a> in kbase_csf_user_io_pages_vm_fault<\/code><\/a>, which are used for accessing the memory page after it is freed, ultimately uses insert_pfn<\/code><\/a> to create the mapping, which inserts the page frame into the user space page table. I am not totally sure, but it seems that because the page frames are inserted directly into the user space page table, accessing those pages from user space does not require kernel level dereferencing and therefore does not trigger MTE.<\/p>\n\n\n\n
    Conclusion<\/h2>\n\n\n\n
    In this post I’ve shown how CVE-2025-0072 can be used to gain arbitrary kernel code execution on a Pixel 8 with kernel MTE enabled. Unlike a previous vulnerability<\/a> that I reported, which bypasses MTE by accessing freed memory from the GPU, this vulnerability accesses freed memory via user space memory mapping inserted by the driver. This shows that MTE can also be bypassed when freed memory pages are accessed via memory mappings in user space, which is a much more common scenario than the previous vulnerability.<\/p>\n<\/body><\/html>\n","protected":false},"excerpt":{"rendered":"
    In this post, I\u2019ll look at CVE-2025-0072, a vulnerability in the Arm Mali GPU, and show how it can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.<\/p>\n","protected":false},"author":1878,"featured_media":76158,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_gh_post_show_toc":"yes","_gh_post_is_no_robots":"","_gh_post_is_featured":"yes","_gh_post_is_excluded":"","_gh_post_is_unlisted":"","_gh_post_related_link_1":"","_gh_post_related_link_2":"","_gh_post_related_link_3":"","_gh_post_sq_img":"","_gh_post_sq_img_id":"","_gh_post_cta_title":"","_gh_post_cta_text":"","_gh_post_cta_link":"","_gh_post_cta_button":"","_gh_post_recirc_hide":"","_gh_post_recirc_col_1":"","_gh_post_recirc_col_2":"","_gh_post_recirc_col_3":"","_gh_post_recirc_col_4":"","_featured_video":"","_gh_post_additional_query_params":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2},"_wpas_customize_per_network":false,"jetpack_post_was_ever_published":false,"_links_to":"","_links_to_target":""},"categories":[91,3336],"tags":[2955,2956,1915],"coauthors":[2081],"class_list":["post-88178","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security","category-vulnerability-research","tag-android","tag-exploit-development","tag-github-security-lab"],"yoast_head":"\nBypassing MTE with CVE-2025-0072 - The GitHub Blog<\/title>\n<meta name=\"description\" content=\"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Bypassing MTE with CVE-2025-0072\" \/>\n<meta property=\"og:description\" content=\"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/\" \/>\n<meta property=\"og:site_name\" content=\"The GitHub Blog\" \/>\n<meta property=\"article:published_time\" content=\"2025-05-23T10:00:00+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Man Yue Mo\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Man Yue Mo\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/\"},\"author\":{\"name\":\"Man Yue Mo\",\"@id\":\"https:\\\/\\\/github.blog\\\/#\\\/schema\\\/person\\\/0ac0c5700a6f36214989d4391dbf21b1\"},\"headline\":\"Bypassing MTE with CVE-2025-0072\",\"datePublished\":\"2025-05-23T10:00:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/\"},\"wordCount\":2066,\"image\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/github.blog\\\/wp-content\\\/uploads\\\/2024\\\/01\\\/Security-DarkMode-3-1.png?fit=1200%2C630\",\"keywords\":[\"Android\",\"exploit development\",\"GitHub Security Lab\"],\"articleSection\":[\"Security\",\"Vulnerability research\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/\",\"url\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/\",\"name\":\"Bypassing MTE with CVE-2025-0072 - The GitHub Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/github.blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/github.blog\\\/wp-content\\\/uploads\\\/2024\\\/01\\\/Security-DarkMode-3-1.png?fit=1200%2C630\",\"datePublished\":\"2025-05-23T10:00:00+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/github.blog\\\/#\\\/schema\\\/person\\\/0ac0c5700a6f36214989d4391dbf21b1\"},\"description\":\"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#primaryimage\",\"url\":\"https:\\\/\\\/github.blog\\\/wp-content\\\/uploads\\\/2024\\\/01\\\/Security-DarkMode-3-1.png?fit=1200%2C630\",\"contentUrl\":\"https:\\\/\\\/github.blog\\\/wp-content\\\/uploads\\\/2024\\\/01\\\/Security-DarkMode-3-1.png?fit=1200%2C630\",\"width\":1200,\"height\":630},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/bypassing-mte-with-cve-2025-0072\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/github.blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Security\",\"item\":\"https:\\\/\\\/github.blog\\\/security\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Vulnerability research\",\"item\":\"https:\\\/\\\/github.blog\\\/security\\\/vulnerability-research\\\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Bypassing MTE with CVE-2025-0072\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/github.blog\\\/#website\",\"url\":\"https:\\\/\\\/github.blog\\\/\",\"name\":\"The GitHub Blog\",\"description\":\"Updates, ideas, and inspiration from GitHub to help developers build and design software.\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/github.blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/github.blog\\\/#\\\/schema\\\/person\\\/0ac0c5700a6f36214989d4391dbf21b1\",\"name\":\"Man Yue Mo\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g58cb61bd120c032429ede6698f35624c\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g\",\"caption\":\"Man Yue Mo\"},\"url\":\"https:\\\/\\\/github.blog\\\/author\\\/mymo\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Bypassing MTE with CVE-2025-0072 - The GitHub Blog","description":"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/","og_locale":"en_US","og_type":"article","og_title":"Bypassing MTE with CVE-2025-0072","og_description":"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.","og_url":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/","og_site_name":"The GitHub Blog","article_published_time":"2025-05-23T10:00:00+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","type":"image\/png"}],"author":"Man Yue Mo","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Man Yue Mo","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#article","isPartOf":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/"},"author":{"name":"Man Yue Mo","@id":"https:\/\/github.blog\/#\/schema\/person\/0ac0c5700a6f36214989d4391dbf21b1"},"headline":"Bypassing MTE with CVE-2025-0072","datePublished":"2025-05-23T10:00:00+00:00","mainEntityOfPage":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/"},"wordCount":2066,"image":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#primaryimage"},"thumbnailUrl":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","keywords":["Android","exploit development","GitHub Security Lab"],"articleSection":["Security","Vulnerability research"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/","url":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/","name":"Bypassing MTE with CVE-2025-0072 - The GitHub Blog","isPartOf":{"@id":"https:\/\/github.blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#primaryimage"},"image":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#primaryimage"},"thumbnailUrl":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","datePublished":"2025-05-23T10:00:00+00:00","author":{"@id":"https:\/\/github.blog\/#\/schema\/person\/0ac0c5700a6f36214989d4391dbf21b1"},"description":"See how a vulnerability in the Arm Mali GPU can be exploited to gain kernel code execution even when Memory Tagging Extension (MTE) is enabled.","breadcrumb":{"@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#primaryimage","url":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","contentUrl":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","width":1200,"height":630},{"@type":"BreadcrumbList","@id":"https:\/\/github.blog\/security\/vulnerability-research\/bypassing-mte-with-cve-2025-0072\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/github.blog\/"},{"@type":"ListItem","position":2,"name":"Security","item":"https:\/\/github.blog\/security\/"},{"@type":"ListItem","position":3,"name":"Vulnerability research","item":"https:\/\/github.blog\/security\/vulnerability-research\/"},{"@type":"ListItem","position":4,"name":"Bypassing MTE with CVE-2025-0072"}]},{"@type":"WebSite","@id":"https:\/\/github.blog\/#website","url":"https:\/\/github.blog\/","name":"The GitHub Blog","description":"Updates, ideas, and inspiration from GitHub to help developers build and design software.","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/github.blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/github.blog\/#\/schema\/person\/0ac0c5700a6f36214989d4391dbf21b1","name":"Man Yue Mo","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g58cb61bd120c032429ede6698f35624c","url":"https:\/\/secure.gravatar.com\/avatar\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/b1e7e4060b562f42554cb744fa738e3d3e31d04437c4faf6232bfb29b6d0b6e7?s=96&d=mm&r=g","caption":"Man Yue Mo"},"url":"https:\/\/github.blog\/author\/mymo\/"}]}},"jetpack_publicize_connections":[],"jetpack_shortlink":"https:\/\/wp.me\/pamS32-mWe","jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/github.blog\/wp-content\/uploads\/2024\/01\/Security-DarkMode-3-1.png?fit=1200%2C630","_links":{"self":[{"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/posts\/88178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/users\/1878"}],"replies":[{"embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/comments?post=88178"}],"version-history":[{"count":5,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/posts\/88178\/revisions"}],"predecessor-version":[{"id":88195,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/posts\/88178\/revisions\/88195"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/media\/76158"}],"wp:attachment":[{"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/media?parent=88178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/categories?post=88178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/tags?post=88178"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/github.blog\/wp-json\/wp\/v2\/coauthors?post=88178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}