Linux Kernel KASAN Use-After-Free Vulnerability in SLUB Allocator

Vulnerability

A use-after-free vulnerability has been identified in the Linux kernel's SLUB memory allocator. This issue occurs when the CONFIG_SLUB_TINY option is enabled. In this scenario, the kfree_nolock() function calls kasan_slab_free() before defer_free(). On ARM64 systems with Memory Tagging Extension (MTE), kasan_slab_free() alters the memory tag, replacing the original tag with a poison tag. Consequently, when defer_free() attempts to write to the freed object to update the deferred free list, the pointer retains the old tag, leading to a tag mismatch. This mismatch triggers a KASAN (Kernel Address Sanitizer) use-after-free error, indicating that freed memory is being accessed incorrectly.

Impact

Exploitation of this vulnerability causes a KASAN use-after-free error, which can disrupt normal kernel operations and potentially be exploited to execute arbitrary code or cause a denial-of-service condition.

Reproduction

To reproduce this vulnerability, compile the Linux kernel with the CONFIG_SLUB_TINY option enabled. Once the kernel is running, allocate memory using the SLUB allocator, and then free it using the kfree_nolock() function. This will trigger the kasan_slab_free() call, which poisons the memory and changes the tag. Afterward, invoke the defer_free() function, which will attempt to access the freed memory. The old tag will still be present, causing a tag mismatch and generating a KASAN use-after-free report.

Remediation

The vulnerability has been addressed by modifying the defer_free() function to reset the KASAN tag before accessing the freed memory. This change is safe because defer_free() is part of the memory allocator's internal management and is expected to handle freed memory for bookkeeping purposes.

Added: Jan 14, 2026, 3:52 PM
Updated: Jan 14, 2026, 5:02 PM

Vulnerability Rating

Custom Algorithm
spread
9.0
impact
2.5
exploitability
3.9
remediation
7.7
relevance
2.1
threat
4.8
urgency
2.9
incentive
0.0

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.