CVE-2024-50182 (GCVE-0-2024-50182)

Vulnerability from cvelistv5 – Published: 2024-11-08 05:38 – Updated: 2026-08-05 11:42
VLAI
Title
secretmem: disable memfd_secret() if arch cannot set direct map
Summary
In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
Impacted products
Vendor Product Version
Linux Linux Affected: 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 , < d0ae6ffa1aeb297aef89f49cfb894a83c329ebad (git)
Affected: 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 , < 5ea0b7af38754d2b45ead9257bca47e84662e926 (git)
Affected: 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 , < 7caf966390e6e4ebf42775df54e7ee1f280ce677 (git)
Affected: 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 , < 757786abe4547eb3d9d0e8350a63bdb0f9824af2 (git)
Affected: 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 , < 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 (git)
Create a notification for this product.
Linux Linux Affected: 5.14
Unaffected: 0 , < 5.14 (semver)
Unaffected: 5.15.169 , ≤ 5.15.* (semver)
Unaffected: 6.1.113 , ≤ 6.1.* (semver)
Unaffected: 6.6.57 , ≤ 6.6.* (semver)
Unaffected: 6.11.4 , ≤ 6.11.* (semver)
Unaffected: 6.12 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website

{
  "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-2024-50182",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-01T20:18:53.661565Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "description": "CWE-noinfo Not enough information",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-01T20:27:09.695Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T22:26:32.866Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/secretmem.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d0ae6ffa1aeb297aef89f49cfb894a83c329ebad",
              "status": "affected",
              "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49",
              "versionType": "git"
            },
            {
              "lessThan": "5ea0b7af38754d2b45ead9257bca47e84662e926",
              "status": "affected",
              "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49",
              "versionType": "git"
            },
            {
              "lessThan": "7caf966390e6e4ebf42775df54e7ee1f280ce677",
              "status": "affected",
              "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49",
              "versionType": "git"
            },
            {
              "lessThan": "757786abe4547eb3d9d0e8350a63bdb0f9824af2",
              "status": "affected",
              "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49",
              "versionType": "git"
            },
            {
              "lessThan": "532b53cebe58f34ce1c0f34d866f5c0e335c53c6",
              "status": "affected",
              "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/secretmem.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.14"
            },
            {
              "lessThan": "5.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.169",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.113",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.57",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.169",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.113",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.57",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11.4",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsecretmem: disable memfd_secret() if arch cannot set direct map\n\nReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This\nis the case for example on some arm64 configurations, where marking 4k\nPTEs in the direct map not present can only be done if the direct map is\nset up at 4k granularity in the first place (as ARM\u0027s break-before-make\nsemantics do not easily allow breaking apart large/gigantic pages).\n\nMore precisely, on arm64 systems with !can_set_direct_map(),\nset_direct_map_invalid_noflush() is a no-op, however it returns success\n(0) instead of an error.  This means that memfd_secret will seemingly\n\"work\" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),\nbut it does not actually achieve its goal of removing its memory from the\ndirect map.\n\nNote that with this patch, memfd_secret() will start erroring on systems\nwhere can_set_direct_map() returns false (arm64 with\nCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and\nCONFIG_KFENCE=n), but that still seems better than the current silent\nfailure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to \u0027y\u0027, most\narm64 systems actually have a working memfd_secret() and aren\u0027t be\naffected.\n\nFrom going through the iterations of the original memfd_secret patch\nseries, it seems that disabling the syscall in these scenarios was the\nintended behavior [1] (preferred over having\nset_direct_map_invalid_noflush return an error as that would result in\nSIGBUSes at page-fault time), however the check for it got dropped between\nv16 [2] and v17 [3], when secretmem moved away from CMA allocations.\n\n[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/\n[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t\n[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The flaw is in the `memfd_secret()` syscall path and the resulting exposure is of the kernel direct map, which requires local code execution on the affected host to observe or abuse. There is no network-facing path to secretmem.\nAC:L - On an affected arm64 system (CONFIG_RODATA_FULL_DEFAULT_ENABLED=n or the supported boot arg `rodata=on`/`rodata=off`, without debug_pagealloc or early KFENCE) the protection is unconditionally absent for every secretmem page \u2014 no race, timing window, or memory layout the attacker cannot influence is involved, and the syscall reports success every time.\nPR:L - `memfd_secret()` has no capability check and, since v6.3, is enabled by default with no boot parameter, so any unprivileged local user can create the falsely-protected mapping; abusing the retained direct-map entry likewise only needs unprivileged local execution plus a kernel read/write or transient-execution primitive.\nUI:N - No victim action is needed \u2014 the mitigation is already silently inert for every secretmem allocation on the affected system, and the attacker acts entirely on their own.\nS:U - The failed hardening and the exposed memory are both managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed by the flaw itself.\nC:H - Memory the application explicitly asked the kernel to unmap from the direct map \u2014 cryptographic keys, VMM guest secrets \u2014 remains fully mapped, so any kernel infoleak gadget or speculative/transient-execution side channel can exfiltrate arbitrary amounts of it, which is precisely the exposure memfd_secret exists to eliminate.\nI:H - The direct-map PTE stays valid *and writable* (PAGE_KERNEL RW), so the missing invalidation removes the write barrier as well as the read barrier, letting a kernel write primitive tamper with or substitute secret data that should be unreachable from kernel context.\nA:N - No crash, hang, deadlock, or resource exhaustion results \u2014 the syscall succeeds and the system continues operating normally; the only defect is the silently missing isolation guarantee."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:42:19.645Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad"
        },
        {
          "url": "https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926"
        },
        {
          "url": "https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677"
        },
        {
          "url": "https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2"
        },
        {
          "url": "https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6"
        }
      ],
      "title": "secretmem: disable memfd_secret() if arch cannot set direct map",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50182",
    "datePublished": "2024-11-08T05:38:23.528Z",
    "dateReserved": "2024-10-21T19:36:19.965Z",
    "dateUpdated": "2026-08-05T11:42:19.645Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-50182",
      "date": "2026-08-07",
      "epss": "0.00232",
      "percentile": "0.14054"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.14\", \"versionEndExcluding\": \"5.15.169\", \"matchCriteriaId\": \"ADC31A5D-676C-45DC-AA72-F69DA6922679\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.16\", \"versionEndExcluding\": \"6.1.113\", \"matchCriteriaId\": \"D01BD22E-ACD1-4618-9D01-6116570BE1EE\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.2\", \"versionEndExcluding\": \"6.6.57\", \"matchCriteriaId\": \"05D83DB8-7465-4F88-AFB2-980011992AC1\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.7\", \"versionEndExcluding\": \"6.11.4\", \"matchCriteriaId\": \"AA84D336-CE9A-4535-B901-1AD77EC17C34\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"7F361E1D-580F-4A2D-A509-7615F73167A1\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\", \"matchCriteriaId\": \"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nsecretmem: disable memfd_secret() if arch cannot set direct map\\n\\nReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This\\nis the case for example on some arm64 configurations, where marking 4k\\nPTEs in the direct map not present can only be done if the direct map is\\nset up at 4k granularity in the first place (as ARM\u0027s break-before-make\\nsemantics do not easily allow breaking apart large/gigantic pages).\\n\\nMore precisely, on arm64 systems with !can_set_direct_map(),\\nset_direct_map_invalid_noflush() is a no-op, however it returns success\\n(0) instead of an error.  This means that memfd_secret will seemingly\\n\\\"work\\\" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),\\nbut it does not actually achieve its goal of removing its memory from the\\ndirect map.\\n\\nNote that with this patch, memfd_secret() will start erroring on systems\\nwhere can_set_direct_map() returns false (arm64 with\\nCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and\\nCONFIG_KFENCE=n), but that still seems better than the current silent\\nfailure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to \u0027y\u0027, most\\narm64 systems actually have a working memfd_secret() and aren\u0027t be\\naffected.\\n\\nFrom going through the iterations of the original memfd_secret patch\\nseries, it seems that disabling the syscall in these scenarios was the\\nintended behavior [1] (preferred over having\\nset_direct_map_invalid_noflush return an error as that would result in\\nSIGBUSes at page-fault time), however the check for it got dropped between\\nv16 [2] and v17 [3], when secretmem moved away from CMA allocations.\\n\\n[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/\\n[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t\\n[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: secretmem: deshabilitar memfd_secret() si arch no puede establecer el mapa directo Devolver -ENOSYS de la llamada al sistema memfd_secret() si !can_set_direct_map(). Este es el caso, por ejemplo, de algunas configuraciones arm64, donde marcar 4k PTE en el mapa directo como no presentes solo se puede hacer si el mapa directo se configura con una granularidad de 4k en primer lugar (ya que la sem\\u00e1ntica break-before-make de ARM no permite dividir f\\u00e1cilmente p\\u00e1ginas grandes/gigantescas). M\\u00e1s precisamente, en sistemas arm64 con !can_set_direct_map(), set_direct_map_invalid_noflush() es una operaci\\u00f3n sin efecto, sin embargo, devuelve \\u00e9xito (0) en lugar de un error. Esto significa que memfd_secret aparentemente \\\"funcionar\\u00e1\\\" (por ejemplo, la llamada al sistema tiene \\u00e9xito, puede mmap el fd y el error en las p\\u00e1ginas), pero en realidad no logra su objetivo de eliminar su memoria del mapa directo. Tenga en cuenta que con este parche, memfd_secret() comenzar\\u00e1 a generar errores en sistemas donde can_set_direct_map() devuelve falso (arm64 con CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n y CONFIG_KFENCE=n), pero eso parece mejor que el error silencioso actual. Dado que CONFIG_RODATA_FULL_DEFAULT_ENABLED tiene como valor predeterminado \u0027y\u0027, la mayor\\u00eda de los sistemas arm64 tienen en realidad un memfd_secret() en funcionamiento y no se ven afectados. Al revisar las iteraciones de la serie de parches memfd_secret originales, parece que deshabilitar la llamada al sistema en estos escenarios era el comportamiento previsto [1] (preferible a que set_direct_map_invalid_noflush devuelva un error ya que eso generar\\u00eda SIGBUS en el momento de la falla de la p\\u00e1gina); sin embargo, la verificaci\\u00f3n se abandon\\u00f3 entre v16 [2] y v17 [3], cuando secretmem se alej\\u00f3 de las asignaciones de CMA. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/\"}]",
      "id": "CVE-2024-50182",
      "lastModified": "2024-11-29T20:38:47.760",
      "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-11-08T06:15:15.450",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad\", \"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\": \"NVD-CWE-noinfo\"}]}]"
    },
    "microsoft_vex": {
      "current_release_date": "2026-02-19T01:18:46.000Z",
      "cve": "CVE-2024-50182",
      "id": "msrc_CVE-2024-50182",
      "initial_release_date": "2024-11-02T00:00:00.000Z",
      "product_status:fixed": "3",
      "product_status:known_affected": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "secretmem: disable memfd_secret() if arch cannot set direct map",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-50182.json",
      "version": "2"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-50182\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-11-08T06:15:15.450\",\"lastModified\":\"2026-08-04T11:21:29.560\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nsecretmem: disable memfd_secret() if arch cannot set direct map\\n\\nReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This\\nis the case for example on some arm64 configurations, where marking 4k\\nPTEs in the direct map not present can only be done if the direct map is\\nset up at 4k granularity in the first place (as ARM\u0027s break-before-make\\nsemantics do not easily allow breaking apart large/gigantic pages).\\n\\nMore precisely, on arm64 systems with !can_set_direct_map(),\\nset_direct_map_invalid_noflush() is a no-op, however it returns success\\n(0) instead of an error.  This means that memfd_secret will seemingly\\n\\\"work\\\" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),\\nbut it does not actually achieve its goal of removing its memory from the\\ndirect map.\\n\\nNote that with this patch, memfd_secret() will start erroring on systems\\nwhere can_set_direct_map() returns false (arm64 with\\nCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and\\nCONFIG_KFENCE=n), but that still seems better than the current silent\\nfailure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to \u0027y\u0027, most\\narm64 systems actually have a working memfd_secret() and aren\u0027t be\\naffected.\\n\\nFrom going through the iterations of the original memfd_secret patch\\nseries, it seems that disabling the syscall in these scenarios was the\\nintended behavior [1] (preferred over having\\nset_direct_map_invalid_noflush return an error as that would result in\\nSIGBUSes at page-fault time), however the check for it got dropped between\\nv16 [2] and v17 [3], when secretmem moved away from CMA allocations.\\n\\n[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/\\n[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t\\n[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: secretmem: deshabilitar memfd_secret() si arch no puede establecer el mapa directo Devolver -ENOSYS de la llamada al sistema memfd_secret() si !can_set_direct_map(). Este es el caso, por ejemplo, de algunas configuraciones arm64, donde marcar 4k PTE en el mapa directo como no presentes solo se puede hacer si el mapa directo se configura con una granularidad de 4k en primer lugar (ya que la sem\u00e1ntica break-before-make de ARM no permite dividir f\u00e1cilmente p\u00e1ginas grandes/gigantescas). M\u00e1s precisamente, en sistemas arm64 con !can_set_direct_map(), set_direct_map_invalid_noflush() es una operaci\u00f3n sin efecto, sin embargo, devuelve \u00e9xito (0) en lugar de un error. Esto significa que memfd_secret aparentemente \\\"funcionar\u00e1\\\" (por ejemplo, la llamada al sistema tiene \u00e9xito, puede mmap el fd y el error en las p\u00e1ginas), pero en realidad no logra su objetivo de eliminar su memoria del mapa directo. Tenga en cuenta que con este parche, memfd_secret() comenzar\u00e1 a generar errores en sistemas donde can_set_direct_map() devuelve falso (arm64 con CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n y CONFIG_KFENCE=n), pero eso parece mejor que el error silencioso actual. Dado que CONFIG_RODATA_FULL_DEFAULT_ENABLED tiene como valor predeterminado \u0027y\u0027, la mayor\u00eda de los sistemas arm64 tienen en realidad un memfd_secret() en funcionamiento y no se ven afectados. Al revisar las iteraciones de la serie de parches memfd_secret originales, parece que deshabilitar la llamada al sistema en estos escenarios era el comportamiento previsto [1] (preferible a que set_direct_map_invalid_noflush devuelva un error ya que eso generar\u00eda SIGBUS en el momento de la falla de la p\u00e1gina); sin embargo, la verificaci\u00f3n se abandon\u00f3 entre v16 [2] y v17 [3], cuando secretmem se alej\u00f3 de las asignaciones de CMA. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"mm/secretmem.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\",\"lessThan\":\"d0ae6ffa1aeb297aef89f49cfb894a83c329ebad\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\",\"lessThan\":\"5ea0b7af38754d2b45ead9257bca47e84662e926\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\",\"lessThan\":\"7caf966390e6e4ebf42775df54e7ee1f280ce677\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\",\"lessThan\":\"757786abe4547eb3d9d0e8350a63bdb0f9824af2\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\",\"lessThan\":\"532b53cebe58f34ce1c0f34d866f5c0e335c53c6\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"mm/secretmem.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.14\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.14\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.169\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.113\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.57\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.11.4\",\"lessThanOrEqual\":\"6.11.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.8,\"impactScore\":5.2},{\"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},{\"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}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2025-10-01T20:18:53.661565Z\",\"id\":\"CVE-2024-50182\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.14\",\"versionEndExcluding\":\"5.15.169\",\"matchCriteriaId\":\"ADC31A5D-676C-45DC-AA72-F69DA6922679\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.113\",\"matchCriteriaId\":\"D01BD22E-ACD1-4618-9D01-6116570BE1EE\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.57\",\"matchCriteriaId\":\"05D83DB8-7465-4F88-AFB2-980011992AC1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.11.4\",\"matchCriteriaId\":\"AA84D336-CE9A-4535-B901-1AD77EC17C34\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-06-28T08:08:57+00:00",
      "cve": "CVE-2024-50182",
      "id": "CVE-2024-50182",
      "initial_release_date": "2024-11-08T00:00:00+00:00",
      "product_status:fixed": "305",
      "product_status:known_affected": "22",
      "product_status:known_not_affected": "90",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: secretmem: disable memfd_secret() if arch cannot set direct map",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-50182.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-07-25T01:26:57Z",
      "cve": "CVE-2024-50182",
      "id": "CVE-2024-50182",
      "initial_release_date": "2024-11-09T03:49:10Z",
      "product_status:known_affected": "426",
      "product_status:known_not_affected": "224",
      "product_status:recommended": "628",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-50182",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-50182.json",
      "version": "57"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html\"}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2025-11-03T22:26:32.866Z\"}}, {\"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-2024-50182\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-01T20:18:53.661565Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"description\": \"CWE-noinfo Not enough information\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-01T15:20:14.187Z\"}}], \"cna\": {\"title\": \"secretmem: disable memfd_secret() if arch cannot set direct map\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 7.1, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The flaw is in the `memfd_secret()` syscall path and the resulting exposure is of the kernel direct map, which requires local code execution on the affected host to observe or abuse. There is no network-facing path to secretmem.\\nAC:L - On an affected arm64 system (CONFIG_RODATA_FULL_DEFAULT_ENABLED=n or the supported boot arg `rodata=on`/`rodata=off`, without debug_pagealloc or early KFENCE) the protection is unconditionally absent for every secretmem page \\u2014 no race, timing window, or memory layout the attacker cannot influence is involved, and the syscall reports success every time.\\nPR:L - `memfd_secret()` has no capability check and, since v6.3, is enabled by default with no boot parameter, so any unprivileged local user can create the falsely-protected mapping; abusing the retained direct-map entry likewise only needs unprivileged local execution plus a kernel read/write or transient-execution primitive.\\nUI:N - No victim action is needed \\u2014 the mitigation is already silently inert for every secretmem allocation on the affected system, and the attacker acts entirely on their own.\\nS:U - The failed hardening and the exposed memory are both managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed by the flaw itself.\\nC:H - Memory the application explicitly asked the kernel to unmap from the direct map \\u2014 cryptographic keys, VMM guest secrets \\u2014 remains fully mapped, so any kernel infoleak gadget or speculative/transient-execution side channel can exfiltrate arbitrary amounts of it, which is precisely the exposure memfd_secret exists to eliminate.\\nI:H - The direct-map PTE stays valid *and writable* (PAGE_KERNEL RW), so the missing invalidation removes the write barrier as well as the read barrier, letting a kernel write primitive tamper with or substitute secret data that should be unreachable from kernel context.\\nA:N - No crash, hang, deadlock, or resource exhaustion results \\u2014 the syscall succeeds and the system continues operating normally; the only defect is the silently missing isolation guarantee.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\", \"lessThan\": \"d0ae6ffa1aeb297aef89f49cfb894a83c329ebad\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\", \"lessThan\": \"5ea0b7af38754d2b45ead9257bca47e84662e926\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\", \"lessThan\": \"7caf966390e6e4ebf42775df54e7ee1f280ce677\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\", \"lessThan\": \"757786abe4547eb3d9d0e8350a63bdb0f9824af2\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49\", \"lessThan\": \"532b53cebe58f34ce1c0f34d866f5c0e335c53c6\", \"versionType\": \"git\"}], \"programFiles\": [\"mm/secretmem.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.14\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.14\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.15.169\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1.113\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6.57\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.11.4\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.11.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"mm/secretmem.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad\"}, {\"url\": \"https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926\"}, {\"url\": \"https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677\"}, {\"url\": \"https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2\"}, {\"url\": \"https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nsecretmem: disable memfd_secret() if arch cannot set direct map\\n\\nReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This\\nis the case for example on some arm64 configurations, where marking 4k\\nPTEs in the direct map not present can only be done if the direct map is\\nset up at 4k granularity in the first place (as ARM\u0027s break-before-make\\nsemantics do not easily allow breaking apart large/gigantic pages).\\n\\nMore precisely, on arm64 systems with !can_set_direct_map(),\\nset_direct_map_invalid_noflush() is a no-op, however it returns success\\n(0) instead of an error.  This means that memfd_secret will seemingly\\n\\\"work\\\" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),\\nbut it does not actually achieve its goal of removing its memory from the\\ndirect map.\\n\\nNote that with this patch, memfd_secret() will start erroring on systems\\nwhere can_set_direct_map() returns false (arm64 with\\nCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and\\nCONFIG_KFENCE=n), but that still seems better than the current silent\\nfailure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to \u0027y\u0027, most\\narm64 systems actually have a working memfd_secret() and aren\u0027t be\\naffected.\\n\\nFrom going through the iterations of the original memfd_secret patch\\nseries, it seems that disabling the syscall in these scenarios was the\\nintended behavior [1] (preferred over having\\nset_direct_map_invalid_noflush return an error as that would result in\\nSIGBUSes at page-fault time), however the check for it got dropped between\\nv16 [2] and v17 [3], when secretmem moved away from CMA allocations.\\n\\n[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/\\n[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t\\n[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.169\", \"versionStartIncluding\": \"5.14\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.113\", \"versionStartIncluding\": \"5.14\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.57\", \"versionStartIncluding\": \"5.14\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.11.4\", \"versionStartIncluding\": \"5.14\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12\", \"versionStartIncluding\": \"5.14\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T11:42:19.645Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-50182\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T11:42:19.645Z\", \"dateReserved\": \"2024-10-21T19:36:19.965Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-11-08T05:38:23.528Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…