Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%
Buy Us a Coffee

CVE-2026-74632— mm/huge_memory: fix huge_zero_pfn race

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中，已修复以下漏洞： mm/huge_memory：修复 huge_zero_pfn 竞态条件 补丁系列 “mm/huge_memory: fix huge_zero_pfn race”，版本 2。 在引用计数实现的 中存在一个微妙的竞态条件。 快速路径中的原子逻辑未能考虑到这样一个事实：回收器（shrinker，负责释放最后的 引用锁）可能在竞态的 在此处安装有效值之后，在 中将 覆写为 哨兵值。 这会导致 被正确设置，但 被错误设置，从而导致 以及随之而来的 将巨大零页 folio 错误地识

CVSS 7.8 · High EPSS 0.13% · P3

Possible ATT&CK Techniques 1 AI

T1499 · Endpoint Denial of Service

Affected Version Matrix 22

VendorProduct Version RangeStatus
Linux Linux 3b77e8c8cde581dadab9a0f1543a347e24315f11< 9332b080ad57650d1dc582e54517f9fc78ef89cc affected
3b77e8c8cde581dadab9a0f1543a347e24315f11< f3a874a903053c53fb53ba287ea9eacda69c68e8 affected
3b77e8c8cde581dadab9a0f1543a347e24315f11< 6024f6d0d9b9ca5138bfc4ac6f6e4bdf616e42b3 affected
3b77e8c8cde581dadab9a0f1543a347e24315f11< 105d04edbec83010df5728f74d17fd9c108e7553 affected
3b77e8c8cde581dadab9a0f1543a347e24315f11< ab7e4b407c7f58d1a003134eff3841f303d5ccc2 affected
3b77e8c8cde581dadab9a0f1543a347e24315f11< 33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb affected
fc1fbc5b017b6f5ef24a4a93f33cd022225e01c8 affected
bd092a0f19423d7e9e81182314a96ecd6a14f3b7 affected
… +14 more rows
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-74632

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
mm/huge_memory: fix huge_zero_pfn race
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series "mm/huge_memory: fix huge_zero_pfn race", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---
Source: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 3b77e8c8cde581dadab9a0f1543a347e24315f11 ~ 9332b080ad57650d1dc582e54517f9fc78ef89cc -
Linux Linux 5.13 -

II. Public POCs for CVE-2026-74632

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-74632

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-74632 (6)

Same Patch Batch · Linux · 2026-08-22 · 150 CVEs total

CVE-2026-74705 10.0 CRITICAL udp: fix potential use-after-free in tunnel segmentation
CVE-2026-74612 10.0 CRITICAL veth: fix skb length accounting after XDP frag adjustment
CVE-2026-74587 9.8 CRITICAL sctp: fix use-after-free of cached ASCONF chunk
CVE-2026-74591 9.8 CRITICAL mm/filemap: __filemap_add_folio() restore index before retrying
CVE-2026-74688 9.8 CRITICAL sctp: clear control chunk transport if it is being removed
CVE-2026-74597 9.8 CRITICAL ip6_tunnel: clear skb2->cb[] in ip6ip6_err()
CVE-2026-74617 9.8 CRITICAL dibs: initialise dibs->lock in dibs_dev_alloc()
CVE-2026-74616 9.8 CRITICAL xdp: reject clones that overrun skb_shared_info tailroom
CVE-2026-74628 9.8 CRITICAL net/x25: fix use-after-free of the socket by its timers
CVE-2026-74608 9.8 CRITICAL smb: client: Fix use-after-free in cifs_try_adding_channels()
CVE-2026-74669 9.8 CRITICAL ipvs: clear IPv4 options after rebasing tunnel ICMP errors
CVE-2026-74662 9.8 CRITICAL inet: frags: publish queues before arming timer
CVE-2026-74730 9.8 CRITICAL NFS: Pin the 'struct nfs_server' during a FREE_STATEID call
CVE-2026-74727 9.8 CRITICAL ovpn: skip rehash for peers already removed from by_id
CVE-2026-74586 9.8 CRITICAL sctp: clear new_transport when removing a peer
CVE-2026-74723 9.8 CRITICAL btrfs: lzo: reject inline extents without valid headers
CVE-2026-74588 9.8 CRITICAL sctp: keep chunk->transport in step with the list it is queued on
CVE-2026-74611 9.8 CRITICAL tls: rx: restore msg_iter before TLS 1.3 optimistic retry
CVE-2026-74712 9.3 CRITICAL vdpa/mlx5: Fix buffer length in create_direct_keys()
CVE-2026-74665 9.1 CRITICAL net: fix skb length accounting after generic XDP frag adjustment

Showing top 20 of 150 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

Same product: Linux
Same vendor: Linux

V. Comments for CVE-2026-74632

No comments yet

Leave a comment