CVE-2023-53247 (GCVE-0-2023-53247)
Vulnerability from cvelistv5
Published
2025-09-15 14:46
Modified
2025-09-15 14:46
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand While trying to get the subpage blocksize tests running, I hit the following panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198 This happens because during btrfs_cont_expand we'll get a page, set it as mapped, and if it's not Uptodate we'll read it. However between the read and re-locking the page we could have called release_folio() on the page, but left the page in the file mapping. release_folio() can clear the page private, and thus further down we blow up when we go to modify the subpage bits. Fix this by putting the set_page_extent_mapped() after the read. This is safe because read_folio() will call set_page_extent_mapped() before it does the read, and then if we clear page private but leave it on the mapping we're completely safe re-setting set_page_extent_mapped(). With this patch I can now run generic/476 without panicing.
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Create a notification for this product.
   Linux Linux Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/inode.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0a5e0bc8e8618e32a6ca64450867628eb0a627bf",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "a5880e69cf7fe4a0bb1eabae02205352d1b59b7b",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "17b17fcd6d446b95904a6929c40012ee7f0afc0c",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/inode.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.42",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.4.*",
              "status": "unaffected",
              "version": "6.4.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.5",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.42",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.4.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand\n\nWhile trying to get the subpage blocksize tests running, I hit the\nfollowing panic on generic/476\n\n  assertion failed: PagePrivate(page) \u0026\u0026 page-\u003eprivate, in fs/btrfs/subpage.c:229\n  kernel BUG at fs/btrfs/subpage.c:229!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n  CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12\n  Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023\n  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n  pc : btrfs_subpage_assert+0xbc/0xf0\n  lr : btrfs_subpage_assert+0xbc/0xf0\n  Call trace:\n   btrfs_subpage_assert+0xbc/0xf0\n   btrfs_subpage_clear_checked+0x38/0xc0\n   btrfs_page_clear_checked+0x48/0x98\n   btrfs_truncate_block+0x5d0/0x6a8\n   btrfs_cont_expand+0x5c/0x528\n   btrfs_write_check.isra.0+0xf8/0x150\n   btrfs_buffered_write+0xb4/0x760\n   btrfs_do_write_iter+0x2f8/0x4b0\n   btrfs_file_write_iter+0x1c/0x30\n   do_iter_readv_writev+0xc8/0x158\n   do_iter_write+0x9c/0x210\n   vfs_iter_write+0x24/0x40\n   iter_file_splice_write+0x224/0x390\n   direct_splice_actor+0x38/0x68\n   splice_direct_to_actor+0x12c/0x260\n   do_splice_direct+0x90/0xe8\n   generic_copy_file_range+0x50/0x90\n   vfs_copy_file_range+0x29c/0x470\n   __arm64_sys_copy_file_range+0xcc/0x498\n   invoke_syscall.constprop.0+0x80/0xd8\n   do_el0_svc+0x6c/0x168\n   el0_svc+0x50/0x1b0\n   el0t_64_sync_handler+0x114/0x120\n   el0t_64_sync+0x194/0x198\n\nThis happens because during btrfs_cont_expand we\u0027ll get a page, set it\nas mapped, and if it\u0027s not Uptodate we\u0027ll read it.  However between the\nread and re-locking the page we could have called release_folio() on the\npage, but left the page in the file mapping.  release_folio() can clear\nthe page private, and thus further down we blow up when we go to modify\nthe subpage bits.\n\nFix this by putting the set_page_extent_mapped() after the read.  This\nis safe because read_folio() will call set_page_extent_mapped() before\nit does the read, and then if we clear page private but leave it on the\nmapping we\u0027re completely safe re-setting set_page_extent_mapped().  With\nthis patch I can now run generic/476 without panicing."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-09-15T14:46:17.344Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf"
        },
        {
          "url": "https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b"
        },
        {
          "url": "https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c"
        }
      ],
      "title": "btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-53247",
    "datePublished": "2025-09-15T14:46:17.344Z",
    "dateReserved": "2025-09-15T14:19:21.848Z",
    "dateUpdated": "2025-09-15T14:46:17.344Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-53247\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-09-15T15:15:51.930\",\"lastModified\":\"2025-09-15T15:22:27.090\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand\\n\\nWhile trying to get the subpage blocksize tests running, I hit the\\nfollowing panic on generic/476\\n\\n  assertion failed: PagePrivate(page) \u0026\u0026 page-\u003eprivate, in fs/btrfs/subpage.c:229\\n  kernel BUG at fs/btrfs/subpage.c:229!\\n  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\\n  CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12\\n  Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023\\n  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\\n  pc : btrfs_subpage_assert+0xbc/0xf0\\n  lr : btrfs_subpage_assert+0xbc/0xf0\\n  Call trace:\\n   btrfs_subpage_assert+0xbc/0xf0\\n   btrfs_subpage_clear_checked+0x38/0xc0\\n   btrfs_page_clear_checked+0x48/0x98\\n   btrfs_truncate_block+0x5d0/0x6a8\\n   btrfs_cont_expand+0x5c/0x528\\n   btrfs_write_check.isra.0+0xf8/0x150\\n   btrfs_buffered_write+0xb4/0x760\\n   btrfs_do_write_iter+0x2f8/0x4b0\\n   btrfs_file_write_iter+0x1c/0x30\\n   do_iter_readv_writev+0xc8/0x158\\n   do_iter_write+0x9c/0x210\\n   vfs_iter_write+0x24/0x40\\n   iter_file_splice_write+0x224/0x390\\n   direct_splice_actor+0x38/0x68\\n   splice_direct_to_actor+0x12c/0x260\\n   do_splice_direct+0x90/0xe8\\n   generic_copy_file_range+0x50/0x90\\n   vfs_copy_file_range+0x29c/0x470\\n   __arm64_sys_copy_file_range+0xcc/0x498\\n   invoke_syscall.constprop.0+0x80/0xd8\\n   do_el0_svc+0x6c/0x168\\n   el0_svc+0x50/0x1b0\\n   el0t_64_sync_handler+0x114/0x120\\n   el0t_64_sync+0x194/0x198\\n\\nThis happens because during btrfs_cont_expand we\u0027ll get a page, set it\\nas mapped, and if it\u0027s not Uptodate we\u0027ll read it.  However between the\\nread and re-locking the page we could have called release_folio() on the\\npage, but left the page in the file mapping.  release_folio() can clear\\nthe page private, and thus further down we blow up when we go to modify\\nthe subpage bits.\\n\\nFix this by putting the set_page_extent_mapped() after the read.  This\\nis safe because read_folio() will call set_page_extent_mapped() before\\nit does the read, and then if we clear page private but leave it on the\\nmapping we\u0027re completely safe re-setting set_page_extent_mapped().  With\\nthis patch I can now run generic/476 without panicing.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.
  • 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…