ghsa-25m9-3j97-v6cg
Vulnerability from github
Published
2024-03-26 18:32
Modified
2024-11-04 15:31
Details

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

ext4: avoid online resizing failures due to oversized flex bg

When we online resize an ext4 filesystem with a oversized flexbg_size,

 mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
 mount $dev $dir
 resize2fs $dev 16G

the following WARN_ON is triggered:

WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ==================================================================

This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is:

(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52622"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-26T18:15:08Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid online resizing failures due to oversized flex bg\n\nWhen we online resize an ext4 filesystem with a oversized flexbg_size,\n\n     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M\n     mount $dev $dir\n     resize2fs $dev 16G\n\nthe following WARN_ON is triggered:\n==================================================================\nWARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550\nModules linked in: sg(E)\nCPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314\nRIP: 0010:__alloc_pages+0x411/0x550\nCall Trace:\n \u003cTASK\u003e\n __kmalloc_large_node+0xa2/0x200\n __kmalloc+0x16e/0x290\n ext4_resize_fs+0x481/0xd80\n __ext4_ioctl+0x1616/0x1d90\n ext4_ioctl+0x12/0x20\n __x64_sys_ioctl+0xf0/0x150\n do_syscall_64+0x3b/0x90\n==================================================================\n\nThis is because flexbg_size is too large and the size of the new_group_data\narray to be allocated exceeds MAX_ORDER. Currently, the minimum value of\nMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding\nmaximum number of groups that can be allocated is:\n\n (PAGE_SIZE \u003c\u003c MAX_ORDER) / sizeof(struct ext4_new_group_data) \u2248 21845\n\nAnd the value that is down-aligned to the power of 2 is 16384. Therefore,\nthis value is defined as MAX_RESIZE_BG, and the number of groups added\neach time does not exceed this value during resizing, and is added multiple\ntimes to complete the online resizing. The difference is that the metadata\nin a flex_bg may be more dispersed.",
  "id": "GHSA-25m9-3j97-v6cg",
  "modified": "2024-11-04T15:31:53Z",
  "published": "2024-03-26T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52622"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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