Bug 2348082 (CVE-2022-49474)

Summary:	CVE-2022-49474 kernel: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	dfreiber, drow, jburrell, vkumar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	A flaw was discovered in the Linux kernel’s Bluetooth subsystem, SCO sockets. When calling sco_sock_connect() and connecting the same socket twice in quick succession, two sco_conn objects may be created, but only one gets associated with the socket. If the socket is closed before the SCO connection is fully established, the timer linked to the dangling sco_conn is not canceled. This results in a use-after-free issue in sco_sock_timeout(), where the kernel attempts to access the freed socket. A local, unprivileged user may exploit this flaw to trigger kernel memory corruption, resulting in system instability or a denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-02-26 03:16:59 UTC

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

Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout

Connecting the same socket twice consecutively in sco_sock_connect()
could lead to a race condition where two sco_conn objects are created
but only one is associated with the socket. If the socket is closed
before the SCO connection is established, the timer associated with the
dangling sco_conn object won't be canceled. As the sock object is being
freed, the use-after-free problem happens when the timer callback
function sco_sock_timeout() accesses the socket. Here's the call trace:

dump_stack+0x107/0x163
? refcount_inc+0x1c/
print_address_description.constprop.0+0x1c/0x47e
? refcount_inc+0x1c/0x7b
kasan_report+0x13a/0x173
? refcount_inc+0x1c/0x7b
check_memory_region+0x132/0x139
refcount_inc+0x1c/0x7b
sco_sock_timeout+0xb2/0x1ba
process_one_work+0x739/0xbd1
? cancel_delayed_work+0x13f/0x13f
? __raw_spin_lock_init+0xf0/0xf0
? to_kthread+0x59/0x85
worker_thread+0x593/0x70e
kthread+0x346/0x35a
? drain_workqueue+0x31a/0x31a
? kthread_bind+0x4b/0x4b
ret_from_fork+0x1f/0x30

Comment 1 Avinash Hanwate 2025-02-26 21:42:00 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025022603-CVE-2022-49474-ce0b@gregkh/T