CVE-2025-21756

Published Feb 27, 2025

Last updated 3 months ago

CVSS high 7.8
Container Security

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-21756 affects the Linux kernel's vsock (Virtual Socket) implementation. Disclosed on February 26, 2025, it is a use-after-free vulnerability that occurs during socket destruction and transport reassignment processes within the vsock subsystem. The vulnerability stems from improper handling of socket bindings during transport reassignment. The `vsock_remove_bound` function can be called without verifying if the socket was bound, potentially leading to a use-after-free condition when `vsock_bind` assumes the socket is in an unbound list. A patch has been implemented to preserve socket bindings until socket destruction, resolving the issue.

Description
In the Linux kernel, the following vulnerability has been resolved: vsock: Keep the binding until socket destruction Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect(). Prevents socket unbinding during a transport reassignment, which fixes a use-after-free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does: list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Modified
Products
linux_kernel

Risk scores

CVSS 3.1

Type
Secondary
Base score
7.8
Impact score
5.9
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-416

Social media

Hype score
Not currently trending
  1. CVE-2025-21756 just landed. vsock vulnerability. Most teams haven't seen it yet. Ours was patched before public disclosure. Here's the breakdown. (1/7) https://t.co/NCBD4sKA85

    @polsia

    19 Jul 2026

    54 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. “Linux kernel” platformasında yüksək riskli boşluqlar (CVE-2025-21756, CVE-2025-21863) aşkar olunub. #ETX #certaz #cybersecurity #kibertəhlükəsizlik #xəbərdarlıq https://t.co/1ekbqqT2Tc

    @CERTAzerbaijan

    11 Aug 2025

    37 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. #Kernel_Security #Offensive_security 1. Exploiting UAF in vsock subsystem of the Linux kernel (CVE-2025-21756) https://t.co/S2bRE1NMBv 2. Secure Enclaves for Offensive Operations Part 1 - https://t.co/XPXkP78F9G Part 2 - https://t.co/BU1cXSuMgN

    @ksg93rd

    18 Jun 2025

    177 Impressions

    0 Retweets

    1 Like

    1 Bookmark

    0 Replies

    0 Quotes

  4. Exploiting the CVE-2025-21756 1-day vulnerability @v4bel and @_qwerty_po posted a kernelCTF report about exploiting a UAF in the vsock subsystem of the Linux kernel: https://t.co/iw1O0ZivdG https://t.co/f8rC7YqAVC

    @linkersec

    17 Jun 2025

    6677 Impressions

    33 Retweets

    126 Likes

    45 Bookmarks

    1 Reply

    0 Quotes

  5. Use After Free Affecting kernel-64k-modules package, versions <0:5.14.0-284.117.1.el9_2 CVE-2025-21756 CWE-416 https://t.co/xYg3baxHAM

    @ytroncal

    1 Jun 2025

    10 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. This is an exploit for CVE-2025-21756. It is written for linux kernel 6.6.75. https://t.co/GtSpz0uem8

    @ytroncal

    28 May 2025

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. Linux Kernel Exploitation: CVE-2025-21756 https://t.co/sxZszyt68J

    @akaclandestine

    23 May 2025

    958 Impressions

    2 Retweets

    8 Likes

    4 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-21756: Attack of the Vsock Michael Hoefler published an article about exploiting an incorrect reference counter decrement causing a UAF in the vsock subsystem. https://t.co/5QS9BE6tM6 https://t.co/o0SGVT2qwW

    @linkersec

    8 May 2025

    4752 Impressions

    30 Retweets

    101 Likes

    36 Bookmarks

    1 Reply

    0 Quotes

  9. この記事をおすすめしました "Linux Kernel Exploitation: CVE-2025-21756" via @techfeedapp #techfeed https://t.co/U4bZ7faNdC

    @hossuii

    3 May 2025

    58 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. CVE-2025-21756: การโจมตีของ Vsock - การแสวงหาประโยชน์ของลินุกซ์เคอร์เนล https://t.co/vgkIACkMt3

    @freedomhack101

    3 May 2025

    29 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  11. به تازگی آسیب پذیری جدیدی با کد شناسایی CVE-2025-21756 برای کرنل لینوکس منتشر شده است. این آسیب پذیری که از نوع privilege escalation می باشد ، باعث ارتقای سطح دسترسی هکر به

    @AmirHossein_sec

    1 May 2025

    61 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. CVE-2025-21756: Attack of the Vsock https://t.co/vXcfat5KvA https://t.co/ejxfpxYwsu

    @secharvesterx

    1 May 2025

    122 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. Linux Kernel Exploitation (CVE-2025-21756) : Attack of the Vsock : https://t.co/w5Hs9WrXH5 Source code for the exploit : https://t.co/rRFNu6KBqd https://t.co/g4664kFGMY

    @binitamshah

    1 May 2025

    1938 Impressions

    2 Retweets

    18 Likes

    10 Bookmarks

    0 Replies

    0 Quotes

  14. Linux Kernel Exploitation (CVE-2025-21756) : Attack of the Vsock : https://t.co/w5Hs9WrXH5 Source code for the exploit : https://t.co/rRFNu6KBqd https://t.co/f77Dih300r

    @binitamshah

    1 May 2025

    1735 Impressions

    10 Retweets

    22 Likes

    6 Bookmarks

    1 Reply

    0 Quotes

  15. Linux Kernel Exploitation CVE-2025-21756: Attack of the Vsock https://t.co/AW4a3RR5R1

    @ytroncal

    30 Apr 2025

    20 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  16. Linux Kernel Exploitation: CVE-2025-21756 #HackerNews https://t.co/sx0qMiBHf2

    @hackernewstop5

    30 Apr 2025

    28 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  17. Linux Kernel Exploitation: CVE-2025-21756 https://t.co/gf0VDnPZmH 2

    @cevaboyz

    30 Apr 2025

    26 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  18. ⚠️Múltiples vulnerabilidades del kernel de Linux Debian ❗CVE-2025-21756 ❗CVE-2025-21855 ❗CVE-2025-39735 ➡️Más info: https://t.co/oAUIMKsjS4 https://t.co/hyWEwL5d5T

    @CERTpy

    30 Apr 2025

    88 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  19. 🚨 #Linux Kernel Hacked: #CVE-2025-21756 – Exploiting the Vsock UAF for Root Access https://t.co/jfF1b8pjRv Educational Purposes!

    @UndercodeUpdate

    30 Apr 2025

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  20. 🚨🐧Linux Kernel Hacked: CVE-2025-21756 – Exploiting the Vsock UAF for Root Access The Article Can Be Found Here https://t.co/rQ1iOMwugX https://t.co/fqFwkFLwKE

    @_zeus_dev_

    30 Apr 2025

    152 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    1 Quote

  21. 🚨 Critical Linux Kernel vulnerability (CVE-2025-21756) in vsock module allows local #privilegeescalation to root. Affects cloud & container environments. Patch now! 📌 Read more: https://t.co/yuWDaKCMmN #CVE202521756 #Linux #CyberSecurity

    @threatsbank

    30 Apr 2025

    13 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  22. Linuxの権限昇格脆弱性CVE-2025-21756に対応するPoC(攻撃の概念実証コード)が公開された。カーネルのvsockサブシステムにおける解放後メモリ使用。脆弱なvsock_release()関数はAppArmor保護対象ではないため、ポイン

    @__kokumoto

    29 Apr 2025

    696 Impressions

    2 Retweets

    5 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  23. Linux Kernel Exploitation: CVE-2025-21756 https://t.co/iEhP0meBFZ

    @takesako

    29 Apr 2025

    55 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  24. Actively exploited CVE : CVE-2025-21756

    @transilienceai

    29 Apr 2025

    21 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  25. 🔥 Linux Kernel Vulnerability Exposes Systems to Privilege Escalation Attacks Read more: https://t.co/ZatBxYAcpF A significant vulnerability in the Linux kernel’s Virtual Socket (vsock) implementation, designated as CVE-2025-21756, has been identified that could allow lo

    @The_Cyber_News

    29 Apr 2025

    389 Impressions

    3 Retweets

    4 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  26. CVE-2025-21756: How a Tiny Linux Kernel Bug Led to a Full Root Exploit, PoC Releases https://t.co/fJSTn5CaNq

    @Dinosn

    29 Apr 2025

    6152 Impressions

    45 Retweets

    153 Likes

    45 Bookmarks

    2 Replies

    1 Quote

  27. CVE-2025-21756: How a Tiny Linux Kernel Bug Led to a Full Root Exploit, PoC Releases https://t.co/az9sqf8NDL

    @Daily_CyberSec

    29 Apr 2025

    5745 Impressions

    43 Retweets

    156 Likes

    62 Bookmarks

    0 Replies

    0 Quotes

  28. GitHub - hoefler02/CVE-2025-21756: My first linux kernel exploit https://t.co/BpYKlKvAbj

    @akaclandestine

    19 Apr 2025

    1037 Impressions

    1 Retweet

    13 Likes

    6 Bookmarks

    0 Replies

    0 Quotes

  29. GitHub - hoefler02/CVE-2025-21756: My first linux kernel exploit - https://t.co/azv5mktRGG

    @piedpiper1616

    19 Apr 2025

    697 Impressions

    4 Retweets

    10 Likes

    4 Bookmarks

    0 Replies

    0 Quotes

Configurations

  1. In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.CVE-2026-63807
  2. In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: <TASK> __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf </TASK> Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on "normal" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.CVE-2026-63806