CVE-2025-0927

Published Mar 23, 2025

Last updated 2 years ago

Linux Kernel

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-0927 is a heap overflow vulnerability found in the HFS+ file system implementation within the Linux Kernel. Discovered by Attila Szász, the vulnerability can be exploited if an attacker mounts a specially crafted file system image. This flaw, a buffer overflow in B-tree node processing within the HFS+ driver, can lead to a denial of service (system crash) or potentially allow the execution of arbitrary code. The vulnerability has been present in the Linux kernel since 2005 (Linux-2.6.12-rc2) and affects Linux Kernel versions up to 6.12.0, as well as Ubuntu 22.04 with Linux Kernel 6.5.0-18-generic. A public proof-of-concept exploit exists for this vulnerability.

Description
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Filesystem bugs due to corrupt images are not considered a CVE for any filesystem that is only mountable by CAP_SYS_ADMIN in the initial user namespace. That includes delegated mounting.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Rejected

Social media

Hype score
Not currently trending

  1. Oh, the Linux CNA got nominated for a @PwnieAwards with CVE-2025-0927? Well, well..🥸 https://t.co/Ols9UoI5t2

    @4ttil4sz1a

    18 Jul 2025

    1026 Impressions

    0 Retweets

    9 Likes

    1 Bookmark

    0 Replies

    1 Quote

  2. Fuzzing Linux Kernel Modules, with Slava Moskvin Stream by @slava_moskvin_ hosted by @Steph3nSims about building a custom fuzzer to rediscover CVE-2025-0927 in the HFS+ filesystem implementation. https://t.co/UPWCmwUWC1

    @linkersec

    16 Jul 2025

    5963 Impressions

    27 Retweets

    98 Likes

    42 Bookmarks

    2 Replies

    0 Quotes

  3. 🛠System Update Notification The Lemondator Validator VM has been successfully updated with the latest Ubuntu security patches as of June 2025. This includes: 🔐 Kernel Vulnerability Fix (CVE-2025-0927) • Resolved a critical heap overflow issue in the HFS+ file system.

    @Lemondator

    18 Jun 2025

    46 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  4. 🚨 ALERTA DE SEGURIDAD: CVE-2025-0927 - Falla Crítica al Montar Archivos HFS+ en Linux 🚨 ⚠️ Impacto: Riesgo de denegación de servicio o ejecución de código malicioso. https://t.co/VO9zOiuja1

    @BanCERT_gt

    30 Apr 2025

    8 Impressions

    1 Retweet

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 A serious vulnerability, CVE-2025-0927, in the Linux kernel affects Ubuntu 22.04, enabling local privilege escalation via heap overflow in HFS+. Patches are out! ⚠️ #LinuxSecurity #Ubuntu #CVE2025 link: https://t.co/2ykbeaAynO https://t.co/JpkfrbD8wR

    @TweetThreatNews

    25 Mar 2025

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2025-0927: Public Exploit Released for Linux Kernel Privilege Escalation Bug https://t.co/GuKZzqTP7C

    @Dinosn

    25 Mar 2025

    13241 Impressions

    86 Retweets

    336 Likes

    117 Bookmarks

    0 Replies

    0 Quotes

  7. Linuxカーネルにおける権限昇格の脆弱性CVE-2025-0927に対応するPoC（攻撃の概念実証コード）が公表された。Ubuntu 22.04に影響。HFS+ファイルシステムにおけるヒープオーバーフロー。 https://t.co/8LrhROw9NI

    @__kokumoto

    25 Mar 2025

    2709 Impressions

    12 Retweets

    41 Likes

    13 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-0927: Public Exploit Released for #Linux Kernel Privilege Escalation Bug The flaw, tracked as CVE-2025-0927, a heap overflow in the HFS+ file system implementation, could allow an attacker to escalate local privileges on affected systems https://t.co/r27DjU2ghx

    @Daily_CyberSec

    25 Mar 2025

    6679 Impressions

    39 Retweets

    136 Likes

    53 Bookmarks

    2 Replies

    1 Quote

  9. 🚨 CVE-2025-0927 🔴 HIGH (7.8) 🏢 Canonical - Ubuntu Linux 🏗️ 3.13 🔗 https://t.co/aBEPvI109q 🔗 https://t.co/vdEflNpSBZ #CyberCron #VulnAlert #InfoSec https://t.co/RO5U4O2FrO

    @cybercronai

    24 Mar 2025

    21 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. 🚨 CVE-2025-0927 🔴 HIGH (7.8) 🏢 Canonical - Ubuntu Linux 🏗️ 3.13 🔗 https://t.co/aBEPvI109q 🔗 https://t.co/vdEflNpSBZ #CyberCron #VulnAlert #InfoSec https://t.co/WyzfQEPH1v

    @cybercronai

    23 Mar 2025

    23 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. New post from https://t.co/uXvPWJyEiR (CVE-2025-0927 | Canonical Ubuntu Linux prior 6.11.0-18.18 HFS+ filesystem out-of-bounds write (USN-7276-1)) has been published on https://t.co/qit1d5GaO7

    @WolfgangSesin

    23 Mar 2025

    14 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. CVE-2025-0927 HFS+ File System Heap Overflow Vulnerability in Linux Kernel https://t.co/Uzle4uCJAg

    @VulmonFeeds

    23 Mar 2025

    8 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. CVE-2025-0927 Attila Szász discovered that the HFS+ file system implementation in the Linux Kernel contained a heap overflow vulnerability. An attacker could use a specially crafted … https://t.co/J0shHxeofg

    @CVEnew

    23 Mar 2025

    532 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. I ran into this issue while working on my kernel exploit for CVE-2025-0927. Curious to see if you know the answer—some LLMs might need a little nudge to get it right. https://t.co/azs1OAbZao

    @4ttil4sz1a

    22 Mar 2025

    137 Impressions

    0 Retweets

    2 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  15. Learn how an out-of-bounds write vulnerability in the Linux kernel can be exploited to achieve an LPE (CVE-2025-0927) https://t.co/LKfY71in00 https://t.co/qvUYSfD2u0

    @secharvesterx

    18 Mar 2025

    25 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  16. CVE-2025-0927 details here! https://t.co/z9amcuNjKP

    @4ttil4sz1a

    18 Mar 2025

    883 Impressions

    5 Retweets

    15 Likes

    8 Bookmarks

    0 Replies

    0 Quotes

  17. CVE-2025-0927 : A New Linux Kernel LPE Vulnerability A recently discovered out-of-bounds write vulnerability in the Linux kernel (versions 2.x up to 6.13) affects filesystem code, enabling local privilege escalation (LPE). https://t.co/Cgm7ppLiXC

    @freedomhack101

    18 Feb 2025

    25 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  18. 🚨 #CVE-2025-0927 – A New #Linux Kernel LPE Vulnerability https://t.co/XX9XyGUgdM

    @UndercodeUpdate

    17 Feb 2025

    13 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Related CVEs

  1. In the Linux kernel, the following vulnerability has been resolved: ipv4: validate checksum_start before completing checksum If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work.•CVE-2026-99999
  2. In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.•CVE-2026-72137
  3. In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.•CVE-2026-68162
  4. In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.•CVE-2026-64561
  5. In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).•CVE-2026-63801

References

Sources include official advisories and independent security research.