CVE-2026-23147: Linux Kernel Memory Leak Vulnerability

CVE-2026-23147 Overview

A memory leak vulnerability has been discovered in the Linux kernel's Btrfs filesystem implementation, specifically affecting the zlib compression component when using S390 hardware acceleration. The vulnerability occurs in the copy_data_into_buffer() function where a folio (page cache structure) is not properly released after use, leading to a resource leak that can cause system instability over time.

The issue was introduced in commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation"), which refactored the S390x hardware acceleration buffer preparation code. While the refactored code improved readability, it inadvertently removed the critical folio_put() call that releases the filemap folio returned by btrfs_compress_filemap_get_folio().

Critical Impact
Systems using Btrfs with zlib compression on S390 architecture with hardware acceleration enabled may experience gradual memory exhaustion due to unreleased page cache folios, potentially leading to system instability or denial of service conditions.

Affected Products

Linux Kernel (versions with the affected commit in the Btrfs zlib S390 hardware acceleration path)
S390/S390x architecture systems using Btrfs filesystem with zlib compression
Linux distributions running affected kernel versions on IBM Z systems

Discovery Timeline

2026-02-14 - CVE CVE-2026-23147 published to NVD
2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23147

Vulnerability Analysis

This vulnerability is a Memory Leak in the Linux kernel's Btrfs filesystem subsystem. The root cause lies in improper resource management during zlib compression operations on S390 hardware-accelerated systems.

When Btrfs performs file compression using zlib on S390 systems with hardware acceleration, it retrieves folios (page cache structures) via btrfs_compress_filemap_get_folio(). Before the problematic refactoring commit, the code correctly released each folio by calling kunmap_local() and folio_put() after processing. The refactored implementation, while cleaner and easier to understand, failed to include the essential folio_put() call within the copy_data_into_buffer() function.

The impact manifests as a gradual accumulation of unreleased page cache memory. Each compression operation on affected systems leaks the folio reference, preventing the kernel from reclaiming that memory. Over time, particularly on systems with heavy Btrfs write activity using zlib compression, this can exhaust available memory resources.

Root Cause

The memory leak stems from incomplete refactoring of the S390x hardware acceleration code path in Btrfs zlib compression. The original implementation handled folio release at the beginning of each loop iteration with additional cleanup logic outside the loop. When this code was refactored for improved readability, the critical folio_put() call was omitted from the copy_data_into_buffer() function, leaving folio references dangling after each compression operation.

Attack Vector

This vulnerability requires local access to a system running an affected Linux kernel on S390 architecture with Btrfs filesystem configured to use zlib compression and hardware acceleration enabled. An attacker with write access to a Btrfs-mounted filesystem could potentially trigger repeated compression operations to accelerate memory exhaustion, though this is primarily a stability and availability concern rather than a direct exploitation vector.

The vulnerability can be triggered through normal filesystem operations involving data compression, meaning it may occur organically on affected systems without malicious intent.

Detection Methods for CVE-2026-23147

Indicators of Compromise

Gradual increase in kernel memory usage on S390 systems running Btrfs with zlib compression
Growing MemUsed values in /proc/meminfo without corresponding user-space memory allocation
Page cache statistics showing abnormally high folio counts that persist after file operations complete
System logs indicating memory pressure on systems with sufficient physical RAM

Detection Strategies

Monitor kernel memory allocation patterns on S390 systems using Btrfs with zlib compression
Implement memory usage alerting thresholds specific to page cache growth rates
Use kernel tracing (ftrace) to monitor btrfs_compress_filemap_get_folio() calls versus corresponding folio_put() releases
Review system memory statistics periodically for unexpected growth patterns on affected architectures

Monitoring Recommendations

Deploy memory monitoring solutions that track kernel-space allocations separately from user-space
Configure alerts for sustained memory growth on S390 Btrfs systems
Establish baseline memory usage patterns for comparison after kernel updates
Monitor /proc/meminfo and /proc/vmstat for signs of folio accumulation

How to Mitigate CVE-2026-23147

Immediate Actions Required

Apply the kernel patches provided in the official kernel git commits
Consider temporarily disabling S390 hardware acceleration for Btrfs zlib compression on affected systems
Reboot affected systems after patching to release accumulated leaked memory
Review Btrfs mount options and compression settings on S390 infrastructure

Patch Information

The fix adds the missing folio_put() call to the copy_data_into_buffer() function, ensuring proper release of filemap folios after use in the S390 hardware acceleration path.

Official patches are available through the kernel git repository:

System administrators should update to a kernel version containing these fixes through their distribution's package management system.

Workarounds

Disable S390 hardware acceleration for zlib compression by using software-only compression paths where supported
Consider switching to alternative compression algorithms (lzo, zstd) that may not use the affected code path on S390 systems
Implement scheduled reboots on affected systems to periodically clear accumulated leaked memory until patching is complete
Reduce write activity to Btrfs filesystems using zlib compression on affected S390 systems during the interim period

bash

# Check current Btrfs compression settings
btrfs property get /mount/point compression

# Remount with alternative compression (if acceptable)
mount -o remount,compress=zstd /mount/point

# Monitor memory usage on affected systems
watch -n 60 'cat /proc/meminfo | grep -E "MemTotal|MemFree|Cached|Buffers"'