CVE-2021-46989 (GCVE-0-2021-46989)
Vulnerability from cvelistv5
Published
2024-02-28 08:13
Modified
2025-05-04 07:01
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: hfsplus: prevent corruption in shrinking truncate I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check.
References
Impacted products
Vendor Product Version
Linux Linux Version: 31651c607151f1034cfb57e5a78678bea54c362b
Version: 31651c607151f1034cfb57e5a78678bea54c362b
Version: 31651c607151f1034cfb57e5a78678bea54c362b
Version: 31651c607151f1034cfb57e5a78678bea54c362b
Version: 31651c607151f1034cfb57e5a78678bea54c362b
Version: 31651c607151f1034cfb57e5a78678bea54c362b
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2021-46989",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-02-28T18:24:07.661826Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "description": "CWE-noinfo Not enough information",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-04T16:56:31.426Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T05:24:37.918Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/hfsplus/extents.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "52dde855663e5db824af51db39b5757d2ef3e28a",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            },
            {
              "lessThan": "c451a6bafb5f422197d31536f82116aed132b72c",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            },
            {
              "lessThan": "adbd8a2a8cc05d9e501f93e5c95c59307874cc99",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            },
            {
              "lessThan": "c477f62db1a0c0ecaa60a29713006ceeeb04b685",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            },
            {
              "lessThan": "97314e45aa1223a42d60256a62c5d9af54baf446",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            },
            {
              "lessThan": "c3187cf32216313fb316084efac4dab3a8459b1d",
              "status": "affected",
              "version": "31651c607151f1034cfb57e5a78678bea54c362b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/hfsplus/extents.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.19"
            },
            {
              "lessThan": "4.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.191",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.120",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.38",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.11.*",
              "status": "unaffected",
              "version": "5.11.22",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.12.*",
              "status": "unaffected",
              "version": "5.12.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.191",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.120",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.38",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.11.22",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.12.5",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.13",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: prevent corruption in shrinking truncate\n\nI believe there are some issues introduced by commit 31651c607151\n(\"hfsplus: avoid deadlock on file truncation\")\n\nHFS+ has extent records which always contains 8 extents.  In case the\nfirst extent record in catalog file gets full, new ones are allocated from\nextents overflow file.\n\nIn case shrinking truncate happens to middle of an extent record which\nlocates in extents overflow file, the logic in hfsplus_file_truncate() was\nchanged so that call to hfs_brec_remove() is not guarded any more.\n\nRight action would be just freeing the extents that exceed the new size\ninside extent record by calling hfsplus_free_extents(), and then check if\nthe whole extent record should be removed.  However since the guard\n(blk_cnt \u003e start) is now after the call to hfs_brec_remove(), this has\nunfortunate effect that the last matching extent record is removed\nunconditionally.\n\nTo reproduce this issue, create a file which has at least 10 extents, and\nthen perform shrinking truncate into middle of the last extent record, so\nthat the number of remaining extents is not under or divisible by 8.  This\ncauses the last extent record (8 extents) to be removed totally instead of\ntruncating into middle of it.  Thus this causes corruption, and lost data.\n\nFix for this is simply checking if the new truncated end is below the\nstart of this extent record, making it safe to remove the full extent\nrecord.  However call to hfs_brec_remove() can\u0027t be moved to it\u0027s previous\nplace since we\u0027re dropping -\u003etree_lock and it can cause a race condition\nand the cached info being invalidated possibly corrupting the node data.\n\nAnother issue is related to this one.  When entering into the block\n(blk_cnt \u003e start) we are not holding the -\u003etree_lock.  We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it.  Not\nsure if it\u0027s possible for someone else to take the lock under our feet,\nbut it can cause hard to debug errors and premature unlocking.  Even if\nthere\u0027s no real risk of it, the locking should still always be kept in\nbalance.  Thus taking the lock now just before the check."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T07:01:50.434Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a"
        },
        {
          "url": "https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c"
        },
        {
          "url": "https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99"
        },
        {
          "url": "https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685"
        },
        {
          "url": "https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446"
        },
        {
          "url": "https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d"
        }
      ],
      "title": "hfsplus: prevent corruption in shrinking truncate",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2021-46989",
    "datePublished": "2024-02-28T08:13:15.930Z",
    "dateReserved": "2024-02-27T18:42:55.948Z",
    "dateUpdated": "2025-05-04T07:01:50.434Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2021-46989\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-02-28T09:15:37.687\",\"lastModified\":\"2025-03-14T19:02:38.240\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nhfsplus: prevent corruption in shrinking truncate\\n\\nI believe there are some issues introduced by commit 31651c607151\\n(\\\"hfsplus: avoid deadlock on file truncation\\\")\\n\\nHFS+ has extent records which always contains 8 extents.  In case the\\nfirst extent record in catalog file gets full, new ones are allocated from\\nextents overflow file.\\n\\nIn case shrinking truncate happens to middle of an extent record which\\nlocates in extents overflow file, the logic in hfsplus_file_truncate() was\\nchanged so that call to hfs_brec_remove() is not guarded any more.\\n\\nRight action would be just freeing the extents that exceed the new size\\ninside extent record by calling hfsplus_free_extents(), and then check if\\nthe whole extent record should be removed.  However since the guard\\n(blk_cnt \u003e start) is now after the call to hfs_brec_remove(), this has\\nunfortunate effect that the last matching extent record is removed\\nunconditionally.\\n\\nTo reproduce this issue, create a file which has at least 10 extents, and\\nthen perform shrinking truncate into middle of the last extent record, so\\nthat the number of remaining extents is not under or divisible by 8.  This\\ncauses the last extent record (8 extents) to be removed totally instead of\\ntruncating into middle of it.  Thus this causes corruption, and lost data.\\n\\nFix for this is simply checking if the new truncated end is below the\\nstart of this extent record, making it safe to remove the full extent\\nrecord.  However call to hfs_brec_remove() can\u0027t be moved to it\u0027s previous\\nplace since we\u0027re dropping -\u003etree_lock and it can cause a race condition\\nand the cached info being invalidated possibly corrupting the node data.\\n\\nAnother issue is related to this one.  When entering into the block\\n(blk_cnt \u003e start) we are not holding the -\u003etree_lock.  We break out from\\nthe loop not holding the lock, but hfs_find_exit() does unlock it.  Not\\nsure if it\u0027s possible for someone else to take the lock under our feet,\\nbut it can cause hard to debug errors and premature unlocking.  Even if\\nthere\u0027s no real risk of it, the locking should still always be kept in\\nbalance.  Thus taking the lock now just before the check.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: hfsplus: evita la corrupci\u00f3n al reducir y truncar Creo que hay algunos problemas introducidos por el commit 31651c607151 (\\\"hfsplus: evita el punto muerto en el truncamiento de archivos\\\") HFS+ tiene registros de extensi\u00f3n que siempre contienen 8 extensiones. En caso de que el primer registro de extensi\u00f3n en el archivo de cat\u00e1logo se llene, se asignan nuevos registros desde el archivo de desbordamiento de extensiones. En caso de que se produzca un truncamiento reducido en la mitad de un registro de extensi\u00f3n que se ubica en un archivo de desbordamiento de extensiones, la l\u00f3gica en hfsplus_file_truncate() se cambi\u00f3 para que la llamada a hfs_brec_remove() ya no est\u00e9 protegida. La acci\u00f3n correcta ser\u00eda simplemente liberar las extensiones que exceden el nuevo tama\u00f1o dentro del registro de extensi\u00f3n llamando a hfsplus_free_extents() y luego verificar si se debe eliminar todo el registro de extensi\u00f3n. Sin embargo, dado que la guardia (blk_cnt \u0026gt; start) est\u00e1 ahora despu\u00e9s de la llamada a hfs_brec_remove(), esto tiene el efecto desafortunado de que el \u00faltimo registro de extensi\u00f3n coincidente se elimina incondicionalmente. Para reproducir este problema, cree un archivo que tenga al menos 10 extensiones y luego realice un truncamiento reducido hasta la mitad del \u00faltimo registro de extensi\u00f3n, de modo que el n\u00famero de extensiones restantes no sea menor o divisible por 8. Esto hace que el \u00faltimo registro de extensi\u00f3n ( 8 extensiones) para eliminarse por completo en lugar de truncarse a la mitad. Por tanto, esto provoca corrupci\u00f3n y p\u00e9rdida de datos. La soluci\u00f3n para esto es simplemente verificar si el nuevo final truncado est\u00e1 debajo del inicio de este registro de extensi\u00f3n, lo que hace que sea seguro eliminar el registro de extensi\u00f3n completo. Sin embargo, la llamada a hfs_brec_remove() no se puede mover a su lugar anterior ya que estamos eliminando -\u0026gt;tree_lock y puede provocar una condici\u00f3n de ejecuci\u00f3n y la invalidaci\u00f3n de la informaci\u00f3n almacenada en cach\u00e9, posiblemente corrompiendo los datos del nodo. Otro tema est\u00e1 relacionado con \u00e9ste. Al ingresar al bloque (blk_cnt \u0026gt; start) no mantenemos -\u0026gt;tree_lock. Salimos del bucle sin mantener el bloqueo, pero hfs_find_exit() lo desbloquea. No estoy seguro de si es posible que otra persona tome el bloqueo bajo nuestros pies, pero puede causar errores dif\u00edciles de depurar y desbloqueo prematuro. Aunque no exista ning\u00fan riesgo real, el bloqueo siempre debe mantenerse en equilibrio. Tomando as\u00ed el candado ahora justo antes del control.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"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\":\"NVD-CWE-Other\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.19\",\"versionEndExcluding\":\"4.19.191\",\"matchCriteriaId\":\"64B18B0C-5B02-4506-ADE4-6B1430542B99\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.20\",\"versionEndExcluding\":\"5.4.120\",\"matchCriteriaId\":\"2BDC71CF-4451-4D53-93E9-61DE7C4E25B0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.38\",\"matchCriteriaId\":\"2BB4E5E8-4AAD-475A-A1B9-F287254C7D72\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.11.22\",\"matchCriteriaId\":\"83B53E9A-F426-4C03-9A5F-A931FF79827E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.12\",\"versionEndExcluding\":\"5.12.5\",\"matchCriteriaId\":\"0274929A-B36C-4F4C-AB22-30A0DD6B995B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"0CBAD0FC-C281-4666-AB2F-F8E6E1165DF7\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-04T05:24:37.918Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.5, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"NONE\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2021-46989\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-02-28T18:24:07.661826Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"description\": \"CWE-noinfo Not enough information\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-05-23T19:01:13.573Z\"}}], \"cna\": {\"title\": \"hfsplus: prevent corruption in shrinking truncate\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"52dde855663e5db824af51db39b5757d2ef3e28a\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"c451a6bafb5f422197d31536f82116aed132b72c\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"adbd8a2a8cc05d9e501f93e5c95c59307874cc99\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"c477f62db1a0c0ecaa60a29713006ceeeb04b685\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"97314e45aa1223a42d60256a62c5d9af54baf446\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"31651c607151f1034cfb57e5a78678bea54c362b\", \"lessThan\": \"c3187cf32216313fb316084efac4dab3a8459b1d\", \"versionType\": \"git\"}], \"programFiles\": [\"fs/hfsplus/extents.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.19\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"4.19\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"4.19.191\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.19.*\"}, {\"status\": \"unaffected\", \"version\": \"5.4.120\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.4.*\"}, {\"status\": \"unaffected\", \"version\": \"5.10.38\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.10.*\"}, {\"status\": \"unaffected\", \"version\": \"5.11.22\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.11.*\"}, {\"status\": \"unaffected\", \"version\": \"5.12.5\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.12.*\"}, {\"status\": \"unaffected\", \"version\": \"5.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"fs/hfsplus/extents.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a\"}, {\"url\": \"https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c\"}, {\"url\": \"https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99\"}, {\"url\": \"https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685\"}, {\"url\": \"https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446\"}, {\"url\": \"https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nhfsplus: prevent corruption in shrinking truncate\\n\\nI believe there are some issues introduced by commit 31651c607151\\n(\\\"hfsplus: avoid deadlock on file truncation\\\")\\n\\nHFS+ has extent records which always contains 8 extents.  In case the\\nfirst extent record in catalog file gets full, new ones are allocated from\\nextents overflow file.\\n\\nIn case shrinking truncate happens to middle of an extent record which\\nlocates in extents overflow file, the logic in hfsplus_file_truncate() was\\nchanged so that call to hfs_brec_remove() is not guarded any more.\\n\\nRight action would be just freeing the extents that exceed the new size\\ninside extent record by calling hfsplus_free_extents(), and then check if\\nthe whole extent record should be removed.  However since the guard\\n(blk_cnt \u003e start) is now after the call to hfs_brec_remove(), this has\\nunfortunate effect that the last matching extent record is removed\\nunconditionally.\\n\\nTo reproduce this issue, create a file which has at least 10 extents, and\\nthen perform shrinking truncate into middle of the last extent record, so\\nthat the number of remaining extents is not under or divisible by 8.  This\\ncauses the last extent record (8 extents) to be removed totally instead of\\ntruncating into middle of it.  Thus this causes corruption, and lost data.\\n\\nFix for this is simply checking if the new truncated end is below the\\nstart of this extent record, making it safe to remove the full extent\\nrecord.  However call to hfs_brec_remove() can\u0027t be moved to it\u0027s previous\\nplace since we\u0027re dropping -\u003etree_lock and it can cause a race condition\\nand the cached info being invalidated possibly corrupting the node data.\\n\\nAnother issue is related to this one.  When entering into the block\\n(blk_cnt \u003e start) we are not holding the -\u003etree_lock.  We break out from\\nthe loop not holding the lock, but hfs_find_exit() does unlock it.  Not\\nsure if it\u0027s possible for someone else to take the lock under our feet,\\nbut it can cause hard to debug errors and premature unlocking.  Even if\\nthere\u0027s no real risk of it, the locking should still always be kept in\\nbalance.  Thus taking the lock now just before the check.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.19.191\", \"versionStartIncluding\": \"4.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.4.120\", \"versionStartIncluding\": \"4.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.10.38\", \"versionStartIncluding\": \"4.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.11.22\", \"versionStartIncluding\": \"4.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.12.5\", \"versionStartIncluding\": \"4.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.13\", \"versionStartIncluding\": \"4.19\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-05-04T07:01:50.434Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2021-46989\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-05-04T07:01:50.434Z\", \"dateReserved\": \"2024-02-27T18:42:55.948Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-02-28T08:13:15.930Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


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.