Common Weakness Enumeration

CWE-416

Allowed

Use After Free

Abstraction: Variant · Status: Stable

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

9821 vulnerabilities reference this CWE, most recent first.

GHSA-5V94-M7FF-M26P

Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-08-29 03:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: Fix use-after-free and race in fastrpc_map_find

Currently, there is a race window between the point when the mutex is unlocked in fastrpc_map_lookup and the reference count increasing (fastrpc_map_get) in fastrpc_map_find, which can also lead to use-after-free.

So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us to both protect the maps list by also taking the &fl->lock spinlock and the reference count, since the spinlock will be released only after. Add take_ref argument to make this suitable for all callers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T07:15:04Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix use-after-free and race in fastrpc_map_find\n\nCurrently, there is a race window between the point when the mutex is\nunlocked in fastrpc_map_lookup and the reference count increasing\n(fastrpc_map_get) in fastrpc_map_find, which can also lead to\nuse-after-free.\n\nSo lets merge fastrpc_map_find into fastrpc_map_lookup which allows us\nto both protect the maps list by also taking the \u0026fl-\u003elock spinlock and\nthe reference count, since the spinlock will be released only after.\nAdd take_ref argument to make this suitable for all callers.",
  "id": "GHSA-5v94-m7ff-m26p",
  "modified": "2024-08-29T03:30:48Z",
  "published": "2024-08-21T09:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48874"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9446fa1683a7e3937d9970248ced427c1983a1c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a50c5c25b6e7d2824698c0e6385f882a18f4a498"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5V99-GHRR-2564

Vulnerability from github – Published: 2022-11-29 18:30 – Updated: 2022-12-01 21:30
VLAI
Details

GPAC v2.1-DEV-rev478-g696e6f868-master was discovered to contain a heap use-after-free via the Q_IsTypeOn function at /gpac/src/bifs/unquantize.c.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-45343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-29T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "GPAC v2.1-DEV-rev478-g696e6f868-master was discovered to contain a heap use-after-free via the Q_IsTypeOn function at /gpac/src/bifs/unquantize.c.",
  "id": "GHSA-5v99-ghrr-2564",
  "modified": "2022-12-01T21:30:19Z",
  "published": "2022-11-29T18:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45343"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gpac/gpac/issues/2315"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5411"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5V9P-3RFC-6RW2

Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-07-14 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net: fix fanout UAF in packet_release() via NETDEV_UP race

