CVE-2023-54157 (GCVE-0-2023-54157)

Vulnerability from cvelistv5 – Published: 2025-12-24 13:07 – Updated: 2026-08-05 09:17
VLAI
Title
binder: fix UAF of alloc->vma in race with munmap()
Summary
In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of alloc->vma in race with munmap() [ cmllamas: clean forward port from commit 015ac18be7de ("binder: fix UAF of alloc->vma in race with munmap()") in 5.10 stable. It is needed in mainline after the revert of commit a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") as pointed out by Liam. The commit log and tags have been tweaked to reflect this. ] In commit 720c24192404 ("ANDROID: binder: change down_write to down_read") binder assumed the mmap read lock is sufficient to protect alloc->vma inside binder_update_page_range(). This used to be accurate until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"), which now downgrades the mmap_lock after detaching the vma from the rbtree in munmap(). Then it proceeds to teardown and free the vma with only the read lock held. This means that accesses to alloc->vma in binder_update_page_range() now will race with vm_area_free() in munmap() and can cause a UAF as shown in the following KASAN trace: ================================================================== BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560: kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ================================================================== To prevent the race above, revert back to taking the mmap write lock inside binder_update_page_range(). One might expect an increase of mmap lock contention. However, binder already serializes these calls via top level alloc->mutex. Also, there was no performance impact shown when running the binder benchmark tests.
Assigner
Impacted products
Vendor Product Version
Linux Linux Affected: dd2283f2605e3b3e9c61bcae844b34f2afa4813f , < 1bb8a65190d45cd5c7dbc85e29b9102110cd6be6 (git)
Affected: dd2283f2605e3b3e9c61bcae844b34f2afa4813f , < 931ea1ed31be939c1efdbc49bc66d2a45684f9b4 (git)
Affected: dd2283f2605e3b3e9c61bcae844b34f2afa4813f , < ca0cc0a9c6e56c699e2acbb93d8024523021f3c3 (git)
Affected: dd2283f2605e3b3e9c61bcae844b34f2afa4813f , < d1d8875c8c13517f6fd1ff8d4d3e1ac366a17e07 (git)
Create a notification for this product.
Linux Linux Affected: 4.20
Unaffected: 0 , < 4.20 (semver)
Unaffected: 5.15.115 , ≤ 5.15.* (semver)
Unaffected: 6.1.31 , ≤ 6.1.* (semver)
Unaffected: 6.3.5 , ≤ 6.3.* (semver)
Unaffected: 6.4 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/android/binder_alloc.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1bb8a65190d45cd5c7dbc85e29b9102110cd6be6",
              "status": "affected",
              "version": "dd2283f2605e3b3e9c61bcae844b34f2afa4813f",
              "versionType": "git"
            },
            {
              "lessThan": "931ea1ed31be939c1efdbc49bc66d2a45684f9b4",
              "status": "affected",
              "version": "dd2283f2605e3b3e9c61bcae844b34f2afa4813f",
              "versionType": "git"
            },
            {
              "lessThan": "ca0cc0a9c6e56c699e2acbb93d8024523021f3c3",
              "status": "affected",
              "version": "dd2283f2605e3b3e9c61bcae844b34f2afa4813f",
              "versionType": "git"
            },
            {
              "lessThan": "d1d8875c8c13517f6fd1ff8d4d3e1ac366a17e07",
              "status": "affected",
              "version": "dd2283f2605e3b3e9c61bcae844b34f2afa4813f",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/android/binder_alloc.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.20"
            },
            {
              "lessThan": "4.20",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.115",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.31",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.3.*",
              "status": "unaffected",
              "version": "6.3.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.4",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.115",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.31",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.3.5",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.4",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF of alloc-\u003evma in race with munmap()\n\n[ cmllamas: clean forward port from commit 015ac18be7de (\"binder: fix\n  UAF of alloc-\u003evma in race with munmap()\") in 5.10 stable. It is needed\n  in mainline after the revert of commit a43cfc87caaf (\"android: binder:\n  stop saving a pointer to the VMA\") as pointed out by Liam. The commit\n  log and tags have been tweaked to reflect this. ]\n\nIn commit 720c24192404 (\"ANDROID: binder: change down_write to\ndown_read\") binder assumed the mmap read lock is sufficient to protect\nalloc-\u003evma inside binder_update_page_range(). This used to be accurate\nuntil commit dd2283f2605e (\"mm: mmap: zap pages with read mmap_sem in\nmunmap\"), which now downgrades the mmap_lock after detaching the vma\nfrom the rbtree in munmap(). Then it proceeds to teardown and free the\nvma with only the read lock held.\n\nThis means that accesses to alloc-\u003evma in binder_update_page_range() now\nwill race with vm_area_free() in munmap() and can cause a UAF as shown\nin the following KASAN trace:\n\n  ==================================================================\n  BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0\n  Read of size 8 at addr ffff16204ad00600 by task server/558\n\n  CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   dump_backtrace+0x0/0x2a0\n   show_stack+0x18/0x2c\n   dump_stack+0xf8/0x164\n   print_address_description.constprop.0+0x9c/0x538\n   kasan_report+0x120/0x200\n   __asan_load8+0xa0/0xc4\n   vm_insert_page+0x7c/0x1f0\n   binder_update_page_range+0x278/0x50c\n   binder_alloc_new_buf+0x3f0/0xba0\n   binder_transaction+0x64c/0x3040\n   binder_thread_write+0x924/0x2020\n   binder_ioctl+0x1610/0x2e5c\n   __arm64_sys_ioctl+0xd4/0x120\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  Allocated by task 559:\n   kasan_save_stack+0x38/0x6c\n   __kasan_kmalloc.constprop.0+0xe4/0xf0\n   kasan_slab_alloc+0x18/0x2c\n   kmem_cache_alloc+0x1b0/0x2d0\n   vm_area_alloc+0x28/0x94\n   mmap_region+0x378/0x920\n   do_mmap+0x3f0/0x600\n   vm_mmap_pgoff+0x150/0x17c\n   ksys_mmap_pgoff+0x284/0x2dc\n   __arm64_sys_mmap+0x84/0xa4\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  Freed by task 560:\n   kasan_save_stack+0x38/0x6c\n   kasan_set_track+0x28/0x40\n   kasan_set_free_info+0x24/0x4c\n   __kasan_slab_free+0x100/0x164\n   kasan_slab_free+0x14/0x20\n   kmem_cache_free+0xc4/0x34c\n   vm_area_free+0x1c/0x2c\n   remove_vma+0x7c/0x94\n   __do_munmap+0x358/0x710\n   __vm_munmap+0xbc/0x130\n   __arm64_sys_munmap+0x4c/0x64\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  [...]\n  ==================================================================\n\nTo prevent the race above, revert back to taking the mmap write lock\ninside binder_update_page_range(). One might expect an increase of mmap\nlock contention. However, binder already serializes these calls via top\nlevel alloc-\u003emutex. Also, there was no performance impact shown when\nrunning the binder benchmark tests."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The vulnerability is reached only through local syscalls \u2014 `mmap()`, `munmap()`, and `ioctl(BINDER_WRITE_READ)` on an opened `/dev/binder` (or binderfs) character device. There is no remote or adjacent-network path into `binder_update_page_range()`.\nAC:L - The attacker controls both sides of the race entirely within their own process: one thread issues the BC_TRANSACTION ioctl while a second thread calls `munmap()` on the binder mapping. The window is further widened by the sleepable `alloc_page(GFP_KERNEL)` that executes between the `alloc-\u003evma` load and the `vm_insert_page()` dereference, and the attempt is freely repeatable.\nPR:L - No capability check exists anywhere on the path \u2014 binder.c contains no `capable()`/`CAP_*` gate reaching `binder_alloc_new_buf()`. An ordinary Android app (`untrusted_app`) may open `/dev/binder`, and on generic kernels binderfs is `FS_USERNS_MOUNT` (binderfs.c:796), so an unprivileged user can `unshare -Ur`, mount binderfs, and create a 0600 binder device they own via `BINDER_CTL_ADD`.\nUI:N - The attacker performs every step \u2014 open, mmap, transaction ioctl, and munmap \u2014 from their own process with no victim action required.\nS:U - The corruption occurs in kernel memory and yields local privilege escalation within the same security authority; no VM, IOMMU, or sandbox boundary is crossed by the flaw itself.\nC:H - This is a use-after-free of a `struct vm_area_struct` from the global `vm_area_cachep`, which an attacker reclaims trivially with a concurrent `mmap()`, gaining control of `vm_start/vm_end`, `vm_mm`, and `vm_page_prot`. `vm_insert_page()` then maps attacker-held binder pages into an unintended (potentially cross-process) mapping, enabling disclosure of memory beyond the attacker\u0027s own address space.\nI:H - The UAF is not read-only \u2014 `vm_insert_page()` performs `vm_flags_set(vma, VM_MIXEDMAP)`, writing into the freed/reclaimed slab object, and then installs page-table entries derived from its attacker-controllable fields. This yields a page-mapping and heap-corruption primitive of the same class as previously weaponized binder UAFs used for Android root escalation.\nA:H - The KASAN report in the fix commit shows a use-after-free read in `vm_insert_page()` reachable from a normal binder ioctl, and unsuccessful exploitation attempts corrupt page tables or the freed slab object, causing an oops or panic. The attacker can retrigger the race repeatedly."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T09:17:43.435Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/1bb8a65190d45cd5c7dbc85e29b9102110cd6be6"
        },
        {
          "url": "https://git.kernel.org/stable/c/931ea1ed31be939c1efdbc49bc66d2a45684f9b4"
        },
        {
          "url": "https://git.kernel.org/stable/c/ca0cc0a9c6e56c699e2acbb93d8024523021f3c3"
        },
        {
          "url": "https://git.kernel.org/stable/c/d1d8875c8c13517f6fd1ff8d4d3e1ac366a17e07"
        }
      ],
      "title": "binder: fix UAF of alloc-\u003evma in race with munmap()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-54157",
    "datePublished": "2025-12-24T13:07:06.764Z",
    "dateReserved": "2025-12-24T13:02:52.530Z",
    "dateUpdated": "2026-08-05T09:17:43.435Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-54157",
      "date": "2026-08-09",
      "epss": "0.0013",
      "percentile": "0.02994"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-54157\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-24T13:16:17.750\",\"lastModified\":\"2026-08-04T11:16:34.560\",\"vulnStatus\":\"Deferred\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbinder: fix UAF of alloc-\u003evma in race with munmap()\\n\\n[ cmllamas: clean forward port from commit 015ac18be7de (\\\"binder: fix\\n  UAF of alloc-\u003evma in race with munmap()\\\") in 5.10 stable. It is needed\\n  in mainline after the revert of commit a43cfc87caaf (\\\"android: binder:\\n  stop saving a pointer to the VMA\\\") as pointed out by Liam. The commit\\n  log and tags have been tweaked to reflect this. ]\\n\\nIn commit 720c24192404 (\\\"ANDROID: binder: change down_write to\\ndown_read\\\") binder assumed the mmap read lock is sufficient to protect\\nalloc-\u003evma inside binder_update_page_range(). This used to be accurate\\nuntil commit dd2283f2605e (\\\"mm: mmap: zap pages with read mmap_sem in\\nmunmap\\\"), which now downgrades the mmap_lock after detaching the vma\\nfrom the rbtree in munmap(). Then it proceeds to teardown and free the\\nvma with only the read lock held.\\n\\nThis means that accesses to alloc-\u003evma in binder_update_page_range() now\\nwill race with vm_area_free() in munmap() and can cause a UAF as shown\\nin the following KASAN trace:\\n\\n  ==================================================================\\n  BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0\\n  Read of size 8 at addr ffff16204ad00600 by task server/558\\n\\n  CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1\\n  Hardware name: linux,dummy-virt (DT)\\n  Call trace:\\n   dump_backtrace+0x0/0x2a0\\n   show_stack+0x18/0x2c\\n   dump_stack+0xf8/0x164\\n   print_address_description.constprop.0+0x9c/0x538\\n   kasan_report+0x120/0x200\\n   __asan_load8+0xa0/0xc4\\n   vm_insert_page+0x7c/0x1f0\\n   binder_update_page_range+0x278/0x50c\\n   binder_alloc_new_buf+0x3f0/0xba0\\n   binder_transaction+0x64c/0x3040\\n   binder_thread_write+0x924/0x2020\\n   binder_ioctl+0x1610/0x2e5c\\n   __arm64_sys_ioctl+0xd4/0x120\\n   el0_svc_common.constprop.0+0xac/0x270\\n   do_el0_svc+0x38/0xa0\\n   el0_svc+0x1c/0x2c\\n   el0_sync_handler+0xe8/0x114\\n   el0_sync+0x180/0x1c0\\n\\n  Allocated by task 559:\\n   kasan_save_stack+0x38/0x6c\\n   __kasan_kmalloc.constprop.0+0xe4/0xf0\\n   kasan_slab_alloc+0x18/0x2c\\n   kmem_cache_alloc+0x1b0/0x2d0\\n   vm_area_alloc+0x28/0x94\\n   mmap_region+0x378/0x920\\n   do_mmap+0x3f0/0x600\\n   vm_mmap_pgoff+0x150/0x17c\\n   ksys_mmap_pgoff+0x284/0x2dc\\n   __arm64_sys_mmap+0x84/0xa4\\n   el0_svc_common.constprop.0+0xac/0x270\\n   do_el0_svc+0x38/0xa0\\n   el0_svc+0x1c/0x2c\\n   el0_sync_handler+0xe8/0x114\\n   el0_sync+0x180/0x1c0\\n\\n  Freed by task 560:\\n   kasan_save_stack+0x38/0x6c\\n   kasan_set_track+0x28/0x40\\n   kasan_set_free_info+0x24/0x4c\\n   __kasan_slab_free+0x100/0x164\\n   kasan_slab_free+0x14/0x20\\n   kmem_cache_free+0xc4/0x34c\\n   vm_area_free+0x1c/0x2c\\n   remove_vma+0x7c/0x94\\n   __do_munmap+0x358/0x710\\n   __vm_munmap+0xbc/0x130\\n   __arm64_sys_munmap+0x4c/0x64\\n   el0_svc_common.constprop.0+0xac/0x270\\n   do_el0_svc+0x38/0xa0\\n   el0_svc+0x1c/0x2c\\n   el0_sync_handler+0xe8/0x114\\n   el0_sync+0x180/0x1c0\\n\\n  [...]\\n  ==================================================================\\n\\nTo prevent the race above, revert back to taking the mmap write lock\\ninside binder_update_page_range(). One might expect an increase of mmap\\nlock contention. However, binder already serializes these calls via top\\nlevel alloc-\u003emutex. Also, there was no performance impact shown when\\nrunning the binder benchmark tests.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/android/binder_alloc.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"dd2283f2605e3b3e9c61bcae844b34f2afa4813f\",\"lessThan\":\"1bb8a65190d45cd5c7dbc85e29b9102110cd6be6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"dd2283f2605e3b3e9c61bcae844b34f2afa4813f\",\"lessThan\":\"931ea1ed31be939c1efdbc49bc66d2a45684f9b4\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"dd2283f2605e3b3e9c61bcae844b34f2afa4813f\",\"lessThan\":\"ca0cc0a9c6e56c699e2acbb93d8024523021f3c3\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"dd2283f2605e3b3e9c61bcae844b34f2afa4813f\",\"lessThan\":\"d1d8875c8c13517f6fd1ff8d4d3e1ac366a17e07\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/android/binder_alloc.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.20\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.20\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.115\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.31\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.3.5\",\"lessThanOrEqual\":\"6.3.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.4\",\"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:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1bb8a65190d45cd5c7dbc85e29b9102110cd6be6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/931ea1ed31be939c1efdbc49bc66d2a45684f9b4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ca0cc0a9c6e56c699e2acbb93d8024523021f3c3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d1d8875c8c13517f6fd1ff8d4d3e1ac366a17e07\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "None",
      "current_release_date": "2026-06-30T10:15:33+00:00",
      "cve": "CVE-2023-54157",
      "id": "CVE-2023-54157",
      "initial_release_date": "2023-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: binder: fix UAF of alloc-\u003evma in race with munmap()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-54157.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-08-05T01:02:48Z",
      "cve": "CVE-2023-54157",
      "id": "CVE-2023-54157",
      "initial_release_date": "2025-12-25T00:54:18Z",
      "product_status:known_not_affected": "453",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2023-54157",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-54157.json",
      "version": "11"
    }
  }
}



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…