CVE-2026-46279

What it actually does

This Linux kernel flaw is an initialization-ordering bug in the memory-allocation profiling path. Pages allocated and freed before page_ext initialization can retain an uninitialized allocation codetag; when those pages are later freed, especially through KASAN-related paths, the kernel can emit a warning such as "alloc_tag was not set" from __pgalloc_tag_sub(). The issue is primarily observable when CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled and mem_profiling_compressed is disabled. The practical impact is a kernel warning and potential denial-of-service behavior if the system is configured to treat kernel warnings as fatal, such as with panic_on_warn.

Why it matters to the business

For most production Linux systems this is likely low risk because it depends on uncommon debug/profiling kernel configuration and has no known public exploit maturity, is not listed in CISA KEV, is not associated with ransomware use, and has a low EPSS score. Organizations running custom, debug, test, CI, fuzzing, or hardened kernels that panic on kernel warnings could experience boot-time or early-runtime instability, failed test runs, host crashes, or reduced availability.

How an attack unfolds

There is no evidence of a practical remote exploitation path or active exploitation. The condition arises during early kernel boot because page_ext is initialized after some pages may already have been allocated and freed. If memory allocation profiling debug support is enabled and compressed memory profiling is disabled, those early pages may later be reclaimed through KASAN/quarantine or slab-allocation paths. When the kernel attempts to subtract accounting from a page whose allocation codetag was never set, it emits a warning. An attacker would generally need local code execution or control over workloads that influence memory allocation/free patterns, and meaningful denial of service would typically require the host to be configured to panic on kernel warnings.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for mm/alloc_tag page codetag initialization during early boot. If vendor fixed package versions are not available, obtain the fix from the relevant Linux distribution or kernel vendor advisory once published. As mitigations, avoid using affected debug/profiling kernel configurations in production, disable CONFIG_MEM_ALLOC_PROFILING_DEBUG where it is not required, enable the corrected memory profiling behavior where applicable, and avoid panic_on_warn on systems where kernel warnings should not cause availability loss. For systems used in kernel development, fuzzing, or CI, prioritize applying the patch to reduce false-positive instability and test interruption.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the distribution/vendor changelog or kernel source for the mm/alloc_tag change that tracks pages allocated before page_ext initialization and clears their codetag after page_ext setup completes. Verify runtime exposure by reviewing the kernel configuration for CONFIG_MEM_ALLOC_PROFILING_DEBUG and relevant memory profiling settings. Reboot a patched test system with the same configuration and confirm that dmesg, journalctl -k, or kernel ring buffer logs no longer show "alloc_tag was not set" warnings from __pgalloc_tag_sub(), __free_frozen_pages(), qlist_free_all(), or kasan_quarantine_reduce during boot or early workload execution.

Typical attack path

1. Identify a Linux system running an affected kernel build with CONFIG_MEM_ALLOC_PROFILING_DEBUG enabled and mem_profiling_compressed disabled.
2. Confirm that kernel warning behavior is security-impacting, for example panic_on_warn is enabled or kernel warnings disrupt workload health checks.
3. Trigger memory allocation and free activity that causes pages allocated before page_ext initialization to be reclaimed through KASAN/slab paths.
4. Cause the kernel to hit the uninitialized allocation codetag path and emit the "alloc_tag was not set" warning.
5. If the system panics on warnings, convert the warning into a denial of service by crashing or rebooting the host.

How to detect it

Look for prior exploitation or manifestation in kernel logs rather than conventional intrusion artifacts. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel logs via journalctl -k, crash dumps, kdump/vmcore analysis, and CI/fuzzing console logs. Search for the warning text "alloc_tag was not set" and stack traces involving __pgalloc_tag_sub, __free_frozen_pages, qlist_free_all, kasan_quarantine_reduce, and kmem_cache_alloc_noprof. Correlate events with boot time, early service startup, kernel panic/reboot events, panic_on_warn settings, and systems running debug memory profiling or KASAN-enabled kernels. Because there are no known threat actors or public exploit maturity for this CVE, treat matches as exposure or triggering evidence first, then investigate whether any local workload intentionally caused repeated memory pressure immediately before crashes.

• alloc_tag was not set
• WARNING: ./include/linux/alloc_tag.h:164
• __pgalloc_tag_sub
• __free_frozen_pages
• qlist_free_all
• kasan_quarantine_reduce
• __kasan_slab_alloc
• kmem_cache_alloc_noprof
• CONFIG_MEM_ALLOC_PROFILING_DEBUG=Y
• mem_profiling_compressed disabled
• panic_on_warn
• ------------[ cut here ]------------

What your security team should do

• Inventory Linux systems using custom, debug, CI, fuzzing, or hardened kernels, especially those with CONFIG_MEM_ALLOC_PROFILING_DEBUG enabled.
• Prioritize patching systems that combine affected debug memory-allocation profiling options with panic_on_warn or other policies that turn kernel warnings into crashes.
• Monitor vendor kernel advisories and apply the fixed kernel package when available; where package versions are not yet published, track the upstream mm/alloc_tag fix.
• For production systems, avoid running debug kernel configurations unless operationally required.
• Add monitoring for the specific kernel warning strings so affected hosts can be identified before warnings become availability incidents.
• Review boot and kernel logs on development and test fleets for recurrence after patching.