packet_release() has a race window where NETDEV_UP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanout_release(), leaving a dangling pointer in the fanout array. packet_release() does NOT zero po->num in its bind_lock section. After releasing bind_lock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packet_notifier(NETDEV_UP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls __fanout_link(sk, po) which adds the socket back into f->arr[] and increments f->num_members, but does NOT increment f->sk_ref.

The fix sets po->num to zero in packet_release while bind_lock is held to prevent NETDEV_UP from linking, preventing the race window.

This bug was found following an additional audit with Claude Code based on CVE-2025-38617.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T14:16:49Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix fanout UAF in packet_release() via NETDEV_UP race\n\n`packet_release()` has a race window where `NETDEV_UP` can re-register a\nsocket into a fanout group\u0027s `arr[]` array. The re-registration is not\ncleaned up by `fanout_release()`, leaving a dangling pointer in the fanout\narray.\n`packet_release()` does NOT zero `po-\u003enum` in its `bind_lock` section.\nAfter releasing `bind_lock`, `po-\u003enum` is still non-zero and `po-\u003eifindex`\nstill matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`\nthat already found the socket in `sklist` can re-register the hook.\nFor fanout sockets, this re-registration calls `__fanout_link(sk, po)`\nwhich adds the socket back into `f-\u003earr[]` and increments `f-\u003enum_members`,\nbut does NOT increment `f-\u003esk_ref`.\n\nThe fix sets `po-\u003enum` to zero in `packet_release` while `bind_lock` is\nheld to prevent NETDEV_UP from linking, preventing the race window.\n\nThis bug was found following an additional audit with Claude Code based\non CVE-2025-38617.",
  "id": "GHSA-5v9p-3rfc-6rw2",
  "modified": "2026-07-14T15:31:53Z",
  "published": "2026-04-22T15:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31504"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b4c03f8892d955385c202009af7485364731bb9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/42156f93d123436f2a27c468f18c966b7e5db796"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/42cfd7898eeed290c9fb73f732af1f7d6b0a703e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/654386baef228c2992dbf604c819e4c7c35fc71b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/75fe6db23705a1d55160081f7b37db9665b1880b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ceccbfc6de720ad633519a226715989cfb065af1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d0c7cdc15fdf8c4f91aca1928e52295d175b6ec6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee642b1962caa9aa231c01abbd58bc453ae6b66e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VJ7-R55G-9XV7

Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-14 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).

This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:

1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault

The issue manifests as follows:

WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do something sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.

So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

[sean: massage changelog, make it clear this isn't architectural behavior]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T16:15:33Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception\n\nPreviously, commit ed129ec9057f (\"KVM: x86: forcibly leave nested mode\non vCPU reset\") addressed an issue where a triple fault occurring in\nnested mode could lead to use-after-free scenarios. However, the commit\ndid not handle the analogous situation for System Management Mode (SMM).\n\nThis omission results in triggering a WARN when KVM forces a vCPU INIT\nafter SHUTDOWN interception while the vCPU is in SMM. This situation was\nreprodused using Syzkaller by:\n\n  1) Creating a KVM VM and vCPU\n  2) Sending a KVM_SMI ioctl to explicitly enter SMM\n  3) Executing invalid instructions causing consecutive exceptions and\n     eventually a triple fault\n\nThe issue manifests as follows:\n\n  WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112\n  kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Modules linked in:\n  CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted\n  6.1.130-syzkaller-00157-g164fe5dde9b6 #0\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n  BIOS 1.12.0-1 04/01/2014\n  RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Call Trace:\n   \u003cTASK\u003e\n   shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136\n   svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395\n   svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457\n   vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]\n   vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062\n   kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283\n   kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:870 [inline]\n   __se_sys_ioctl fs/ioctl.c:856 [inline]\n   __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nArchitecturally, INIT is blocked when the CPU is in SMM, hence KVM\u0027s WARN()\nin kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper\nemulation of INIT.  SHUTDOWN on SVM is a weird edge case where KVM needs to\ndo _something_ sane with the VMCB, since it\u0027s technically undefined, and\nINIT is the least awful choice given KVM\u0027s ABI.\n\nSo, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of\nSMM to avoid any weirdness (and the WARN).\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[sean: massage changelog, make it clear this isn\u0027t architectural behavior]",
  "id": "GHSA-5vj7-r55g-9xv7",
  "modified": "2025-11-14T18:31:19Z",
  "published": "2025-05-20T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37957"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a2620f8932fa9fdabc3d78ed6efb004ca409019f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d362b21fefcef7eda8f1cd78a5925735d2b3287c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e9b28bc65fd3a56755ba503258024608292b4ab1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec24e62a1dd3540ee696314422040180040c1e4a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VJ9-MJ9W-QCWF

Vulnerability from github – Published: 2022-07-22 00:00 – Updated: 2022-07-27 00:00
VLAI
Details

Use after free in Safe Browsing in Google Chrome prior to 99.0.4844.74 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-0973"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-21T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use after free in Safe Browsing in Google Chrome prior to 99.0.4844.74 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.",
  "id": "GHSA-5vj9-mj9w-qcwf",
  "modified": "2022-07-27T00:00:45Z",
  "published": "2022-07-22T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0973"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_15.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1297498"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-25"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VMJ-CW62-2MGM

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-12-17 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug

Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur.

The solution is to let rxe_cleanup do all the work.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38024"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T10:15:34Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.",
  "id": "GHSA-5vmj-cw62-2mgm",
  "modified": "2025-12-17T21:30:31Z",
  "published": "2025-06-18T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38024"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/16c45ced0b3839d3eee72a86bb172bef6cf58980"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/336edd6b0f5b7fbffc3e065285610624f59e88df"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a3b73e135e3bd18423d0baa72571319c7feb759"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/52daccfc3fa68ee1902d52124921453d7a335591"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c7c80c32e00665234e373ab03fe82f5c5c2c230"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee4c5a2a38596d548566560c0c022ab797e6f71a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f81b33582f9339d2dc17c69b92040d3650bb4bae"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8f470e3a757425a8f98fb9a5991e3cf62fc7134"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VQ6-7CJ2-4M9J

Vulnerability from github – Published: 2026-05-27 12:31 – Updated: 2026-06-26 21:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix use-after-free in arena_vm_close on fork

arena_vm_open() only bumps vml->mmap_count but never registers the child VMA in arena->vma_list. The vml->vma always points at the parent VMA, so after parent munmap the pointer dangles. If the child then calls bpf_arena_free_pages(), zap_pages() reads the stale vml->vma triggering use-after-free.

Fix this by preventing the arena VMA from being inherited across fork with VM_DONTCOPY, and preventing VMA splits via the may_split callback.

Also reject mremap with a .mremap callback returning -EINVAL. A same-size mremap(MREMAP_FIXED) on the full arena VMA reaches copy_vma() through the following path:

check_prep_vma() - returns 0 early: new_len == old_len skips VM_DONTEXPAND check prep_move_vma() - vm_start == old_addr and vm_end == old_addr + old_len so may_split is never called move_vma() copy_vma_and_data() copy_vma() vm_area_dup() - copies vm_private_data (vml pointer) vm_ops->open() - bumps vml->mmap_count vm_ops->mremap() - returns -EINVAL, rollback unmaps new VMA

The refcount ensures the rollback's arena_vm_close does not free the vml shared with the original VMA.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-45837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T11:16:23Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix use-after-free in arena_vm_close on fork\n\narena_vm_open() only bumps vml-\u003emmap_count but never registers the\nchild VMA in arena-\u003evma_list. The vml-\u003evma always points at the\nparent VMA, so after parent munmap the pointer dangles. If the child\nthen calls bpf_arena_free_pages(), zap_pages() reads the stale\nvml-\u003evma triggering use-after-free.\n\nFix this by preventing the arena VMA from being inherited across\nfork with VM_DONTCOPY, and preventing VMA splits via the may_split\ncallback.\n\nAlso reject mremap with a .mremap callback returning -EINVAL. A\nsame-size mremap(MREMAP_FIXED) on the full arena VMA reaches\ncopy_vma() through the following path:\n\n  check_prep_vma()       - returns 0 early: new_len == old_len\n                           skips VM_DONTEXPAND check\n  prep_move_vma()        - vm_start == old_addr and\n                           vm_end == old_addr + old_len\n                           so may_split is never called\n  move_vma()\n    copy_vma_and_data()\n      copy_vma()\n        vm_area_dup()    - copies vm_private_data (vml pointer)\n        vm_ops-\u003eopen()   - bumps vml-\u003emmap_count\n      vm_ops-\u003emremap()   - returns -EINVAL, rollback unmaps new VMA\n\nThe refcount ensures the rollback\u0027s arena_vm_close does not free\nthe vml shared with the original VMA.",
  "id": "GHSA-5vq6-7cj2-4m9j",
  "modified": "2026-06-26T21:32:04Z",
  "published": "2026-05-27T12:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45837"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/201128fcc7b213d27ab77bc4e89488b41796480f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4fddde2a732de60bb97e3307d4eb69ac5f1d2b74"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/723b9fa930cc277c15ce6b9ec9feec828cfac9d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d18099f19e53250f8ad2801498b88cec29d9107a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VQW-WPPF-X433

Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

libceph: fix race between delayed_work() and ceph_monc_stop()

The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.

To fix this:

  • clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
  • bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
  • call cancel_delayed_work_sync() after the session is closed
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-07T16:15:46Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix race between delayed_work() and ceph_monc_stop()\n\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting().  Both of\nthese can requeue the delayed work which wouldn\u0027t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0027t mess with the delayed work in order\nto avoid interfering with the hunting interval logic.  This part was\nmissed in commit b5d91704f53e (\"libceph: behave in mon_fault() if\ncur_mon \u003c 0\") and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u003eauth and monc-\u003emonmap being\nparticularly susceptible to quickly being reused.\n\nTo fix this:\n\n- clear monc-\u003ecur_mon and monc-\u003ehunting as part of closing the session\n  in ceph_monc_stop()\n- bail from delayed_work() if monc-\u003ecur_mon is cleared, similar to how\n  it\u0027s done in mon_fault() and finish_hunting() (based on monc-\u003ehunting)\n- call cancel_delayed_work_sync() after the session is closed",
  "id": "GHSA-5vqw-wppf-x433",
  "modified": "2025-11-04T00:31:10Z",
  "published": "2024-08-07T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VRC-4FJ4-9CMH

Vulnerability from github – Published: 2026-05-11 21:31 – Updated: 2026-05-12 15:31
VLAI
Details

A use after free issue was addressed with improved memory management. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. An app may be able to cause unexpected system termination.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-28969"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-11T21:18:57Z",
    "severity": "HIGH"
  },
  "details": "A use after free issue was addressed with improved memory management. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. An app may be able to cause unexpected system termination.",
  "id": "GHSA-5vrc-4fj4-9cmh",
  "modified": "2026-05-12T15:31:34Z",
  "published": "2026-05-11T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28969"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127110"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127111"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127115"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127116"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127117"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127118"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127120"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VWC-PX2M-7JXG

Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-04-08 18:34
VLAI
Details

Use after free in Microsoft Office allows an unauthorized attacker to execute code locally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-27749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-08T18:16:04Z",
    "severity": "HIGH"
  },
  "details": "Use after free in Microsoft Office allows an unauthorized attacker to execute code locally.",
  "id": "GHSA-5vwc-px2m-7jxg",
  "modified": "2025-04-08T18:34:56Z",
  "published": "2025-04-08T18:34:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27749"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-27749"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Language Selection

Choose a language that provides automatic memory management.

Mitigation
Implementation

Strategy: Attack Surface Reduction

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

No CAPEC attack patterns related to this CWE.