fkie_cve-2022-49272
Vulnerability from fkie_nvd
Published
2025-02-26 07:01
Modified
2025-02-26 07:01
Severity ?
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Arreglar un posible bloqueo AB/BA con buffer_mutex y mmap_lock syzbot captur\u00f3 un posible punto muerto entre PCM runtime-\u0026gt;buffer_mutex y mm-\u0026gt;mmap_lock. Fue provocado por la correcci\u00f3n reciente para cubrir la lectura/escritura acelerada y otras ioctl, y en esa confirmaci\u00f3n, pas\u00e9 por alto un caso extremo (con suerte el \u00fanico) que puede tomar el bloqueo de reversi\u00f3n, es decir, el mmap de OSS. La operaci\u00f3n mmap de OSS permite excepcionalmente reconfigurar los par\u00e1metros dentro de la llamada al sistema mmap de OSS, donde ya se mantiene mm-\u0026gt;mmap_mutex. Mientras tanto, las llamadas copy_from/to_user en operaciones de lectura/escritura tambi\u00e9n toman el mm-\u0026gt;mmap_lock internamente, por lo tanto, puede llevar a un punto muerto AB/BA. Ya se vio un problema similar en el pasado y lo arreglamos con un refcount (en el commit b248371628aa). La correcci\u00f3n anterior solo cubr\u00eda las rutas de llamadas con lectura/escritura de OSS y controles ioctl de OSS, mientras que ahora necesitamos cubrir el acceso concurrente a trav\u00e9s de las API de ALSA y OSS. Este parche soluciona el problema anterior al reemplazar el bloqueo buffer_mutex en las operaciones de lectura/escritura con un refcount similar al que hemos usado para OSS. El nuevo campo, runtime-\u0026gt;buffer_accessing, mantiene el n\u00famero de operaciones de lectura/escritura concurrentes. A diferencia de la protecci\u00f3n buffer_mutex anterior, esto protege solo alrededor de las llamadas copy_from/to_user(); los otros c\u00f3digos est\u00e1n b\u00e1sicamente protegidos por el bloqueo de flujo PCM. El refcount puede ser negativo, lo que significa que est\u00e1 bloqueado por los controles ioctl. Si se ve un valor negativo, la lectura/escritura se cancela con -EBUSY. En el lado de los controles ioctl, por otro lado, tambi\u00e9n verifican este refcount y lo establecen en un valor negativo para bloquear a menos que ya se est\u00e9 accediendo a \u00e9l."
}
],
"id": "CVE-2022-49272",
"lastModified": "2025-02-26T07:01:04.097",
"metrics": {},
"published": "2025-02-26T07:01:04.097",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
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.
Loading…
Loading…