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