{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2021-46989", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-02-27T18:42:55.948Z", "datePublished": "2024-02-28T08:13:15.930Z", "dateUpdated": "2024-11-04T16:56:31.426Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T11:57:14.377Z"}, "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 > 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't be moved to it's previous\nplace since we're dropping ->tree_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 > start) we are not holding the ->tree_lock. We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it. Not\nsure if it's 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's no real risk of it, the locking should still always be kept in\nbalance. Thus taking the lock now just before the check."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/hfsplus/extents.c"], "versions": [{"version": "31651c607151", "lessThan": "52dde855663e", "status": "affected", "versionType": "git"}, {"version": "31651c607151", "lessThan": "c451a6bafb5f", "status": "affected", "versionType": "git"}, {"version": "31651c607151", "lessThan": "adbd8a2a8cc0", "status": "affected", "versionType": "git"}, {"version": "31651c607151", "lessThan": "c477f62db1a0", "status": "affected", "versionType": "git"}, {"version": "31651c607151", "lessThan": "97314e45aa12", "status": "affected", "versionType": "git"}, {"version": "31651c607151", "lessThan": "c3187cf32216", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/hfsplus/extents.c"], "versions": [{"version": "4.19", "status": "affected"}, {"version": "0", "lessThan": "4.19", "status": "unaffected", "versionType": "semver"}, {"version": "4.19.191", "lessThanOrEqual": "4.19.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.4.120", "lessThanOrEqual": "5.4.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.38", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.11.22", "lessThanOrEqual": "5.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.12.5", "lessThanOrEqual": "5.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.13", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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-9e1c9544281a"}}, "adp": [{"problemTypes": [{"descriptions": [{"type": "CWE", "lang": "en", "description": "CWE-noinfo Not enough information"}]}], "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": {"timestamp": "2024-02-28T18:24:07.661826Z", "id": "CVE-2021-46989", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-11-04T16:56:31.426Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T05:24:37.918Z"}, "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"]}]}]}}

{"dataType": "CVE_RECORD", "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": "31651c607151", "lessThan": "52dde855663e", "versionType": "git"}, {"status": "affected", "version": "31651c607151", "lessThan": "c451a6bafb5f", "versionType": "git"}, {"status": "affected", "version": "31651c607151", "lessThan": "adbd8a2a8cc0", "versionType": "git"}, {"status": "affected", "version": "31651c607151", "lessThan": "c477f62db1a0", "versionType": "git"}, {"status": "affected", "version": "31651c607151", "lessThan": "97314e45aa12", "versionType": "git"}, {"status": "affected", "version": "31651c607151", "lessThan": "c3187cf32216", "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-9e1c9544281a"}, "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 > 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't be moved to it's previous\nplace since we're dropping ->tree_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 > start) we are not holding the ->tree_lock. We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it. Not\nsure if it's 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's no real risk of it, the locking should still always be kept in\nbalance. Thus taking the lock now just before the check."}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T11:57:14.377Z"}}}, "cveMetadata": {"cveId": "CVE-2021-46989", "state": "PUBLISHED", "dateUpdated": "2024-11-04T16:56:31.426Z", "dateReserved": "2024-02-27T18:42:55.948Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-02-28T08:13:15.930Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"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 > 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't be moved to it's previous\nplace since we're dropping ->tree_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 > start) we are not holding the ->tree_lock. We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it. Not\nsure if it's 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's 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 > 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 ->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 > start) no mantenemos ->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."}], "id": "CVE-2021-46989", "lastModified": "2024-11-04T17:35:01.073", "metrics": {"cvssMetricV31": [{"cvssData": {"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"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}]}, "published": "2024-02-28T09:15:37.687", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: hfsplus: prevent corruption in shrinking truncate", "id": "2266898", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2266898"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-229", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nhfsplus: prevent corruption in shrinking truncate\nI believe there are some issues introduced by commit 31651c607151\n(\"hfsplus: avoid deadlock on file truncation\")\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.\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.\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 > start) is now after the call to hfs_brec_remove(), this has\nunfortunate effect that the last matching extent record is removed\nunconditionally.\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.\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't be moved to it's previous\nplace since we're dropping ->tree_lock and it can cause a race condition\nand the cached info being invalidated possibly corrupting the node data.\nAnother issue is related to this one. When entering into the block\n(blk_cnt > start) we are not holding the ->tree_lock. We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it. Not\nsure if it's 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's no real risk of it, the locking should still always be kept in\nbalance. Thus taking the lock now just before the check."], "name": "CVE-2021-46989", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-02-28T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2021-46989\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-46989\nhttps://lore.kernel.org/linux-cve-announce/2024022825-CVE-2021-46989-8377@gregkh/T/#u"], "threat_severity": "Moderate", "upstream_fix": "kernel 4.19.191, kernel 5.4.120, kernel 5.10.38, kernel 5.11.22, kernel 5.12.5, kernel 5.13"}