CVE-2022-49272
published 2025-02-26CVE-2022-49272: 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…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.20%
10.1th percentile
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.
Affected
21 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.17.3-1 (bookworm) | linux 5.17.3-1 (bookworm) |
| linux | linux | >= 08d1807f097a63ea00a7067dad89c1c81cb2115e < 9661bf674d6a82b76e4ae424438a8ce1e3ed855d | 9661bf674d6a82b76e4ae424438a8ce1e3ed855d |
| linux | linux | >= 47711ff10c7e126702cfa725f6d86ef529d15a5f < 7777744e92a0b30e3e0cce2758d911837011ebd9 | 7777744e92a0b30e3e0cce2758d911837011ebd9 |
| linux | linux | >= 4d1b0ace2d56dc27cc4921eda7fae57f77f03eb5 < abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e | abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e |
| linux | linux | >= 5.10.109 < 5.10.110 | 5.10.110 |
| linux | linux | >= 5.15.32 < 5.15.33 | 5.15.33 |
| linux | linux | >= 5.16.18 < 5.16.19 | 5.16.19 |
| linux | linux | >= 5.17.1 < 5.17.2 | 5.17.2 |
| linux | linux | >= 73867cb2bc7dfa7fbd219e53a0b68d253d8fda09 < 7e9133607e1501c94881be35e118d8f84d96dcb4 | 7e9133607e1501c94881be35e118d8f84d96dcb4 |
| linux | linux | >= 8527c8f052fb42091c6569cb928e472376a4a889 < 9017201e8d8c6d1472273361389ed431188584a0 | 9017201e8d8c6d1472273361389ed431188584a0 |
| linux | linux | >= b3830197aa7413c65767cf5a1aa8775c83f0dbf7 < 40f4cffbe13a51faf136faf5f9ef6847782cd595 | 40f4cffbe13a51faf136faf5f9ef6847782cd595 |
| linux | linux | >= dca947d4d26dbf925a64a6cfb2ddbc035e831a3d < bc55cfd5718c7c23e5524582e9fa70b4d10f2433 | bc55cfd5718c7c23e5524582e9fa70b4d10f2433 |
| linux | linux | >= dd2f8c684da3e226e5ec7a81c89ff5fd4a957a03 < be9813ad2fc8f0885f5ce6925af0d993ce5da4e5 | be9813ad2fc8f0885f5ce6925af0d993ce5da4e5 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.113-1 | 5.10.113-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-5w6j-rmq5-x4x9: In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caugh
ghsa_unreviewed·2025-09-22
CVE-2022-49272 [MEDIUM] CWE-667 GHSA-5w6j-rmq5-x4x9: In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caugh
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
OSV
CVE-2022-49272: 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
osv·2025-02-26·CVSS 5.5
CVE-2022-49272 [MEDIUM] CVE-2022-49272: 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
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 com
Red Hat
kernel: ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49272 [MEDIUM] kernel: ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
kernel: ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
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
Debian
CVE-2022-49272: linux - In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: ...
vendor_debian·2022·CVSS 5.5
CVE-2022-49272 [MEDIUM] CVE-2022-49272: linux - In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: ...
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 com
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855dhttps://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2ehttps://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5
2025-02-26
Published