cve-2024-38636
Vulnerability from cvelistv5
Published
2024-06-21 10:18
Modified
2024-12-19 09:06
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: f2fs: multidev: fix to recognize valid zero block address As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: <TASK> __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length. This WARN is printed even for non-zoned block devices, by following steps. - Create two (non-zoned) null_blk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() treats it as an invalid block address, and then it triggers the warning in iomap framework code. Finally, as discussed, we decide to use a more simple and direct way that checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != NULL_ADDR) to fix this issue. Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue. [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a
Impacted products
Vendor Product Version
Linux Linux Version: 5.17
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-38636",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-06-21T13:27:13.428552Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-21T13:27:24.159Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T04:12:25.978Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/f2fs/data.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc",
              "status": "affected",
              "version": "1517c1a7a4456f080fabc4ac9853930e4b880d14",
              "versionType": "git"
            },
            {
              "lessThan": "2b2611a42462c6c685d40b5f3aedcd8d21c27065",
              "status": "affected",
              "version": "1517c1a7a4456f080fabc4ac9853930e4b880d14",
              "versionType": "git"
            },
            {
              "lessThan": "e8b485e39b4d17afa9a2821fc778d5a67abfc03a",
              "status": "affected",
              "version": "1517c1a7a4456f080fabc4ac9853930e4b880d14",
              "versionType": "git"
            },
            {
              "lessThan": "33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5",
              "status": "affected",
              "version": "1517c1a7a4456f080fabc4ac9853930e4b880d14",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/f2fs/data.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.17"
            },
            {
              "lessThan": "5.17",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.93",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.33",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: multidev: fix to recognize valid zero block address\n\nAs reported by Yi Zhang in mailing list [1], kernel warning was catched\nduring zbd/010 test as below:\n\n./check zbd/010\nzbd/010 (test gap zone support with F2FS)                    [failed]\n    runtime    ...  3.752s\n    something found in dmesg:\n    [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13\n    [ 4378.192349] null_blk: module loaded\n    [ 4378.209860] null_blk: disk nullb0 created\n    [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim\npoll_queues to 0. poll_q/nr_hw = (0/1)\n    [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]\n                     dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0\n    [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux\nscsi_debug       0191 PQ: 0 ANSI: 7\n    [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred\n    [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20\n    [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device\n    ...\n    (See \u0027/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg\u0027\n\nWARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51\nCPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1\nRIP: 0010:iomap_iter+0x32b/0x350\nCall Trace:\n \u003cTASK\u003e\n __iomap_dio_rw+0x1df/0x830\n f2fs_file_read_iter+0x156/0x3d0 [f2fs]\n aio_read+0x138/0x210\n io_submit_one+0x188/0x8c0\n __x64_sys_io_submit+0x8c/0x1a0\n do_syscall_64+0x86/0x170\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nShinichiro Kawasaki helps to analyse this issue and proposes a potential\nfixing patch in [2].\n\nQuoted from reply of Shinichiro Kawasaki:\n\n\"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a\nlook in the commit, but it looks fine to me. So I thought the cause is not\nin the commit diff.\n\nI found the WARN is printed when the f2fs is set up with multiple devices,\nand read requests are mapped to the very first block of the second device in the\ndirect read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()\nmodify map-\u003em_pblk as the physical block address from each block device. It\nbecomes zero when it is mapped to the first block of the device. However,\nf2fs_iomap_begin() assumes that map-\u003em_pblk is the physical block address of the\nwhole f2fs, across the all block devices. It compares map-\u003em_pblk against\nNULL_ADDR == 0, then go into the unexpected branch and sets the invalid\niomap-\u003elength. The WARN catches the invalid iomap-\u003elength.\n\nThis WARN is printed even for non-zoned block devices, by following steps.\n\n - Create two (non-zoned) null_blk devices memory backed with 128MB size each:\n   nullb0 and nullb1.\n # mkfs.f2fs /dev/nullb0 -c /dev/nullb1\n # mount -t f2fs /dev/nullb0 \"${mount_dir}\"\n # dd if=/dev/zero of=\"${mount_dir}/test.dat\" bs=1M count=192\n # dd if=\"${mount_dir}/test.dat\" of=/dev/null bs=1M count=192 iflag=direct\n\n...\"\n\nSo, the root cause of this issue is: when multi-devices feature is on,\nf2fs_map_blocks() may return zero blkaddr in non-primary device, which is\na verified valid block address, however, f2fs_iomap_begin() treats it as\nan invalid block address, and then it triggers the warning in iomap\nframework code.\n\nFinally, as discussed, we decide to use a more simple and direct way that\nchecking (map.m_flags \u0026 F2FS_MAP_MAPPED) condition instead of\n(map.m_pblk != NULL_ADDR) to fix this issue.\n\nThanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this\nissue.\n\n[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/\n[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:06:09.977Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc"
        },
        {
          "url": "https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065"
        },
        {
          "url": "https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a"
        },
        {
          "url": "https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5"
        }
      ],
      "title": "f2fs: multidev: fix to recognize valid zero block address",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-38636",
    "datePublished": "2024-06-21T10:18:24.900Z",
    "dateReserved": "2024-06-18T19:36:34.947Z",
    "dateUpdated": "2024-12-19T09:06:09.977Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-38636\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-06-21T11:15:12.317\",\"lastModified\":\"2024-11-21T09:26:32.753\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nf2fs: multidev: fix to recognize valid zero block address\\n\\nAs reported by Yi Zhang in mailing list [1], kernel warning was catched\\nduring zbd/010 test as below:\\n\\n./check zbd/010\\nzbd/010 (test gap zone support with F2FS)                    [failed]\\n    runtime    ...  3.752s\\n    something found in dmesg:\\n    [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13\\n    [ 4378.192349] null_blk: module loaded\\n    [ 4378.209860] null_blk: disk nullb0 created\\n    [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim\\npoll_queues to 0. poll_q/nr_hw = (0/1)\\n    [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]\\n                     dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0\\n    [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux\\nscsi_debug       0191 PQ: 0 ANSI: 7\\n    [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred\\n    [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20\\n    [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device\\n    ...\\n    (See \u0027/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg\u0027\\n\\nWARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51\\nCPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1\\nRIP: 0010:iomap_iter+0x32b/0x350\\nCall Trace:\\n \u003cTASK\u003e\\n __iomap_dio_rw+0x1df/0x830\\n f2fs_file_read_iter+0x156/0x3d0 [f2fs]\\n aio_read+0x138/0x210\\n io_submit_one+0x188/0x8c0\\n __x64_sys_io_submit+0x8c/0x1a0\\n do_syscall_64+0x86/0x170\\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\\n\\nShinichiro Kawasaki helps to analyse this issue and proposes a potential\\nfixing patch in [2].\\n\\nQuoted from reply of Shinichiro Kawasaki:\\n\\n\\\"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a\\nlook in the commit, but it looks fine to me. So I thought the cause is not\\nin the commit diff.\\n\\nI found the WARN is printed when the f2fs is set up with multiple devices,\\nand read requests are mapped to the very first block of the second device in the\\ndirect read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()\\nmodify map-\u003em_pblk as the physical block address from each block device. It\\nbecomes zero when it is mapped to the first block of the device. However,\\nf2fs_iomap_begin() assumes that map-\u003em_pblk is the physical block address of the\\nwhole f2fs, across the all block devices. It compares map-\u003em_pblk against\\nNULL_ADDR == 0, then go into the unexpected branch and sets the invalid\\niomap-\u003elength. The WARN catches the invalid iomap-\u003elength.\\n\\nThis WARN is printed even for non-zoned block devices, by following steps.\\n\\n - Create two (non-zoned) null_blk devices memory backed with 128MB size each:\\n   nullb0 and nullb1.\\n # mkfs.f2fs /dev/nullb0 -c /dev/nullb1\\n # mount -t f2fs /dev/nullb0 \\\"${mount_dir}\\\"\\n # dd if=/dev/zero of=\\\"${mount_dir}/test.dat\\\" bs=1M count=192\\n # dd if=\\\"${mount_dir}/test.dat\\\" of=/dev/null bs=1M count=192 iflag=direct\\n\\n...\\\"\\n\\nSo, the root cause of this issue is: when multi-devices feature is on,\\nf2fs_map_blocks() may return zero blkaddr in non-primary device, which is\\na verified valid block address, however, f2fs_iomap_begin() treats it as\\nan invalid block address, and then it triggers the warning in iomap\\nframework code.\\n\\nFinally, as discussed, we decide to use a more simple and direct way that\\nchecking (map.m_flags \u0026 F2FS_MAP_MAPPED) condition instead of\\n(map.m_pblk != NULL_ADDR) to fix this issue.\\n\\nThanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this\\nissue.\\n\\n[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/\\n[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: f2fs: multidev: correcci\u00f3n para reconocer una direcci\u00f3n de bloque cero v\u00e1lida. Seg\u00fan lo informado por Yi Zhang en la lista de correo [1], se detect\u00f3 una advertencia del kernel durante la prueba zbd/010 como se muestra a continuaci\u00f3n: ./check zbd/010 zbd/010 (probar soporte de zona de brecha con F2FS) [fall\u00f3] tiempo de ejecuci\u00f3n... 3.752s algo encontrado en dmesg: [4378.146781] ejecutar blktests zbd/010 en 2024-02-18 11:31:13 [4378.192349] null_blk: m\u00f3dulo cargado [4378.209860] null_blk: disco nullb0 creado [4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: recortar poll_queues a 0. poll_q/nr_hw = (0/1) [4378.422334] scsi host15: scsi_debug: versi\u00f3n 019 1 [20210520] dev_size_mb= 1024, opciones = 0x0, enviar_colas = 1, estad\u00edsticas = 0 [4378.434922] scsi 15:0:0:0: Acceso directo-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [4378.443343] scsi 15:0:0:0 : Se produjo el encendido o el restablecimiento del dispositivo [ 4378.449371] sd 15:0:0:0: SCSI gen\u00e9rico sg5 tipo 20 adjunto [ 4378.449418] sd 15:0:0:0: [sdf] Dispositivo de bloqueo de zonas administrado por host... (Consulte \u0027/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg\u0027 ADVERTENCIA: CPU: 22 PID : 44011 en fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio No contaminado 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Seguimiento de llamadas:  __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 Entry_SYSCALL_64_after_hwframe +0x6e/0x76 Shinichiro Kawasaki ayuda a analizar este problema y propone un posible parche de soluci\u00f3n en [2] . Citado de la respuesta de Shinichiro Kawasaki: \\\"Confirm\u00e9 que el commit desencadenante es dbf8e63f48af como inform\u00f3 Yi. Ech\u00e9 un vistazo al compromiso, pero me parece bien. As\u00ed que pens\u00e9 que la causa no est\u00e1 en la diferencia de compromiso. Encontr\u00e9 el WARN se imprime cuando f2fs est\u00e1 configurado con m\u00faltiples dispositivos y las solicitudes de lectura se asignan al primer bloque del segundo dispositivo en la ruta de lectura directa. En este caso, f2fs_map_blocks() y f2fs_map_blocks_cached() modifican map-\u0026gt;m_pblk como. la direcci\u00f3n del bloque f\u00edsico de cada dispositivo de bloque se vuelve cero cuando se asigna al primer bloque del dispositivo. Sin embargo, f2fs_iomap_begin() asume que map-\u0026gt;m_pblk es la direcci\u00f3n del bloque f\u00edsico de todo el f2fs, en todos los dispositivos de bloque. Compara map-\u0026gt;m_pblk con NULL_ADDR == 0, luego ingresa a la rama inesperada y establece la longitud iomap-\u0026gt; no v\u00e1lida. La ADVERTENCIA detecta la longitud iomap-\u0026gt; no v\u00e1lida. Esta ADVERTENCIA se imprime incluso para dispositivos de bloque no zonificados. siguiendo los siguientes pasos: - Cree dos dispositivos null_blk con memoria respaldada con un tama\u00f1o de 128 MB cada uno: nullb0 y nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 \\\"${mount_dir}\\\" # dd if=/dev/zero of=\\\"${mount_dir}/test.dat\\\" bs =1M count=192 # dd if=\\\"${mount_dir}/test.dat\\\" of=/dev/null bs=1M count=192 iflag=direct ...\\\" Entonces, la causa principal de este problema es: cuando -la funci\u00f3n de dispositivos est\u00e1 activada, f2fs_map_blocks() puede devolver cero blkaddr en un dispositivo no principal, que es una direcci\u00f3n de bloque v\u00e1lida verificada; sin embargo, f2fs_iomap_begin() la trata como una direcci\u00f3n de bloque no v\u00e1lida y luego activa la advertencia en el c\u00f3digo del marco iomap Finalmente, como se mencion\u00f3, decidimos utilizar una forma m\u00e1s simple y directa que verificar la condici\u00f3n (map.m_flags \u0026amp; F2FS_MAP_MAPPED) en lugar de (map.m_pblk! = NULL_ADDR) para solucionar este problema. y Shinichiro Kawasaki sobre este tema [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel. org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


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.