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.
Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Mon, 22 Sep 2025 20:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-667
CPEs cpe:2.3:o:linux:linux_kernel:5.10.109:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.15.32:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.16.18:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17.1:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel

Sat, 10 May 2025 03:30:00 +0000

Type Values Removed Values Added
First Time appeared Redhat
Redhat enterprise Linux
CPEs cpe:/a:redhat:enterprise_linux:9
cpe:/o:redhat:enterprise_linux:8
cpe:/o:redhat:enterprise_linux:9
Vendors & Products Redhat
Redhat enterprise Linux

Thu, 27 Feb 2025 01:45:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Wed, 26 Feb 2025 02:15:00 +0000

Type Values Removed Values 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.
Title ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
References

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-05-04T08:33:54.705Z

Reserved: 2025-02-26T01:49:39.297Z

Link: CVE-2022-49272

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2025-02-26T07:01:04.097

Modified: 2025-09-22T20:32:39.203

Link: CVE-2022-49272

cve-icon Redhat

Severity : Moderate

Publid Date: 2025-02-26T00:00:00Z

Links: CVE-2022-49272 - Bugzilla

cve-icon OpenCVE Enrichment

No data.