CVE-2024-45024 (GCVE-0-2024-45024)

Vulnerability from cvelistv5 – Published: 2024-09-11 15:13 – Updated: 2026-05-11 20:33
VLAI?
Title
mm/hugetlb: fix hugetlb vs. core-mm PT locking
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb vs. core-mm PT locking We recently made GUP's common page table walking code to also walk hugetlb VMAs without most hugetlb special-casing, preparing for the future of having less hugetlb-specific page table walking code in the codebase. Turns out that we missed one page table locking detail: page table locking for hugetlb folios that are not mapped using a single PMD/PUD. Assume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB hugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks the page tables, will perform a pte_offset_map_lock() to grab the PTE table lock. However, hugetlb that concurrently modifies these page tables would actually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the locks would differ. Something similar can happen right now with hugetlb folios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS. This issue can be reproduced [1], for example triggering: [ 3105.936100] ------------[ cut here ]------------ [ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] Modules linked in: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0 [ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Call trace: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Let's make huge_pte_lockptr() effectively use the same PT locks as any core-mm page table walker would. Add ptep_lockptr() to obtain the PTE page table lock using a pte pointer -- unfortunately we cannot convert pte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables we can have with CONFIG_HIGHPTE. Handle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such that when e.g., CONFIG_PGTABLE_LEVELS==2 with PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected. Document why that works. There is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb folio being mapped using two PTE page tables. While hugetlb wants to take the PMD table lock, core-mm would grab the PTE table lock of one of both PTE page tables. In such corner cases, we have to make sure that both locks match, which is (fortunately!) currently guaranteed for 8xx as it does not support SMP and consequently doesn't use split PT locks. [1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/
Severity ?
No CVSS data available.
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < 7300dadba49e531af2d890ae4e34c9b115384a62 (git)
Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < 5f75cfbd6bb02295ddaed48adf667b6c828ce07b (git)
Create a notification for this product.
Linux Linux Affected: 6.10
Unaffected: 0 , < 6.10 (semver)
Unaffected: 6.10.7 , ≤ 6.10.* (semver)
Unaffected: 6.11 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-45024",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-29T15:47:11.835460Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-29T15:47:26.113Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/linux/hugetlb.h",
            "include/linux/mm.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "7300dadba49e531af2d890ae4e34c9b115384a62",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "5f75cfbd6bb02295ddaed48adf667b6c828ce07b",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/linux/hugetlb.h",
            "include/linux/mm.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "lessThan": "6.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.7",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\n\nWe recently made GUP\u0027s common page table walking code to also walk hugetlb\nVMAs without most hugetlb special-casing, preparing for the future of\nhaving less hugetlb-specific page table walking code in the codebase. \nTurns out that we missed one page table locking detail: page table locking\nfor hugetlb folios that are not mapped using a single PMD/PUD.\n\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\nlock.\n\nHowever, hugetlb that concurrently modifies these page tables would\nactually grab the mm-\u003epage_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\nlocks would differ.  Something similar can happen right now with hugetlb\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\n\nThis issue can be reproduced [1], for example triggering:\n\n[ 3105.936100] ------------[ cut here ]------------\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\n[ 3105.944634] Modules linked in: [...]\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\n[ 3105.996986] sp : ffff80008eafb8f0\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\n[ 3106.047957] Call trace:\n[ 3106.049522]  try_grab_folio+0x11c/0x188\n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8\n[ 3106.058118]  __get_user_pages+0xf0/0x348\n[ 3106.060647]  faultin_page_range+0xb0/0x360\n[ 3106.063651]  do_madvise+0x340/0x598\n\nLet\u0027s make huge_pte_lockptr() effectively use the same PT locks as any\ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE\npage table lock using a pte pointer -- unfortunately we cannot convert\npte_lockptr() because virt_to_page() doesn\u0027t work with kmap\u0027ed page tables\nwe can have with CONFIG_HIGHPTE.\n\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document\nwhy that works.\n\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\nfolio being mapped using two PTE page tables.  While hugetlb wants to take\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\nPTE page tables.  In such corner cases, we have to make sure that both\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\ndoes not support SMP and consequently doesn\u0027t use split PT locks.\n\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:33:59.625Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62"
        },
        {
          "url": "https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b"
        }
      ],
      "title": "mm/hugetlb: fix hugetlb vs. core-mm PT locking",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-45024",
    "datePublished": "2024-09-11T15:13:57.076Z",
    "dateReserved": "2024-08-21T05:34:56.684Z",
    "dateUpdated": "2026-05-11T20:33:59.625Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-45024",
      "date": "2026-05-20",
      "epss": "0.00026",
      "percentile": "0.07346"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.10\", \"versionEndExcluding\": \"6.10.7\", \"matchCriteriaId\": \"E55C1263-DF43-41EF-8DA8-2BA68DF4FFFD\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"8B3CE743-2126-47A3-8B7C-822B502CF119\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*\", \"matchCriteriaId\": \"4DEB27E7-30AA-45CC-8934-B89263EF3551\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:*\", \"matchCriteriaId\": \"E0005AEF-856E-47EB-BFE4-90C46899394D\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\\n\\nWe recently made GUP\u0027s common page table walking code to also walk hugetlb\\nVMAs without most hugetlb special-casing, preparing for the future of\\nhaving less hugetlb-specific page table walking code in the codebase. \\nTurns out that we missed one page table locking detail: page table locking\\nfor hugetlb folios that are not mapped using a single PMD/PUD.\\n\\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\\nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the\\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\\nlock.\\n\\nHowever, hugetlb that concurrently modifies these page tables would\\nactually grab the mm-\u003epage_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\\nlocks would differ.  Something similar can happen right now with hugetlb\\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\\n\\nThis issue can be reproduced [1], for example triggering:\\n\\n[ 3105.936100] ------------[ cut here ]------------\\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\\n[ 3105.944634] Modules linked in: [...]\\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\\n[ 3105.996986] sp : ffff80008eafb8f0\\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\\n[ 3106.047957] Call trace:\\n[ 3106.049522]  try_grab_folio+0x11c/0x188\\n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\\n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8\\n[ 3106.058118]  __get_user_pages+0xf0/0x348\\n[ 3106.060647]  faultin_page_range+0xb0/0x360\\n[ 3106.063651]  do_madvise+0x340/0x598\\n\\nLet\u0027s make huge_pte_lockptr() effectively use the same PT locks as any\\ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE\\npage table lock using a pte pointer -- unfortunately we cannot convert\\npte_lockptr() because virt_to_page() doesn\u0027t work with kmap\u0027ed page tables\\nwe can have with CONFIG_HIGHPTE.\\n\\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document\\nwhy that works.\\n\\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\\nfolio being mapped using two PTE page tables.  While hugetlb wants to take\\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\\nPTE page tables.  In such corner cases, we have to make sure that both\\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\\ndoes not support SMP and consequently doesn\u0027t use split PT locks.\\n\\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: correcci\\u00f3n del bloqueo de PT de hugetlb frente a core-mm Recientemente hicimos que el c\\u00f3digo de recorrido de tabla de p\\u00e1ginas com\\u00fan de GUP tambi\\u00e9n recorriera VMA hugetlb sin la mayor\\u00eda de las may\\u00fasculas y min\\u00fasculas especiales de hugetlb, prepar\\u00e1ndonos para el futuro de tener menos c\\u00f3digo de recorrido de tabla de p\\u00e1ginas espec\\u00edfico de hugetlb en la base de c\\u00f3digo. Resulta que nos perdimos un detalle de bloqueo de tabla de p\\u00e1ginas: el bloqueo de tabla de p\\u00e1ginas para folios hugetlb que no est\\u00e1n mapeados usando un solo PMD/PUD. Supongamos que tenemos un folio hugetlb que abarca m\\u00faltiples PTE (por ejemplo, folios hugetlb de 64 KiB en arm64 con un tama\\u00f1o de p\\u00e1gina base de 4 KiB). GUP, mientras recorre las tablas de p\\u00e1ginas, realizar\\u00e1 un pte_offset_map_lock() para agarrar el bloqueo de tabla PTE. Sin embargo, hugetlb que modifica simult\\u00e1neamente estas tablas de p\\u00e1ginas en realidad agarrar\\u00eda el mm-\u0026gt;page_table_lock: con USE_SPLIT_PTE_PTLOCKS, los bloqueos ser\\u00edan diferentes. Algo similar puede suceder ahora mismo con folios hugetlb que abarcan m\\u00faltiples PMD cuando USE_SPLIT_PMD_PTLOCKS. Este problema se puede reproducir [1], por ejemplo, activando: [ 3105.936100] ------------[ cortar aqu\\u00ed ]------------ [ 3105.939323] ADVERTENCIA: CPU: 31 PID: 2732 en mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] M\\u00f3dulos vinculados en: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer No contaminado 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 24/05/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 00000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9: ffffb854771b12f0 [ 3106.034324] x8: 000800000000000 x7: ffff7a546c1aa980 x6: 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Rastreo de llamadas: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Hagamos que huge_pte_lockptr() use efectivamente los mismos bloqueos PT que cualquier rastreador de tablas de p\\u00e1ginas core-mm har\\u00eda. Agregue ptep_lockptr() para obtener el bloqueo de la tabla de p\\u00e1ginas PTE usando un puntero pte - desafortunadamente no podemos convertir pte_lockptr() porque virt_to_page() no funciona con tablas de p\\u00e1ginas kmap\u0027ed que podemos tener con CONFIG_HIGHPTE. Maneje CONFIG_PGTABLE_LEVELS correctamente verificando en orden inverso, de modo que cuando, por ejemplo, CONFIG_PGTABLE_LEVELS==2 con PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE funcionar\\u00e1 como se espera. Documente por qu\\u00e9 funciona eso. Hay un caso desagradable: powerpc 8xx, en el que tenemos un folio hugetlb de 8 MiB que se asigna utilizando dos tablas de p\\u00e1ginas PTE. Mientras hugetlb quiere tomar el bloqueo de la tabla PMD, core-mm tomar\\u00eda el bloqueo de la tabla PTE de una de ambas tablas de p\\u00e1ginas PTE. En tales casos extremos, tenemos que asegurarnos de que ambos bloqueos coincidan, lo que (\\u00a1afortunadamente!) --- truncado ----\"}]",
      "id": "CVE-2024-45024",
      "lastModified": "2024-09-13T16:30:17.277",
      "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}]}",
      "published": "2024-09-11T16:15:07.290",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-667\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-45024\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-09-11T16:15:07.290\",\"lastModified\":\"2024-09-13T16:30:17.277\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\\n\\nWe recently made GUP\u0027s common page table walking code to also walk hugetlb\\nVMAs without most hugetlb special-casing, preparing for the future of\\nhaving less hugetlb-specific page table walking code in the codebase. \\nTurns out that we missed one page table locking detail: page table locking\\nfor hugetlb folios that are not mapped using a single PMD/PUD.\\n\\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\\nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the\\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\\nlock.\\n\\nHowever, hugetlb that concurrently modifies these page tables would\\nactually grab the mm-\u003epage_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\\nlocks would differ.  Something similar can happen right now with hugetlb\\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\\n\\nThis issue can be reproduced [1], for example triggering:\\n\\n[ 3105.936100] ------------[ cut here ]------------\\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\\n[ 3105.944634] Modules linked in: [...]\\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\\n[ 3105.996986] sp : ffff80008eafb8f0\\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\\n[ 3106.047957] Call trace:\\n[ 3106.049522]  try_grab_folio+0x11c/0x188\\n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\\n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8\\n[ 3106.058118]  __get_user_pages+0xf0/0x348\\n[ 3106.060647]  faultin_page_range+0xb0/0x360\\n[ 3106.063651]  do_madvise+0x340/0x598\\n\\nLet\u0027s make huge_pte_lockptr() effectively use the same PT locks as any\\ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE\\npage table lock using a pte pointer -- unfortunately we cannot convert\\npte_lockptr() because virt_to_page() doesn\u0027t work with kmap\u0027ed page tables\\nwe can have with CONFIG_HIGHPTE.\\n\\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document\\nwhy that works.\\n\\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\\nfolio being mapped using two PTE page tables.  While hugetlb wants to take\\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\\nPTE page tables.  In such corner cases, we have to make sure that both\\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\\ndoes not support SMP and consequently doesn\u0027t use split PT locks.\\n\\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: correcci\u00f3n del bloqueo de PT de hugetlb frente a core-mm Recientemente hicimos que el c\u00f3digo de recorrido de tabla de p\u00e1ginas com\u00fan de GUP tambi\u00e9n recorriera VMA hugetlb sin la mayor\u00eda de las may\u00fasculas y min\u00fasculas especiales de hugetlb, prepar\u00e1ndonos para el futuro de tener menos c\u00f3digo de recorrido de tabla de p\u00e1ginas espec\u00edfico de hugetlb en la base de c\u00f3digo. Resulta que nos perdimos un detalle de bloqueo de tabla de p\u00e1ginas: el bloqueo de tabla de p\u00e1ginas para folios hugetlb que no est\u00e1n mapeados usando un solo PMD/PUD. Supongamos que tenemos un folio hugetlb que abarca m\u00faltiples PTE (por ejemplo, folios hugetlb de 64 KiB en arm64 con un tama\u00f1o de p\u00e1gina base de 4 KiB). GUP, mientras recorre las tablas de p\u00e1ginas, realizar\u00e1 un pte_offset_map_lock() para agarrar el bloqueo de tabla PTE. Sin embargo, hugetlb que modifica simult\u00e1neamente estas tablas de p\u00e1ginas en realidad agarrar\u00eda el mm-\u0026gt;page_table_lock: con USE_SPLIT_PTE_PTLOCKS, los bloqueos ser\u00edan diferentes. Algo similar puede suceder ahora mismo con folios hugetlb que abarcan m\u00faltiples PMD cuando USE_SPLIT_PMD_PTLOCKS. Este problema se puede reproducir [1], por ejemplo, activando: [ 3105.936100] ------------[ cortar aqu\u00ed ]------------ [ 3105.939323] ADVERTENCIA: CPU: 31 PID: 2732 en mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] M\u00f3dulos vinculados en: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer No contaminado 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 24/05/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 00000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9: ffffb854771b12f0 [ 3106.034324] x8: 000800000000000 x7: ffff7a546c1aa980 x6: 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Rastreo de llamadas: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Hagamos que huge_pte_lockptr() use efectivamente los mismos bloqueos PT que cualquier rastreador de tablas de p\u00e1ginas core-mm har\u00eda. Agregue ptep_lockptr() para obtener el bloqueo de la tabla de p\u00e1ginas PTE usando un puntero pte - desafortunadamente no podemos convertir pte_lockptr() porque virt_to_page() no funciona con tablas de p\u00e1ginas kmap\u0027ed que podemos tener con CONFIG_HIGHPTE. Maneje CONFIG_PGTABLE_LEVELS correctamente verificando en orden inverso, de modo que cuando, por ejemplo, CONFIG_PGTABLE_LEVELS==2 con PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE funcionar\u00e1 como se espera. Documente por qu\u00e9 funciona eso. Hay un caso desagradable: powerpc 8xx, en el que tenemos un folio hugetlb de 8 MiB que se asigna utilizando dos tablas de p\u00e1ginas PTE. Mientras hugetlb quiere tomar el bloqueo de la tabla PMD, core-mm tomar\u00eda el bloqueo de la tabla PTE de una de ambas tablas de p\u00e1ginas PTE. En tales casos extremos, tenemos que asegurarnos de que ambos bloqueos coincidan, lo que (\u00a1afortunadamente!) --- truncado ----\"}],\"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-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.10\",\"versionEndExcluding\":\"6.10.7\",\"matchCriteriaId\":\"E55C1263-DF43-41EF-8DA8-2BA68DF4FFFD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"8B3CE743-2126-47A3-8B7C-822B502CF119\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"4DEB27E7-30AA-45CC-8934-B89263EF3551\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"E0005AEF-856E-47EB-BFE4-90C46899394D\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-45024\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-29T15:47:11.835460Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-29T15:47:15.951Z\"}}], \"cna\": {\"title\": \"mm/hugetlb: fix hugetlb vs. core-mm PT locking\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"9cb28da54643\", \"lessThan\": \"7300dadba49e\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"9cb28da54643\", \"lessThan\": \"5f75cfbd6bb0\", \"versionType\": \"git\"}], \"programFiles\": [\"include/linux/hugetlb.h\", \"include/linux/mm.h\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.10\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.10\", \"versionType\": \"custom\"}, {\"status\": \"unaffected\", \"version\": \"6.10.7\", \"versionType\": \"custom\", \"lessThanOrEqual\": \"6.10.*\"}, {\"status\": \"unaffected\", \"version\": \"6.11\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"include/linux/hugetlb.h\", \"include/linux/mm.h\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62\"}, {\"url\": \"https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b\"}], \"x_generator\": {\"engine\": \"bippy-c9c4e1df01b2\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\\n\\nWe recently made GUP\u0027s common page table walking code to also walk hugetlb\\nVMAs without most hugetlb special-casing, preparing for the future of\\nhaving less hugetlb-specific page table walking code in the codebase. \\nTurns out that we missed one page table locking detail: page table locking\\nfor hugetlb folios that are not mapped using a single PMD/PUD.\\n\\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\\nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the\\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\\nlock.\\n\\nHowever, hugetlb that concurrently modifies these page tables would\\nactually grab the mm-\u003epage_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\\nlocks would differ.  Something similar can happen right now with hugetlb\\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\\n\\nThis issue can be reproduced [1], for example triggering:\\n\\n[ 3105.936100] ------------[ cut here ]------------\\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\\n[ 3105.944634] Modules linked in: [...]\\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\\n[ 3105.996986] sp : ffff80008eafb8f0\\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\\n[ 3106.047957] Call trace:\\n[ 3106.049522]  try_grab_folio+0x11c/0x188\\n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\\n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8\\n[ 3106.058118]  __get_user_pages+0xf0/0x348\\n[ 3106.060647]  faultin_page_range+0xb0/0x360\\n[ 3106.063651]  do_madvise+0x340/0x598\\n\\nLet\u0027s make huge_pte_lockptr() effectively use the same PT locks as any\\ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE\\npage table lock using a pte pointer -- unfortunately we cannot convert\\npte_lockptr() because virt_to_page() doesn\u0027t work with kmap\u0027ed page tables\\nwe can have with CONFIG_HIGHPTE.\\n\\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document\\nwhy that works.\\n\\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\\nfolio being mapped using two PTE page tables.  While hugetlb wants to take\\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\\nPTE page tables.  In such corner cases, we have to make sure that both\\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\\ndoes not support SMP and consequently doesn\u0027t use split PT locks.\\n\\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2024-09-15T17:57:13.423Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-45024\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-09-29T15:47:26.113Z\", \"dateReserved\": \"2024-08-21T05:34:56.684Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-09-11T15:13:57.076Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.