Executive Summary
Informations | |||
---|---|---|---|
Name | CVE-2024-56555 | First vendor Publication | 2024-12-27 |
Vendor | Cve | Last vendor Modification | 2024-12-27 |
Security-Database Scoring CVSS v3
Cvss vector : N/A | |||
---|---|---|---|
Overall CVSS Score | NA | ||
Base Score | NA | Environmental Score | NA |
impact SubScore | NA | Temporal Score | NA |
Exploitabality Sub Score | NA | ||
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 OOB in binder_add_freeze_work() In binder_add_freeze_work() we iterate over the proc->nodes with the proc->inner_lock held. However, this lock is temporarily dropped to acquire the node->lock first (lock nesting order). This can race with binder_deferred_release() which removes the nodes from the proc->nodes rbtree and adds them into binder_dead_nodes list. This leads to a broken iteration in binder_add_freeze_work() as rb_next() will use data from binder_dead_nodes, triggering an out-of-bounds access: ================================================================== CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18 The buggy address belongs to the variable: This is possible because proc->nodes (rbtree) and binder_dead_nodes (list) share entries in binder_node through a union: struct binder_node { Fix the race by checking that the proc is still alive. If not, simply break out of the iteration. |
Original Source
Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56555 |
Sources (Detail)
Source | Url |
---|
Alert History
Date | Informations |
---|---|
2024-12-27 21:20:29 |
|