Executive Summary
Informations | |||
---|---|---|---|
Name | CVE-2023-53016 | First vendor Publication | 2025-03-27 |
Vendor | Cve | Last vendor Modification | 2025-03-28 |
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: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: rfcomm_sock_release: This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes. |
Original Source
Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-53016 |
Sources (Detail)
Alert History
Date | Informations |
---|---|
2025-03-31 13:20:36 |
|
2025-03-27 21:20:35 |
|