ghsa-w9qr-vr3p-gqmx
Vulnerability from github
Published
2024-04-04 09:30
Modified
2024-11-07 21:31
Severity ?
5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Details

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

btrfs: fix race between ordered extent completion and fiemap

For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc).

However by not locking the target extent range for the whole duration of the fiemap call we can race with an ordered extent. This happens like this:

1) The fiemap task finishes processing a file extent item that covers the file range [512K, 1M[, and that file extent item is the last item in the leaf currently being processed;

2) And ordered extent for the file range [768K, 2M[, in COW mode, completes (btrfs_finish_one_ordered()) and the file extent item covering the range [512K, 1M[ is trimmed to cover the range [512K, 768K[ and then a new file extent item for the range [768K, 2M[ is inserted in the inode's subvolume tree;

3) The fiemap task calls fiemap_next_leaf_item(), which then calls btrfs_next_leaf() to find the next leaf / item. This finds that the the next key following the one we previously processed (its type is BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding to the new file extent item inserted by the ordered extent, which has a type of BTRFS_EXTENT_DATA_KEY and an offset of 768K;

4) Later the fiemap code ends up at emit_fiemap_extent() and triggers the warning:

  if (cache->offset + cache->len > offset) {
           WARN_ON(1);
           return -EINVAL;
  }

Since we get 1M > 768K, because the previously emitted entry for the old extent covering the file range [512K, 1M[ ends at an offset that is greater than the new extent's start offset (768K). This makes fiemap fail with -EINVAL besides triggering the warning that produces a stack trace like the following:

 [1621.677651] ------------[ cut here ]------------
 [1621.677656] WARNING: CPU: 1 PID: 204366 at fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs]
 [1621.677899] Modules linked in: btrfs blake2b_generic (...)
 [1621.677951] CPU: 1 PID: 204366 Comm: pool Not tainted 6.8.0-rc5-btrfs-next-151+ #1
 [1621.677954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs]
 [1621.678033] Code: 2b 4c 89 63 (...)
 [1621.678035] RSP: 0018:ffffab16089ffd20 EFLAGS: 00010206
 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000
 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI: ffffab16089ffe90
 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 0000000000000000
 [1621.678041] R10: 0000000000000000 R11: 0000000000001000 R12: 0000000041d78000
 [1621.678043] R13: 0000000000001000 R14: 0000000000000000 R15: ffff9434f0b17850
 [1621.678044] FS:  00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) knlGS:0000000000000000
 [1621.678046] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [1621.678048] CR2: 00007fa6b0801000 CR3: 000000012d404002 CR4: 0000000000370ef0
 [1621.678053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 [1621.678055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 [1621.678056] Call Trace:
 [1621.678074]  <TASK>
 [1621.678076]  ? __warn+0x80/0x130
 [1621.678082]  ? emit_fiemap_extent+0x84/0x90 [btrfs]
 [1621.678159]  ? report_bug+0x1f4/0x200
 [1621.678164]  ? handle_bug+0x42/0x70
 [1621.678167]  ? exc_invalid_op+0x14/0x70
 [1621.678170]  ? asm_exc_invalid_op+0x16/0x20
 [1621.678178]  ? emit_fiemap_extent+0x84/0x90 [btrfs]
 [1621.678253]  extent_fiemap+0x766

---truncated---

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26794"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-04T09:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between ordered extent completion and fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nHowever by not locking the target extent range for the whole duration of\nthe fiemap call we can race with an ordered extent. This happens like\nthis:\n\n1) The fiemap task finishes processing a file extent item that covers\n   the file range [512K, 1M[, and that file extent item is the last item\n   in the leaf currently being processed;\n\n2) And ordered extent for the file range [768K, 2M[, in COW mode,\n   completes (btrfs_finish_one_ordered()) and the file extent item\n   covering the range [512K, 1M[ is trimmed to cover the range\n   [512K, 768K[ and then a new file extent item for the range [768K, 2M[\n   is inserted in the inode\u0027s subvolume tree;\n\n3) The fiemap task calls fiemap_next_leaf_item(), which then calls\n   btrfs_next_leaf() to find the next leaf / item. This finds that the\n   the next key following the one we previously processed (its type is\n   BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding\n   to the new file extent item inserted by the ordered extent, which has\n   a type of BTRFS_EXTENT_DATA_KEY and an offset of 768K;\n\n4) Later the fiemap code ends up at emit_fiemap_extent() and triggers\n   the warning:\n\n      if (cache-\u003eoffset + cache-\u003elen \u003e offset) {\n               WARN_ON(1);\n               return -EINVAL;\n      }\n\n   Since we get 1M \u003e 768K, because the previously emitted entry for the\n   old extent covering the file range [512K, 1M[ ends at an offset that\n   is greater than the new extent\u0027s start offset (768K). This makes fiemap\n   fail with -EINVAL besides triggering the warning that produces a stack\n   trace like the following:\n\n     [1621.677651] ------------[ cut here ]------------\n     [1621.677656] WARNING: CPU: 1 PID: 204366 at fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs]\n     [1621.677899] Modules linked in: btrfs blake2b_generic (...)\n     [1621.677951] CPU: 1 PID: 204366 Comm: pool Not tainted 6.8.0-rc5-btrfs-next-151+ #1\n     [1621.677954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n     [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs]\n     [1621.678033] Code: 2b 4c 89 63 (...)\n     [1621.678035] RSP: 0018:ffffab16089ffd20 EFLAGS: 00010206\n     [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000\n     [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI: ffffab16089ffe90\n     [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 0000000000000000\n     [1621.678041] R10: 0000000000000000 R11: 0000000000001000 R12: 0000000041d78000\n     [1621.678043] R13: 0000000000001000 R14: 0000000000000000 R15: ffff9434f0b17850\n     [1621.678044] FS:  00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) knlGS:0000000000000000\n     [1621.678046] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n     [1621.678048] CR2: 00007fa6b0801000 CR3: 000000012d404002 CR4: 0000000000370ef0\n     [1621.678053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n     [1621.678055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n     [1621.678056] Call Trace:\n     [1621.678074]  \u003cTASK\u003e\n     [1621.678076]  ? __warn+0x80/0x130\n     [1621.678082]  ? emit_fiemap_extent+0x84/0x90 [btrfs]\n     [1621.678159]  ? report_bug+0x1f4/0x200\n     [1621.678164]  ? handle_bug+0x42/0x70\n     [1621.678167]  ? exc_invalid_op+0x14/0x70\n     [1621.678170]  ? asm_exc_invalid_op+0x16/0x20\n     [1621.678178]  ? emit_fiemap_extent+0x84/0x90 [btrfs]\n     [1621.678253]  extent_fiemap+0x766\n---truncated---",
  "id": "GHSA-w9qr-vr3p-gqmx",
  "modified": "2024-11-07T21:31:37Z",
  "published": "2024-04-04T09:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26794"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31d07a757c6d3430e03cc22799921569999b9a12"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1a4a9ca77f143c00fce69c1239887ff8b813bec"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d43f8e58f10a44df8c08e7f7076f3288352cd168"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}


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 seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • 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.