linux-cve-announce - CVE-2022-49272: ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025022630-CVE-2022-49272-4b85@gregkh>
Date: Wed, 26 Feb 2025 02:57:57 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49272: ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

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.

The Linux kernel CVE team has assigned CVE-2022-49272 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.10.109 with commit 8527c8f052fb42091c6569cb928e472376a4a889 and fixed in 5.10.110 with commit 9017201e8d8c6d1472273361389ed431188584a0
	Issue introduced in 5.15.32 with commit 47711ff10c7e126702cfa725f6d86ef529d15a5f and fixed in 5.15.33 with commit 7777744e92a0b30e3e0cce2758d911837011ebd9
	Issue introduced in 5.16.18 with commit 4d1b0ace2d56dc27cc4921eda7fae57f77f03eb5 and fixed in 5.16.19 with commit abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e
	Issue introduced in 5.17.1 with commit dd2f8c684da3e226e5ec7a81c89ff5fd4a957a03 and fixed in 5.17.2 with commit be9813ad2fc8f0885f5ce6925af0d993ce5da4e5

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49272
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	include/sound/pcm.h
	sound/core/pcm.c
	sound/core/pcm_lib.c
	sound/core/pcm_native.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4
	https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595
	https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855d
	https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0
	https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9
	https://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e
	https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5
	https://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433