ghsa-cgfp-5vmp-v4j6
Vulnerability from github
Published
2025-03-18 21:31
Modified
2025-10-01 21:30
Details

In 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).

Show details on source website


{
  "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"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…