In the Linux kernel, a vulnerability has been resolved involving a use-after-free issue in the shrinker's callback. The problem lies in the fact that the mmap read lock is used during the callback, leaving the alloc->vma pointer unsafe as it can race with munmap(). This article will provide an overview of the vulnerability, how it was reproduced, the KASAN report, and the fix that was applied to address the issue.

Original references

1. Linux kernel GitHub commit - dd2283f2605e
2. Linux kernel GitHub commit - 1c8b86a3799f
3. KASAN: slab-use-after-free

Exploit details

The issue was successfully reproduced by manually adding delays and triggering page reclaiming via the shrinker's debug sysfs. The KASAN report confirmed the use-after-free vulnerability. The KASAN report is as follows:

  ==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+x470/x4b8
  Read of size 8 at addr ffff356ed50e50f by task bash/478

  CPU: 1 PID: 478 Comm: bash Not tainted 6.6.-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+x470/x4b8
   binder_alloc_free_page+x608/xadc
   __list_lru_walk_one+x130/x3b
   list_lru_walk_node+xc4/x22c
   binder_shrink_scan+x108/x1dc
   shrinker_debugfs_scan_write+x2b4/x500
   full_proxy_write+xd4/x140
   vfs_write+x1ac/x758
   ksys_write+xf/x1dc
   __arm64_sys_write+x6c/x9c
...

Solution

To fix the issue, a vma_lookup() function was used instead of the unsafe alloc->vma pointer. This approach not only makes the code safe from the use-after-free issue but also offers better performance compared to upgrading to a mmap write lock, which would increase contention. Additionally, mmap_write_trylock() has been removed recently, so this workaround is more effective.

In conclusion, the CVE-2023-52438 vulnerability in the Linux kernel has been addressed by changing the method used to ensure the safety of the alloc->vma pointer. By using the vma_lookup() function, developers have effectively eliminated the use-after-free issue and improved performance. This fix not only resolves the vulnerability but also provides a more efficient and safer solution than some alternatives.

Timeline

Published on: 02/20/2024 21:15:08 UTC
Last modified on: 03/15/2024 14:03:51 UTC