CVE-2022-49327

{"id": "CVE-2022-49327", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-02-26T07:01:09.510", "references": [{"url": "https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Undergoing Analysis", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-667"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: avoid journal no-space deadlock by reserving 1 journal bucket\n\nThe journal no-space deadlock was reported time to time. Such deadlock\ncan happen in the following situation.\n\nWhen all journal buckets are fully filled by active jset with heavy\nwrite I/O load, the cache set registration (after a reboot) will load\nall active jsets and inserting them into the btree again (which is\ncalled journal replay). If a journaled bkey is inserted into a btree\nnode and results btree node split, new journal request might be\ntriggered. For example, the btree grows one more level after the node\nsplit, then the root node record in cache device super block will be\nupgrade by bch_journal_meta() from bch_btree_set_root(). But there is no\nspace in journal buckets, the journal replay has to wait for new journal\nbucket to be reclaimed after at least one journal bucket replayed. This\nis one example that how the journal no-space deadlock happens.\n\nThe solution to avoid the deadlock is to reserve 1 journal bucket in\nrun time, and only permit the reserved journal bucket to be used during\ncache set registration procedure for things like journal replay. Then\nthe journal space will never be fully filled, there is no chance for\njournal no-space deadlock to happen anymore.\n\nThis patch adds a new member \"bool do_reserve\" in struct journal, it is\ninititalized to 0 (false) when struct journal is allocated, and set to\n1 (true) by bch_journal_space_reserve() when all initialization done in\nrun_cache_set(). In the run time when journal_reclaim() tries to\nallocate a new journal bucket, free_journal_buckets() is called to check\nwhether there are enough free journal buckets to use. If there is only\n1 free journal bucket and journal->do_reserve is 1 (true), the last\nbucket is reserved and free_journal_buckets() will return 0 to indicate\nno free journal bucket. Then journal_reclaim() will give up, and try\nnext time to see whetheer there is free journal bucket to allocate. By\nthis method, there is always 1 jouranl bucket reserved in run time.\n\nDuring the cache set registration, journal->do_reserve is 0 (false), so\nthe reserved journal bucket can be used to avoid the no-space deadlock."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evitar el bloqueo por falta de espacio en el diario reservando 1 dep\u00f3sito de diario El bloqueo por falta de espacio en el diario se inform\u00f3 de vez en cuando. Tal bloqueo puede ocurrir en la siguiente situaci\u00f3n. Cuando todos los dep\u00f3sitos de diario est\u00e1n completamente llenos por jset activo con una carga de E/S de escritura pesada, el registro del conjunto de cach\u00e9 (despu\u00e9s de un reinicio) cargar\u00e1 todos los jsets activos y los insertar\u00e1 en el btree nuevamente (lo que se llama reproducci\u00f3n del diario). Si una bkey registrada en el diario se inserta en un nodo btree y da como resultado la divisi\u00f3n del nodo btree, se puede activar una nueva solicitud de diario. Por ejemplo, el btree crece un nivel m\u00e1s despu\u00e9s de la divisi\u00f3n del nodo, entonces el registro del nodo ra\u00edz en el superbloque del dispositivo de cach\u00e9 se actualizar\u00e1 mediante bch_journal_meta() desde bch_btree_set_root(). Pero no hay espacio en los dep\u00f3sitos de diario, la reproducci\u00f3n del diario tiene que esperar a que se recupere un nuevo dep\u00f3sito de diario despu\u00e9s de reproducir al menos un dep\u00f3sito de diario. Este es un ejemplo de c\u00f3mo ocurre el bloqueo por falta de espacio en el diario. La soluci\u00f3n para evitar el bloqueo es reservar 1 dep\u00f3sito de diario en tiempo de ejecuci\u00f3n y solo permitir que el dep\u00f3sito de diario reservado se use durante el procedimiento de registro del conjunto de cach\u00e9 para cosas como la reproducci\u00f3n del diario. Entonces, el espacio del diario nunca se llenar\u00e1 por completo, ya no hay posibilidad de que se produzca un bloqueo por falta de espacio en el diario. Este parche agrega un nuevo miembro \"bool do_reserve\" en struct journal, se inicializa a 0 (falso) cuando se asigna struct journal y se establece en 1 (verdadero) por bch_journal_space_reserve() cuando se realiza toda la inicializaci\u00f3n en run_cache_set(). En el tiempo de ejecuci\u00f3n, cuando journal_reclaim() intenta asignar un nuevo dep\u00f3sito de diario, se llama a free_journal_buckets() para verificar si hay suficientes dep\u00f3sitos de diario libres para usar. Si solo hay 1 dep\u00f3sito de diario libre y journal->do_reserve es 1 (verdadero), el \u00faltimo dep\u00f3sito est\u00e1 reservado y free_journal_buckets() devolver\u00e1 0 para indicar que no hay ning\u00fan dep\u00f3sito de diario libre. Luego, journal_reclaim() se dar\u00e1 por vencido y la pr\u00f3xima vez intentar\u00e1 ver si hay un dep\u00f3sito de diario libre para asignar. Con este m\u00e9todo, siempre hay un dep\u00f3sito de diario reservado en tiempo de ejecuci\u00f3n. Durante el registro del conjunto de cach\u00e9, journal->do_reserve es 0 (falso), por lo que el dep\u00f3sito de diario reservado se puede utilizar para evitar el bloqueo por falta de espacio."}], "lastModified": "2025-03-13T21:50:54.760", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "814C88C6-C31D-462A-BBBE-BC83E102E84C", "versionEndExcluding": "5.10.121"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "20D41697-0E8B-4B7D-8842-F17BF2AA21E1", "versionEndExcluding": "5.15.46", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "15E2DD33-2255-4B76-9C15-04FF8CBAB252", "versionEndExcluding": "5.17.14", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8E122216-2E9E-4B3E-B7B8-D575A45BA3C2", "versionEndExcluding": "5.18.3", "versionStartIncluding": "5.18"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}