CVE-2024-53111 (GCVE-0-2024-53111)
Vulnerability from cvelistv5
Published
2024-12-02 13:44
Modified
2026-08-05 11:43
Severity ?
7.1 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an "orig_old_start" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h> #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("first char is 0x%02hhx\n", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf("mremap() failed; first char is 0x%02hhx\n", *p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```
References
Impacted products
Vendor Product Version
Linux Linux Version: af8ca1c149069176e6322a77b532e3ffd99ccffe
Version: af8ca1c149069176e6322a77b532e3ffd99ccffe
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-53111",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-01T20:10:37.801331Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-190",
                "description": "CWE-190 Integer Overflow or Wraparound",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-01T20:17:11.230Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/mremap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "909543dc279a91122fb08e4653a72b82f0ad28f4",
              "status": "affected",
              "version": "af8ca1c149069176e6322a77b532e3ffd99ccffe",
              "versionType": "git"
            },
            {
              "lessThan": "a4a282daf1a190f03790bf163458ea3c8d28d217",
              "status": "affected",
              "version": "af8ca1c149069176e6322a77b532e3ffd99ccffe",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/mremap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.7"
            },
            {
              "lessThan": "6.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.10",
              "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": "6.11.10",
                  "versionStartIncluding": "6.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12",
                  "versionStartIncluding": "6.7",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix address wraparound in move_page_tables()\n\nOn 32-bit platforms, it is possible for the expression `len + old_addr \u003c\nold_end` to be false-positive if `len + old_addr` wraps around. \n`old_addr` is the cursor in the old range up to which page table entries\nhave been moved; so if the operation succeeded, `old_addr` is the *end* of\nthe old region, and adding `len` to it can wrap.\n\nThe overflow causes mremap() to mistakenly believe that PTEs have been\ncopied; the consequence is that mremap() bails out, but doesn\u0027t move the\nPTEs back before the new VMA is unmapped, causing anonymous pages in the\nregion to be lost.  So basically if userspace tries to mremap() a\nprivate-anon region and hits this bug, mremap() will return an error and\nthe private-anon region\u0027s contents appear to have been zeroed.\n\nThe idea of this check is that `old_end - len` is the original start\naddress, and writing the check that way also makes it easier to read; so\nfix the check by rearranging the comparison accordingly.\n\n(An alternate fix would be to refactor this function by introducing an\n\"orig_old_start\" variable or such.)\n\n\nTested in a VM with a 32-bit X86 kernel; without the patch:\n\n```\nuser@horn:~/big_mremap$ cat test.c\n#define _GNU_SOURCE\n#include \u003cstdlib.h\u003e\n#include \u003cstdio.h\u003e\n#include \u003cerr.h\u003e\n#include \u003csys/mman.h\u003e\n\n#define ADDR1 ((void*)0x60000000)\n#define ADDR2 ((void*)0x10000000)\n#define SIZE          0x50000000uL\n\nint main(void) {\n  unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE,\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\n  if (p1 == MAP_FAILED)\n    err(1, \"mmap 1\");\n  unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE,\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\n  if (p2 == MAP_FAILED)\n    err(1, \"mmap 2\");\n  *p1 = 0x41;\n  printf(\"first char is 0x%02hhx\\n\", *p1);\n  unsigned char *p3 = mremap(p1, SIZE, SIZE,\n      MREMAP_MAYMOVE|MREMAP_FIXED, p2);\n  if (p3 == MAP_FAILED) {\n    printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1);\n  } else {\n    printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3);\n  }\n}\nuser@horn:~/big_mremap$ gcc -static -o test test.c\nuser@horn:~/big_mremap$ setarch -R ./test\nfirst char is 0x41\nmremap() failed; first char is 0x00\n```\n\nWith the patch:\n\n```\nuser@horn:~/big_mremap$ setarch -R ./test\nfirst char is 0x41\nmremap() succeeded; first char is 0x41\n```"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is reached only through the `mremap()` syscall (or `execve()`\u0027s stack relocation) on the calling process\u0027s own address space, requiring local execution on the target. There is no remote or adjacent-network path into `move_page_tables()`.\nAC:L - On an affected 32-bit kernel the attacker deterministically controls every input needed \u2014 `MAP_FIXED_NOREPLACE` places a large private-anon region so that `old_end + len` exceeds 4GB, then `MREMAP_FIXED` triggers the wrap on the very first attempt, as Jann Horn\u0027s PoC demonstrates. There is no race, no memory-layout guessing, and no condition outside the attacker\u0027s control.\nPR:L - Any unprivileged local user can call `mmap()`/`mremap()`; no capability, user namespace, or elevated credential is checked anywhere along the path from `SYSCALL_DEFINE5(mremap)` to `move_page_tables()`. Only ordinary address-space limits apply, and default `RLIMIT_AS`/overcommit settings permit the ~2.5GB of virtual reservations required.\nUI:N - The attacking process triggers the wraparound entirely on its own with two `mmap()` calls and one `mremap()`; no victim action is needed. In the induced-victim variant the trigger is a background daemon\u0027s allocator, not a human interaction.\nS:U - The damage is confined to the address space of the process that issued the `mremap()` \u2014 no VM, IOMMU, or sandbox boundary is crossed, and the kernel\u0027s own memory is not corrupted. This is the standard unchanged-scope case for an mm bug.\nC:N - `move_ptes()` clears the source entries and `do_vmi_munmap()` frees the pages cleanly, so the region refaults to freshly zeroed pages \u2014 no stale kernel or cross-process data is exposed and the bug provides no read primitive of any kind. The attacker learns nothing they did not already own.\nI:H - The entire contents of a private-anon region are irrecoverably destroyed and replaced with zeroes while `mremap()` reports `-ENOMEM`, so the affected application has no indication its data was altered \u2014 a total loss of integrity for that memory. In a privileged victim (e.g. a daemon whose `realloc()` of a large mapping hits this), silently zeroed keys, ACLs, or heap metadata is a directly security-relevant corruption.\nA:H - The affected process permanently loses the contents of a multi-gigabyte mapping, and consuming that zeroed data \u2014 corrupted allocator metadata, emptied state \u2014 typically drives the application into a crash or unrecoverable malfunction. On the 32-bit embedded, industrial, and automotive systems where this bug lives, that is loss of the service; the `relocate_vma_down()` caller likewise kills the execing process on failure."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:43:49.792Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/909543dc279a91122fb08e4653a72b82f0ad28f4"
        },
        {
          "url": "https://git.kernel.org/stable/c/a4a282daf1a190f03790bf163458ea3c8d28d217"
        }
      ],
      "title": "mm/mremap: fix address wraparound in move_page_tables()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-53111",
    "datePublished": "2024-12-02T13:44:43.478Z",
    "dateReserved": "2024-11-19T17:17:24.993Z",
    "dateUpdated": "2026-08-05T11:43:49.792Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"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-53111\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-01T20:10:37.801331Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-190\", \"description\": \"CWE-190 Integer Overflow or Wraparound\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-01T15:33:56.448Z\"}}], \"cna\": {\"title\": \"mm/mremap: fix address wraparound in move_page_tables()\", \"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:N/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The bug is reached only through the `mremap()` syscall (or `execve()`\u0027s stack relocation) on the calling process\u0027s own address space, requiring local execution on the target. There is no remote or adjacent-network path into `move_page_tables()`.\\nAC:L - On an affected 32-bit kernel the attacker deterministically controls every input needed \\u2014 `MAP_FIXED_NOREPLACE` places a large private-anon region so that `old_end + len` exceeds 4GB, then `MREMAP_FIXED` triggers the wrap on the very first attempt, as Jann Horn\u0027s PoC demonstrates. There is no race, no memory-layout guessing, and no condition outside the attacker\u0027s control.\\nPR:L - Any unprivileged local user can call `mmap()`/`mremap()`; no capability, user namespace, or elevated credential is checked anywhere along the path from `SYSCALL_DEFINE5(mremap)` to `move_page_tables()`. Only ordinary address-space limits apply, and default `RLIMIT_AS`/overcommit settings permit the ~2.5GB of virtual reservations required.\\nUI:N - The attacking process triggers the wraparound entirely on its own with two `mmap()` calls and one `mremap()`; no victim action is needed. In the induced-victim variant the trigger is a background daemon\u0027s allocator, not a human interaction.\\nS:U - The damage is confined to the address space of the process that issued the `mremap()` \\u2014 no VM, IOMMU, or sandbox boundary is crossed, and the kernel\u0027s own memory is not corrupted. This is the standard unchanged-scope case for an mm bug.\\nC:N - `move_ptes()` clears the source entries and `do_vmi_munmap()` frees the pages cleanly, so the region refaults to freshly zeroed pages \\u2014 no stale kernel or cross-process data is exposed and the bug provides no read primitive of any kind. The attacker learns nothing they did not already own.\\nI:H - The entire contents of a private-anon region are irrecoverably destroyed and replaced with zeroes while `mremap()` reports `-ENOMEM`, so the affected application has no indication its data was altered \\u2014 a total loss of integrity for that memory. In a privileged victim (e.g. a daemon whose `realloc()` of a large mapping hits this), silently zeroed keys, ACLs, or heap metadata is a directly security-relevant corruption.\\nA:H - The affected process permanently loses the contents of a multi-gigabyte mapping, and consuming that zeroed data \\u2014 corrupted allocator metadata, emptied state \\u2014 typically drives the application into a crash or unrecoverable malfunction. On the 32-bit embedded, industrial, and automotive systems where this bug lives, that is loss of the service; the `relocate_vma_down()` caller likewise kills the execing process on failure.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"af8ca1c149069176e6322a77b532e3ffd99ccffe\", \"lessThan\": \"909543dc279a91122fb08e4653a72b82f0ad28f4\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"af8ca1c149069176e6322a77b532e3ffd99ccffe\", \"lessThan\": \"a4a282daf1a190f03790bf163458ea3c8d28d217\", \"versionType\": \"git\"}], \"programFiles\": [\"mm/mremap.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.7\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.7\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.11.10\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.11.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"mm/mremap.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/909543dc279a91122fb08e4653a72b82f0ad28f4\"}, {\"url\": \"https://git.kernel.org/stable/c/a4a282daf1a190f03790bf163458ea3c8d28d217\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/mremap: fix address wraparound in move_page_tables()\\n\\nOn 32-bit platforms, it is possible for the expression `len + old_addr \u003c\\nold_end` to be false-positive if `len + old_addr` wraps around. \\n`old_addr` is the cursor in the old range up to which page table entries\\nhave been moved; so if the operation succeeded, `old_addr` is the *end* of\\nthe old region, and adding `len` to it can wrap.\\n\\nThe overflow causes mremap() to mistakenly believe that PTEs have been\\ncopied; the consequence is that mremap() bails out, but doesn\u0027t move the\\nPTEs back before the new VMA is unmapped, causing anonymous pages in the\\nregion to be lost.  So basically if userspace tries to mremap() a\\nprivate-anon region and hits this bug, mremap() will return an error and\\nthe private-anon region\u0027s contents appear to have been zeroed.\\n\\nThe idea of this check is that `old_end - len` is the original start\\naddress, and writing the check that way also makes it easier to read; so\\nfix the check by rearranging the comparison accordingly.\\n\\n(An alternate fix would be to refactor this function by introducing an\\n\\\"orig_old_start\\\" variable or such.)\\n\\n\\nTested in a VM with a 32-bit X86 kernel; without the patch:\\n\\n```\\nuser@horn:~/big_mremap$ cat test.c\\n#define _GNU_SOURCE\\n#include \u003cstdlib.h\u003e\\n#include \u003cstdio.h\u003e\\n#include \u003cerr.h\u003e\\n#include \u003csys/mman.h\u003e\\n\\n#define ADDR1 ((void*)0x60000000)\\n#define ADDR2 ((void*)0x10000000)\\n#define SIZE          0x50000000uL\\n\\nint main(void) {\\n  unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE,\\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\\n  if (p1 == MAP_FAILED)\\n    err(1, \\\"mmap 1\\\");\\n  unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE,\\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\\n  if (p2 == MAP_FAILED)\\n    err(1, \\\"mmap 2\\\");\\n  *p1 = 0x41;\\n  printf(\\\"first char is 0x%02hhx\\\\n\\\", *p1);\\n  unsigned char *p3 = mremap(p1, SIZE, SIZE,\\n      MREMAP_MAYMOVE|MREMAP_FIXED, p2);\\n  if (p3 == MAP_FAILED) {\\n    printf(\\\"mremap() failed; first char is 0x%02hhx\\\\n\\\", *p1);\\n  } else {\\n    printf(\\\"mremap() succeeded; first char is 0x%02hhx\\\\n\\\", *p3);\\n  }\\n}\\nuser@horn:~/big_mremap$ gcc -static -o test test.c\\nuser@horn:~/big_mremap$ setarch -R ./test\\nfirst char is 0x41\\nmremap() failed; first char is 0x00\\n```\\n\\nWith the patch:\\n\\n```\\nuser@horn:~/big_mremap$ setarch -R ./test\\nfirst char is 0x41\\nmremap() succeeded; first char is 0x41\\n```\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.11.10\", \"versionStartIncluding\": \"6.7\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12\", \"versionStartIncluding\": \"6.7\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T11:43:49.792Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-53111\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T11:43:49.792Z\", \"dateReserved\": \"2024-11-19T17:17:24.993Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-12-02T13:44:43.478Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.