CVE-2022-49327
Linux kernel: Bcache Journal No-Space Deadlock Vulnerability
Description
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. 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.
INFO
Published Date :
Feb. 26, 2025, 7:01 a.m.
Last Modified :
March 13, 2025, 9:50 p.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
3.6
Exploitability Score :
1.8
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2022-49327.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2022-49327 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2022-49327 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Mar. 13, 2025
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-667 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 from (excluding) 5.15.46 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 from (excluding) 5.17.14 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.18 from (excluding) 5.18.3 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (excluding) 5.10.121 Added Reference Type kernel.org: https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497 Types: Patch -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Feb. 26, 2025
Action Type Old Value New Value Added Description 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. 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. Added Reference https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159 Added Reference https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6 Added Reference https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363 Added Reference https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce Added Reference https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2022-49327 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2022-49327
weaknesses.