mirror of
https://github.com/fkie-cad/nvd-json-data-feeds.git
synced 2025-05-28 17:21:36 +00:00
29 lines
3.6 KiB
JSON
29 lines
3.6 KiB
JSON
{
|
|
"id": "CVE-2024-42149",
|
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
|
"published": "2024-07-30T08:15:06.543",
|
|
"lastModified": "2024-07-30T13:32:45.943",
|
|
"vulnStatus": "Awaiting Analysis",
|
|
"cveTags": [],
|
|
"descriptions": [
|
|
{
|
|
"lang": "en",
|
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: don't misleadingly warn during thaw operations\n\nThe block device may have been frozen before it was claimed by a\nfilesystem. Concurrently another process might try to mount that\nfrozen block device and has temporarily claimed the block device for\nthat purpose causing a concurrent fs_bdev_thaw() to end up here. The\nmounter is already about to abort mounting because they still saw an\nelevanted bdev->bd_fsfreeze_count so get_bdev_super() will return\nNULL in that case.\n\nFor example, P1 calls dm_suspend() which calls into bdev_freeze() before\nthe block device has been claimed by the filesystem. This brings\nbdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is\nrequired.\n\nNow P2 tries to mount that frozen block device. It claims it and checks\nbdev->bd_fsfreeze_count. As it's elevated it aborts mounting.\n\nIn the meantime P3 called dm_resume(). P3 sees that the block device is\nalready claimed by a filesystem and calls into fs_bdev_thaw().\n\nP3 takes a passive reference and realizes that the filesystem isn't\nready yet. P3 puts itself to sleep to wait for the filesystem to become\nready.\n\nP2 now puts the last active reference to the filesystem and marks it as\ndying. P3 gets woken, sees that the filesystem is dying and\nget_bdev_super() fails."
|
|
},
|
|
{
|
|
"lang": "es",
|
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: fs: no advierta de manera enga\u00f1osa durante las operaciones de descongelaci\u00f3n. Es posible que el dispositivo de bloque se haya congelado antes de que un sistema de archivos lo reclamara. Al mismo tiempo, otro proceso podr\u00eda intentar montar ese dispositivo de bloque congelado y ha reclamado temporalmente el dispositivo de bloque para ese prop\u00f3sito, lo que provoca que un fs_bdev_thaw() concurrente termine aqu\u00ed. El montador ya est\u00e1 a punto de cancelar el montaje porque todav\u00eda vio un bdev->bd_fsfreeze_count elevado, por lo que get_bdev_super() devolver\u00e1 NULL en ese caso. Por ejemplo, P1 llama a dm_suspend(), que llama a bdev_freeze() antes de que el sistema de archivos haya reclamado el dispositivo de bloque. Esto lleva bdev->bd_fsfreeze_count a 1 y no se requiere ninguna llamada a fs_bdev_freeze(). Ahora P2 intenta montar ese dispositivo de bloque congelado. Lo reclama y comprueba bdev->bd_fsfreeze_count. Al estar elevado se aborta el montaje. Mientras tanto, P3 llam\u00f3 a dm_resume(). P3 ve que el dispositivo de bloque ya est\u00e1 reclamado por un sistema de archivos y llama a fs_bdev_thaw(). P3 toma una referencia pasiva y se da cuenta de que el sistema de archivos a\u00fan no est\u00e1 listo. P3 se pone en modo de suspensi\u00f3n para esperar a que el sistema de archivos est\u00e9 listo. P2 ahora coloca la \u00faltima referencia activa al sistema de archivos y lo marca como moribundo. P3 se despierta, ve que el sistema de archivos est\u00e1 muriendo y get_bdev_super() falla."
|
|
}
|
|
],
|
|
"metrics": {},
|
|
"references": [
|
|
{
|
|
"url": "https://git.kernel.org/stable/c/25b1e3906e050d452427bc51620bb7f0a591373a",
|
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
|
},
|
|
{
|
|
"url": "https://git.kernel.org/stable/c/2ae4db5647d807efb6a87c09efaa6d1db9c905d7",
|
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
|
}
|
|
]
|
|
} |