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

Goal: 1000 CNY · Raised: 1336 CNY

100%

CVE-2026-64130— mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free

AI Predicted 5.5 Difficulty: Hard EPSS 0.17% · P6

Possible ATT&CK Techniques 1AI

T1078 · Valid Accounts

Affected Version Matrix 8

VendorProductVersion RangeStatus
LinuxLinuxadfb6609c6809e107ded9a1cd46f519c882e64ea< 738d18f1da3513d17b6f7bf30146cc4ac2480ffdaffected
adfb6609c6809e107ded9a1cd46f519c882e64ea< 2f2aec5120b93a8f8b52dc50cdc60dbb8aec72f6affected
adfb6609c6809e107ded9a1cd46f519c882e64ea< 6a288a4ddb4a994490505ab5f41c445f8e6b6467affected
6.18affected
< 6.18unaffected
6.18.34≤ 6.18.*unaffected
7.0.11≤ 7.0.*unaffected
7.1≤ *unaffected
Get alerts for future matching vulnerabilitiesLog in to subscribe

I. Basic Information for CVE-2026-64130

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/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ... This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会开源的一款操作系统内核。 Linux kernel 6.18之前版本存在安全漏洞,该漏洞源于初始化巨大零页时标签初始化不当,可能导致内存标签泄露。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

VendorProductAffected VersionsCPESubscribe
LinuxLinux adfb6609c6809e107ded9a1cd46f519c882e64ea ~ 738d18f1da3513d17b6f7bf30146cc4ac2480ffd -
LinuxLinux 6.18 -

II. Public POCs for CVE-2026-64130

#POC DescriptionSource LinkShenlong Link
AI-Generated POCPremium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-64130

登录查看更多情报信息。

Patches & Fixes for CVE-2026-64130 (3)

Same Patch Batch · Linux · 2026-07-19 · 431 CVEs total

CVE-2026-6379510.0 CRITICAL9p: avoid putting oldfid in p9_client_walk() error path
CVE-2026-638009.8 CRITICALpNFS: Fix use-after-free in pnfs_update_layout()
CVE-2026-640559.8 CRITICALnet: ethernet: cortina: Carry over frag counter
CVE-2026-640569.8 CRITICALnet: ethernet: cortina: Make RX SKB per-port
CVE-2026-640619.8 CRITICALnetfs: Fix early put of sink folio in netfs_read_gaps()
CVE-2026-640669.8 CRITICALnetfs: Fix netfs_read_to_pagecache() to pause on subreq failure
CVE-2026-640679.8 CRITICALnetfs: Fix missing barriers when accessing stream->subrequests locklessly
CVE-2026-640689.8 CRITICALnetfs: Fix missing locking around retry adding new subreqs
CVE-2026-640699.8 CRITICALnetfs: Fix cancellation of a DIO and single read subrequests
CVE-2026-638089.8 CRITICALexfat: fix potential use-after-free in exfat_find_dir_entry()
CVE-2026-640899.8 CRITICALbatman-adv: tt: fix negative last_changeset_len
CVE-2026-640919.8 CRITICALbatman-adv: tt: fix TOCTOU race for reported vlans
CVE-2026-533999.8 CRITICALnfsd: release layout stid on setlease failure
CVE-2026-641429.8 CRITICALksmbd: close durable scavenger races against m_fp_list lookups
CVE-2026-533989.8 CRITICALNFSD: Fix SECINFO_NO_NAME decode error cleanup
CVE-2026-641369.8 CRITICALsmb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()
CVE-2026-641329.8 CRITICALipv6: ioam: refresh hdr pointer before ioam6_event()
CVE-2026-641229.8 CRITICALnet/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover
CVE-2026-641029.8 CRITICALRDMA/siw: Reject MPA FPDU length underflow before signed receive math
CVE-2026-641139.8 CRITICALixgbevf: fix use-after-free in VEPA multicast source pruning

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

IV. Related Vulnerabilities

V. Comments for CVE-2026-64130

No comments yet


Leave a comment