cve-2024-50118
Vulnerability from cvelistv5
Published
2024-11-05 17:10
Modified
2024-12-19 09:33
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: reject ro->rw reconfiguration if there are hard ro requirements [BUG] Syzbot reports the following crash: BTRFS info (device loop0 state MCS): disabling free space tree BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1) BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2) Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Call Trace: <TASK> btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [inline] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [inline] __do_sys_mount fs/namespace.c:4020 [inline] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] To support mounting different subvolume with different RO/RW flags for the new mount APIs, btrfs introduced two workaround to support this feature: - Skip mount option/feature checks if we are mounting a different subvolume - Reconfigure the fs to RW if the initial mount is RO Combining these two, we can have the following sequence: - Mount the fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all will mark the fs as hard read-only, so no v2 cache clearing will happen. - Mount a subvolume rw of the same fs. We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY because our new fc is RW, different from the original fs. Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag first so that we can grab the existing fs_info. Then we reconfigure the fs to RW. - During reconfiguration, option/features check is skipped This means we will restart the v2 cache clearing, and convert back to v1 cache. This will trigger fs writes, and since the original fs has "rescue=all" option, it skips the csum tree read. And eventually causing NULL pointer dereference in super block writeback. [FIX] For reconfiguration caused by different subvolume RO/RW flags, ensure we always run btrfs_check_options() to ensure we have proper hard RO requirements met. In fact the function btrfs_check_options() doesn't really do many complex checks, but hard RO requirement and some feature dependency checks, thus there is no special reason not to do the check for mount reconfiguration.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/23724398b55d9570f6ae79dd2ea026fff8896bf1Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3c36a72c1d27de6618c1c480c793d9924640f5bbPatch
Impacted products
Vendor Product Version
Linux Linux Version: f044b318675f0347ecfb88377542651ba4eb9e1f
Version: f044b318675f0347ecfb88377542651ba4eb9e1f
 Create a notification for this product.
   Linux Linux Version: 6.8
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "23724398b55d9570f6ae79dd2ea026fff8896bf1",
              "status": "affected",
              "version": "f044b318675f0347ecfb88377542651ba4eb9e1f",
              "versionType": "git"
            },
            {
              "lessThan": "3c36a72c1d27de6618c1c480c793d9924640f5bb",
              "status": "affected",
              "version": "f044b318675f0347ecfb88377542651ba4eb9e1f",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject ro-\u003erw reconfiguration if there are hard ro requirements\n\n[BUG]\nSyzbot reports the following crash:\n\n  BTRFS info (device loop0 state MCS): disabling free space tree\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n  RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]\n  RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041\n  Call Trace:\n   \u003cTASK\u003e\n   btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530\n   btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312\n   btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012\n   btrfs_remount_rw fs/btrfs/super.c:1309 [inline]\n   btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534\n   btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]\n   btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]\n   btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115\n   vfs_get_tree+0x90/0x2b0 fs/super.c:1800\n   do_new_mount+0x2be/0xb40 fs/namespace.c:3472\n   do_mount fs/namespace.c:3812 [inline]\n   __do_sys_mount fs/namespace.c:4020 [inline]\n   __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[CAUSE]\nTo support mounting different subvolume with different RO/RW flags for\nthe new mount APIs, btrfs introduced two workaround to support this feature:\n\n- Skip mount option/feature checks if we are mounting a different\n  subvolume\n\n- Reconfigure the fs to RW if the initial mount is RO\n\nCombining these two, we can have the following sequence:\n\n- Mount the fs ro,rescue=all,clear_cache,space_cache=v1\n  rescue=all will mark the fs as hard read-only, so no v2 cache clearing\n  will happen.\n\n- Mount a subvolume rw of the same fs.\n  We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY\n  because our new fc is RW, different from the original fs.\n\n  Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag\n  first so that we can grab the existing fs_info.\n  Then we reconfigure the fs to RW.\n\n- During reconfiguration, option/features check is skipped\n  This means we will restart the v2 cache clearing, and convert back to\n  v1 cache.\n  This will trigger fs writes, and since the original fs has \"rescue=all\"\n  option, it skips the csum tree read.\n\n  And eventually causing NULL pointer dereference in super block\n  writeback.\n\n[FIX]\nFor reconfiguration caused by different subvolume RO/RW flags, ensure we\nalways run btrfs_check_options() to ensure we have proper hard RO\nrequirements met.\n\nIn fact the function btrfs_check_options() doesn\u0027t really do many\ncomplex checks, but hard RO requirement and some feature dependency\nchecks, thus there is no special reason not to do the check for mount\nreconfiguration."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:33:27.387Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/23724398b55d9570f6ae79dd2ea026fff8896bf1"
        },
        {
          "url": "https://git.kernel.org/stable/c/3c36a72c1d27de6618c1c480c793d9924640f5bb"
        }
      ],
      "title": "btrfs: reject ro-\u003erw reconfiguration if there are hard ro requirements",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50118",
    "datePublished": "2024-11-05T17:10:48.641Z",
    "dateReserved": "2024-10-21T19:36:19.948Z",
    "dateUpdated": "2024-12-19T09:33:27.387Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-50118\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-11-05T18:15:14.887\",\"lastModified\":\"2024-11-08T18:02:21.617\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: reject ro-\u003erw reconfiguration if there are hard ro requirements\\n\\n[BUG]\\nSyzbot reports the following crash:\\n\\n  BTRFS info (device loop0 state MCS): disabling free space tree\\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)\\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)\\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI\\n  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\\n  RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]\\n  RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041\\n  Call Trace:\\n   \u003cTASK\u003e\\n   btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530\\n   btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312\\n   btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012\\n   btrfs_remount_rw fs/btrfs/super.c:1309 [inline]\\n   btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534\\n   btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]\\n   btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]\\n   btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115\\n   vfs_get_tree+0x90/0x2b0 fs/super.c:1800\\n   do_new_mount+0x2be/0xb40 fs/namespace.c:3472\\n   do_mount fs/namespace.c:3812 [inline]\\n   __do_sys_mount fs/namespace.c:4020 [inline]\\n   __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997\\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\\n   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\\n\\n[CAUSE]\\nTo support mounting different subvolume with different RO/RW flags for\\nthe new mount APIs, btrfs introduced two workaround to support this feature:\\n\\n- Skip mount option/feature checks if we are mounting a different\\n  subvolume\\n\\n- Reconfigure the fs to RW if the initial mount is RO\\n\\nCombining these two, we can have the following sequence:\\n\\n- Mount the fs ro,rescue=all,clear_cache,space_cache=v1\\n  rescue=all will mark the fs as hard read-only, so no v2 cache clearing\\n  will happen.\\n\\n- Mount a subvolume rw of the same fs.\\n  We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY\\n  because our new fc is RW, different from the original fs.\\n\\n  Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag\\n  first so that we can grab the existing fs_info.\\n  Then we reconfigure the fs to RW.\\n\\n- During reconfiguration, option/features check is skipped\\n  This means we will restart the v2 cache clearing, and convert back to\\n  v1 cache.\\n  This will trigger fs writes, and since the original fs has \\\"rescue=all\\\"\\n  option, it skips the csum tree read.\\n\\n  And eventually causing NULL pointer dereference in super block\\n  writeback.\\n\\n[FIX]\\nFor reconfiguration caused by different subvolume RO/RW flags, ensure we\\nalways run btrfs_check_options() to ensure we have proper hard RO\\nrequirements met.\\n\\nIn fact the function btrfs_check_options() doesn\u0027t really do many\\ncomplex checks, but hard RO requirement and some feature dependency\\nchecks, thus there is no special reason not to do the check for mount\\nreconfiguration.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: rechazar la reconfiguraci\u00f3n de ro-\u0026gt;rw si hay requisitos de ro estrictos [ERROR]. Syzbot informa del siguiente fallo: Informaci\u00f3n de BTRFS (estado de loop0 del dispositivo MCS): deshabilitar el \u00e1rbol de espacio libre Informaci\u00f3n de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de funci\u00f3n de compatibilidad para FREE_SPACE_TREE (0x1) Informaci\u00f3n de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de funci\u00f3n de compatibilidad para FREE_SPACE_TREE_VALID (0x2) Vaya: error de protecci\u00f3n general, probablemente para la direcci\u00f3n no can\u00f3nica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000018-0x000000000000001f] Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [en l\u00ednea] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Seguimiento de llamadas:  btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [en l\u00ednea] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [en l\u00ednea] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [en l\u00ednea] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [en l\u00ednea] __do_sys_mount fs/namespace.c:4020 [en l\u00ednea] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Para admitir el montaje de diferentes subvol\u00famenes con diferentes indicadores RO/RW para las nuevas API de montaje, btrfs introdujo dos workarounds para admitir esta funci\u00f3n: - Omitir las comprobaciones de opciones/funciones de montaje si estamos montando un subvolumen diferente - Reconfigurar el fs a RW si el montaje inicial es RO Combinando estos dos, podemos tener la siguiente secuencia: - Montar el fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all marcar\u00e1 el fs como de solo lectura, por lo que no se borrar\u00e1 la cach\u00e9 v2. - Montar un subvolumen rw del mismo fs. Entramos en btrfs_get_tree_subvol(), pero fc_mount() devuelve EBUSY porque nuestro nuevo fc es RW, diferente del fs original. Ahora ingresamos btrfs_reconfigure_for_mount(), que cambia el indicador RO primero para que podamos obtener el fs_info existente. Luego reconfiguramos el fs a RW. - Durante la reconfiguraci\u00f3n, se omite la verificaci\u00f3n de opciones/caracter\u00edsticas Esto significa que reiniciaremos el borrado de la cach\u00e9 v2 y volveremos a la cach\u00e9 v1. Esto activar\u00e1 escrituras en el sistema de archivos y, dado que el sistema de archivos original tiene la opci\u00f3n \\\"rescue=all\\\", omite la lectura del \u00e1rbol csum. Y, eventualmente, provoca la desreferencia del puntero NULL en la reescritura del superbloque. [SOLUCI\u00d3N] Para la reconfiguraci\u00f3n causada por diferentes indicadores de RO/RW de subvolumen, aseg\u00farese de que siempre ejecutamos btrfs_check_options() para garantizar que se cumplan los requisitos de RO estrictos adecuados. De hecho, la funci\u00f3n btrfs_check_options() no realiza muchas comprobaciones complejas, sino requisitos de RO estrictos y algunas comprobaciones de dependencia de funciones, por lo que no hay ninguna raz\u00f3n especial para no realizar la comprobaci\u00f3n para la reconfiguraci\u00f3n del montaje.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-476\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.8\",\"versionEndExcluding\":\"6.11.6\",\"matchCriteriaId\":\"2CAA29A6-36B4-4C90-A862-A816F65153DB\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3C95E234-D335-4B6C-96BF-E2CEBD8654ED\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"E0F717D8-3014-4F84-8086-0124B2111379\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/23724398b55d9570f6ae79dd2ea026fff8896bf1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/3c36a72c1d27de6618c1c480c793d9924640f5bb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


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.