Executive Summary

Informations
Name CVE-2023-52438 First vendor Publication 2024-02-20
Vendor Cve Last vendor Modification 2024-03-15

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Overall CVSS Score 7.8
Base Score 7.8 Environmental Score 7.8
impact SubScore 5.9 Temporal Score 7.8
Exploitabality Sub Score 1.8
 
Attack Vector Local Attack Complexity Low
Privileges Required Low User Interaction None
Scope Unchanged Confidentiality Impact High
Integrity Impact High Availability Impact High
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

In the Linux kernel, the following vulnerability has been resolved:

binder: fix use-after-free in shinker's callback

The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") the mmap lock is downgraded after the vma has been isolated.

I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF:

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

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

Allocated by task 492:
kmem_cache_alloc+0x130/0x368
vm_area_alloc+0x2c/0x190
mmap_region+0x258/0x18bc
do_mmap+0x694/0xa60
vm_mmap_pgoff+0x170/0x29c
ksys_mmap_pgoff+0x290/0x3a0
__arm64_sys_mmap+0xcc/0x144

Freed by task 491:
kmem_cache_free+0x17c/0x3c8
vm_area_free_rcu_cb+0x74/0x98
rcu_core+0xa38/0x26d4
rcu_core_si+0x10/0x1c
__do_softirq+0x2fc/0xd24

Last potentially related work creation:
__call_rcu_common.constprop.0+0x6c/0xba0
call_rcu+0x10/0x1c
vm_area_free+0x18/0x24
remove_vma+0xe4/0x118
do_vmi_align_munmap.isra.0+0x718/0xb5c
do_vmi_munmap+0xdc/0x1fc
__vm_munmap+0x10c/0x278
__arm64_sys_munmap+0x58/0x7c

Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway.

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52438

CWE : Common Weakness Enumeration

% Id Name
100 % CWE-416 Use After Free

CPE : Common Platform Enumeration

TypeDescriptionCount
Application 8
Os 3561

Sources (Detail)

https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906
https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6
https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56
https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869
https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3
https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c
https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727
Source Url

Alert History

If you want to see full details history, please login or register.
0
1
Date Informations
2024-03-15 17:27:35
  • Multiple Updates
2024-02-21 05:27:23
  • First insertion