ghsa-w9qv-8mcj-wh8f
Vulnerability from github
Published
2024-05-17 15:31
Modified
2024-05-17 15:31
Details

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

btrfs: fix race in read_extent_buffer_pages()

There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed.

To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks:

/* (1) */
if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))
    return 0;

/* (2) */
if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))
    goto done;

At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does

/* (3) */
set_extent_buffer_uptodate(eb);

/* (4) */
clear_bit(EXTENT_BUFFER_READING, &eb->bflags);

Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving:

Thread A | Thread B | Thread C
---------+----------+---------
   (1)   |          |
         |    (1)   |
   (2)   |          |
   (3)   |          |
   (4)   |          |
         |    (2)   |
         |          |    (1)

When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified:

BTRFS critical (device dm-0): corrupted node, root=256
block=8550954455682405139 owner mismatch, have 11858205567642294356
expect [256, 18446744073709551360]

Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read.

[ minor update of changelog ]

Show details on source website

To clipboard 

{
   affected: [],
   aliases: [
      "CVE-2024-35798",
   ],
   database_specific: {
      cwe_ids: [],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-05-17T14:15:12Z",
      severity: null,
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race in read_extent_buffer_pages()\n\nThere are reports from tree-checker that detects corrupted nodes,\nwithout any obvious pattern so possibly an overwrite in memory.\nAfter some debugging it turns out there's a race when reading an extent\nbuffer the uptodate status can be missed.\n\nTo prevent concurrent reads for the same extent buffer,\nread_extent_buffer_pages() performs these checks:\n\n    /* (1) */\n    if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))\n        return 0;\n\n    /* (2) */\n    if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))\n        goto done;\n\nAt this point, it seems safe to start the actual read operation. Once\nthat completes, end_bbio_meta_read() does\n\n    /* (3) */\n    set_extent_buffer_uptodate(eb);\n\n    /* (4) */\n    clear_bit(EXTENT_BUFFER_READING, &eb->bflags);\n\nNormally, this is enough to ensure only one read happens, and all other\ncallers wait for it to finish before returning.  Unfortunately, there is\na racey interleaving:\n\n    Thread A | Thread B | Thread C\n    ---------+----------+---------\n       (1)   |          |\n             |    (1)   |\n       (2)   |          |\n       (3)   |          |\n       (4)   |          |\n             |    (2)   |\n             |          |    (1)\n\nWhen this happens, thread B kicks of an unnecessary read. Worse, thread\nC will see UPTODATE set and return immediately, while the read from\nthread B is still in progress.  This race could result in tree-checker\nerrors like this as the extent buffer is concurrently modified:\n\n    BTRFS critical (device dm-0): corrupted node, root=256\n    block=8550954455682405139 owner mismatch, have 11858205567642294356\n    expect [256, 18446744073709551360]\n\nFix it by testing UPTODATE again after setting the READING bit, and if\nit's been set, skip the unnecessary read.\n\n[ minor update of changelog ]",
   id: "GHSA-w9qv-8mcj-wh8f",
   modified: "2024-05-17T15:31:09Z",
   published: "2024-05-17T15:31:09Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-35798",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215",
      },
   ],
   schema_version: "1.4.0",
   severity: [],
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.