ghsa-5w6j-rmq5-x4x9
Vulnerability from github
Published
2025-09-22 21:30
Modified
2025-09-22 21:30
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

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.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock\n\nsyzbot caught a potential deadlock between the PCM\nruntime-\u003ebuffer_mutex and the mm-\u003emmap_lock.  It was brought by the\nrecent fix to cover the racy read/write and other ioctls, and in that\ncommit, I overlooked a (hopefully only) corner case that may take the\nrevert lock, namely, the OSS mmap.  The OSS mmap operation\nexceptionally allows to re-configure the parameters inside the OSS\nmmap syscall, where mm-\u003emmap_mutex is already held.  Meanwhile, the\ncopy_from/to_user calls at read/write operations also take the\nmm-\u003emmap_lock internally, hence it may lead to a AB/BA deadlock.\n\nA similar problem was already seen in the past and we fixed it with a\nrefcount (in commit b248371628aa).  The former fix covered only the\ncall paths with OSS read/write and OSS ioctls, while we need to cover\nthe concurrent access via both ALSA and OSS APIs now.\n\nThis patch addresses the problem above by replacing the buffer_mutex\nlock in the read/write operations with a refcount similar as we\u0027ve\nused for OSS.  The new field, runtime-\u003ebuffer_accessing, keeps the\nnumber of concurrent read/write operations.  Unlike the former\nbuffer_mutex protection, this protects only around the\ncopy_from/to_user() calls; the other codes are basically protected by\nthe PCM stream lock.  The refcount can be a negative, meaning blocked\nby the ioctls.  If a negative value is seen, the read/write aborts\nwith -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,\nand set to a negative value for blocking unless it\u0027s already being\naccessed.",
  "id": "GHSA-5w6j-rmq5-x4x9",
  "modified": "2025-09-22T21:30:16Z",
  "published": "2025-09-22T21:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49272"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.