GHSA-4RQ6-QV3V-654P

Vulnerability from github – Published: 2024-12-28 12:30 – Updated: 2024-12-28 12:30
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix race in buffer_head read fault injection

When I enabled ext4 debug for fault injection testing, I encountered the following warning:

EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0

The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions.

[CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty WARN_ON_ONCE(!buffer_uptodate(bh))

The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb.

Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-56686"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-28T10:15:11Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix race in buffer_head read fault injection\n\nWhen I enabled ext4 debug for fault injection testing, I encountered the\nfollowing warning:\n\n  EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress:\n         Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051\n  WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0\n\nThe root cause of the issue lies in the improper implementation of ext4\u0027s\nbuffer_head read fault injection. The actual completion of buffer_head\nread and the buffer_head fault injection are not atomic, which can lead\nto the uptodate flag being cleared on normally used buffer_heads in race\nconditions.\n\n[CPU0]           [CPU1]         [CPU2]\next4_read_inode_bitmap\n  ext4_read_bh()\n  \u003cbh read complete\u003e\n                 ext4_read_inode_bitmap\n                   if (buffer_uptodate(bh))\n                     return bh\n                               jbd2_journal_commit_transaction\n                                 __jbd2_journal_refile_buffer\n                                   __jbd2_journal_unfile_buffer\n                                     __jbd2_journal_temp_unlink_buffer\n  ext4_simulate_fail_bh()\n    clear_buffer_uptodate\n                                      mark_buffer_dirty\n                                        \u003creport warning\u003e\n                                        WARN_ON_ONCE(!buffer_uptodate(bh))\n\nThe best approach would be to perform fault injection in the IO completion\ncallback function, rather than after IO completion. However, the IO\ncompletion callback function cannot get the fault injection code in sb.\n\nFix it by passing the result of fault injection into the bh read function,\nwe simulate faults within the bh read function itself. This requires adding\nan extra parameter to the bh read functions that need fault injection.",
  "id": "GHSA-4rq6-qv3v-654p",
  "modified": "2024-12-28T12:30:47Z",
  "published": "2024-12-28T12:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56686"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25a5acf88fed59e060405bbb48098f4a3a2c2adc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f3d93e210b9c2866c8b3662adae427d5bf511ec"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61832ee7fa2fbd569d129379e795038abfb0d128"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/77035e4d27e15f87ea55929c8bb8fb1970129e2f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

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.



Detection rules are retrieved from Rulezet.