U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Vulnerability Change Records for CVE-2022-49272

Change History

New CVE Received from kernel.org 2/26/2025 2:01:04 AM

Action Type Old Value New Value
Added Description

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

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

syzbot caught a potential deadlock between the PCM
runtime->buffer_mutex and the mm->mmap_lock.  It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap.  The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm->mmap_mutex is already held.  Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.

A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628aa).  The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.

This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS.  The new field, runtime->buffer_accessing, keeps the
number of concurrent read/write operations.  Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock.  The refcount can be a negative, meaning blocked
by the ioctls.  If a negative value is seen, the read/write aborts
with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855d
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433
Added Reference

								
							
							
						
https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5