GHSA-CGFP-5VMP-V4J6
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-10-01 21:30In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix deadlock in concurrent rename whiteout and inode writeback
Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0
[ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770
, are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock!
Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout
Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes).
{
"affected": [],
"aliases": [
"CVE-2021-47637"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T06:37:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix deadlock in concurrent rename whiteout and inode writeback\n\nFollowing hung tasks:\n[ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132\n[ 77.028820] Call Trace:\n[ 77.029027] schedule+0x8c/0x1b0\n[ 77.029067] mutex_lock+0x50/0x60\n[ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]\n[ 77.029117] __writeback_single_inode+0x43c/0x570\n[ 77.029128] writeback_sb_inodes+0x259/0x740\n[ 77.029148] wb_writeback+0x107/0x4d0\n[ 77.029163] wb_workfn+0x162/0x7b0\n\n[ 92.390442] task:aa state:D stack: 0 pid: 1506\n[ 92.390448] Call Trace:\n[ 92.390458] schedule+0x8c/0x1b0\n[ 92.390461] wb_wait_for_completion+0x82/0xd0\n[ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110\n[ 92.390472] writeback_inodes_sb_nr+0x14/0x20\n[ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]\n[ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]\n[ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]\n[ 92.390571] vfs_rename+0xdb2/0x1170\n[ 92.390580] do_renameat2+0x554/0x770\n\n, are caused by concurrent rename whiteout and inode writeback processes:\n\trename_whiteout(Thread 1)\t wb_workfn(Thread2)\nubifs_rename\n do_rename\n lock_4_inodes (Hold ui_mutex)\n ubifs_budget_space\n make_free_space\n shrink_liability\n\t __writeback_inodes_sb_nr\n\t bdi_split_work_to_wbs (Queue new wb work)\n\t\t\t\t\t wb_do_writeback(wb work)\n\t\t\t\t\t\t__writeback_single_inode\n\t\t\t\t\t ubifs_write_inode\n\t\t\t\t\t LOCK(ui_mutex)\n\t\t\t\t\t\t\t \u2191\n\t wb_wait_for_completion (Wait wb work) \u003c-- deadlock!\n\nReproducer (Detail program in [Link]):\n 1. SYS_renameat2(\"/mp/dir/file\", \"/mp/dir/whiteout\", RENAME_WHITEOUT)\n 2. Consume out of space before kernel(mdelay) doing budget for whiteout\n\nFix it by doing whiteout space budget before locking ubifs inodes.\nBTW, it also fixes wrong goto tag \u0027out_release\u0027 in whiteout budget\nerror handling path(It should at least recover dir i_size and unlock\n4 ubifs inodes).",
"id": "GHSA-cgfp-5vmp-v4j6",
"modified": "2025-10-01T21:30:52Z",
"published": "2025-03-18T21:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47637"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.