CVE-2022-49327
In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid journal no-space deadlock by reserving 1 journal bucket
The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation.
When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered.
Leer descripción completaMostrar menos
For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens.
The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore.
This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time.
During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock.
CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Puntuación base: 5.5
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.19%
- Percentil entre todas las CVEs puntuadas: 8
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
CWE
- CWE-667
- CWE-667
Referencias
- https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159
- https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6
- https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363
- https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce
- https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497
JSON original (NVD)
Mostrar
{
"id": "CVE-2022-49327",
"cveTags": [],
"metrics": {
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2022-49327",
"role": "CISA Coordinator",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"version": "2.0.3",
"timestamp": "2025-10-01T19:43:27.047873Z"
}
}
],
"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
},
{
"type": "Secondary",
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"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
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
"lessThan": "59afd4f287900c8187e968a4153ed35e6b48efce",
"versionType": "git"
},
{
"status": "affected",
"version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
"lessThan": "5607652823ac65e2c6885e73bd46d5a4f9a20363",
"versionType": "git"
},
{
"status": "affected",
"version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
"lessThan": "6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497",
"versionType": "git"
},
{
"status": "affected",
"version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
"lessThan": "1dda32aed6f62c163f38ff947ef5b3360e329159",
"versionType": "git"
},
{
"status": "affected",
"version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
"lessThan": "32feee36c30ea06e38ccb8ae6e5c44c6eec790a6",
"versionType": "git"
}
],
"programFiles": [
"drivers/md/bcache/journal.c",
"drivers/md/bcache/journal.h",
"drivers/md/bcache/super.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "3.10",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.10.121",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.46",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "5.17.14",
"versionType": "semver",
"lessThanOrEqual": "5.17.*"
},
{
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver",
"lessThanOrEqual": "5.18.*"
},
{
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/md/bcache/journal.c",
"drivers/md/bcache/journal.h",
"drivers/md/bcache/super.c"
],
"defaultStatus": "affected"
}
]
}
],
"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": "Modified",
"weaknesses": [
{
"type": "Primary",
"source": "nvd@nist.gov",
"description": [
{
"lang": "en",
"value": "CWE-667"
}
]
},
{
"type": "Secondary",
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"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ósito de diario El bloqueo por falta de espacio en el diario se informó de vez en cuando. Tal bloqueo puede ocurrir en la siguiente situación. Cuando todos los depósitos de diario están completamente llenos por jset activo con una carga de E/S de escritura pesada, el registro del conjunto de caché (después de un reinicio) cargará todos los jsets activos y los insertará en el btree nuevamente (lo que se llama reproducción del diario). Si una bkey registrada en el diario se inserta en un nodo btree y da como resultado la división del nodo btree, se puede activar una nueva solicitud de diario. Por ejemplo, el btree crece un nivel más después de la división del nodo, entonces el registro del nodo raíz en el superbloque del dispositivo de caché se actualizará mediante bch_journal_meta() desde bch_btree_set_root(). Pero no hay espacio en los depósitos de diario, la reproducción del diario tiene que esperar a que se recupere un nuevo depósito de diario después de reproducir al menos un depósito de diario. Este es un ejemplo de cómo ocurre el bloqueo por falta de espacio en el diario. La solución para evitar el bloqueo es reservar 1 depósito de diario en tiempo de ejecución y solo permitir que el depósito de diario reservado se use durante el procedimiento de registro del conjunto de caché para cosas como la reproducción del diario. Entonces, el espacio del diario nunca se llenará 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ón en run_cache_set(). En el tiempo de ejecución, cuando journal_reclaim() intenta asignar un nuevo depósito de diario, se llama a free_journal_buckets() para verificar si hay suficientes depósitos de diario libres para usar. Si solo hay 1 depósito de diario libre y journal->do_reserve es 1 (verdadero), el último depósito está reservado y free_journal_buckets() devolverá 0 para indicar que no hay ningún depósito de diario libre. Luego, journal_reclaim() se dará por vencido y la próxima vez intentará ver si hay un depósito de diario libre para asignar. Con este método, siempre hay un depósito de diario reservado en tiempo de ejecución. Durante el registro del conjunto de caché, journal->do_reserve es 0 (falso), por lo que el depósito de diario reservado se puede utilizar para evitar el bloqueo por falta de espacio."
}
],
"lastModified": "2026-06-17T05:17:43.680",
"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"
}