CVE-2026-23176: Linux Kernel Memory Leak Vulnerability

CVE-2026-23176 Overview

A memory leak vulnerability has been discovered in the Linux kernel's platform/x86/toshiba_haps driver. The vulnerability exists in the toshiba_haps_add() and toshiba_haps_remove() routines, where improper memory management leads to unreachable allocated memory blocks.

The toshiba_haps_add() function leaks the haps object it allocates when the function returns an error after successful allocation. Additionally, toshiba_haps_remove() fails to free the object pointed to by toshiba_haps before clearing the pointer, making that allocated memory unreachable and causing a memory leak.

Critical Impact

Persistent memory leaks in the kernel can lead to resource exhaustion and potential denial of service conditions on systems using Toshiba hardware with the HAPS driver loaded.

Affected Products

• Linux kernel with toshiba_haps driver enabled
• Systems running Toshiba hardware utilizing the HAPS (Hardware Protection System) functionality
• Multiple stable kernel versions prior to the security patch

Discovery Timeline

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

Technical Details for CVE-2026-23176

Vulnerability Analysis

This vulnerability represents a classic memory management flaw in kernel driver code. The toshiba_haps driver, responsible for managing Toshiba's Hardware Protection System functionality on x86 platforms, contains two distinct memory leak paths that can be triggered during normal driver operation.

The first leak occurs in toshiba_haps_add() when the function encounters an error condition after successfully allocating memory for the haps object. In this scenario, the error path fails to deallocate the previously allocated memory before returning, leaving orphaned memory in the kernel heap.

The second leak manifests in toshiba_haps_remove(), where the function clears the pointer to the toshiba_haps object without first freeing the underlying memory. Once the pointer is cleared, the allocated memory becomes unreachable and cannot be reclaimed.

Root Cause

The root cause is improper resource cleanup in error handling paths and driver removal routines. The original code used standard kzalloc() for memory allocation without corresponding kfree() calls in all necessary code paths. This is a common pattern of memory management errors in kernel drivers where manual memory management requires careful attention to all possible execution paths.

The fix addresses this by converting the memory allocation to use devm_kzalloc(), which is a device-managed allocation function. Memory allocated with devm_kzalloc() is automatically freed when the associated device is removed, eliminating the need for explicit cleanup code and preventing these types of memory leaks.

Attack Vector

The attack vector for this vulnerability is primarily local. An attacker with the ability to trigger repeated driver add/remove cycles (such as through device hot-plugging simulation or driver module loading/unloading) could potentially exhaust system memory over time. While the immediate impact of a single leak may be minimal, sustained exploitation could lead to denial of service conditions.

The vulnerability is more likely to be triggered accidentally through normal system operation involving device enumeration failures or driver initialization errors on systems with Toshiba HAPS-compatible hardware.

Detection Methods for CVE-2026-23176

Indicators of Compromise

• Gradual increase in kernel memory usage over time on systems with the toshiba_haps driver loaded
• Kernel memory allocation failures or warnings in system logs
• System instability or performance degradation on affected Toshiba hardware
• Presence of unreferenced slab objects in kernel memory analysis

Detection Strategies

• Monitor kernel memory statistics using /proc/meminfo and /proc/slabinfo for abnormal growth patterns
• Implement kernel memory leak detection tools such as kmemleak to identify orphaned allocations
• Review system logs for memory allocation failures or driver-related error messages
• Use SentinelOne's Linux kernel monitoring capabilities to detect unusual memory consumption patterns

Monitoring Recommendations

• Enable continuous monitoring of kernel memory metrics on systems running the toshiba_haps driver
• Configure alerting for memory usage thresholds that may indicate leak accumulation
• Implement regular system health checks that include kernel memory analysis
• Deploy endpoint detection solutions capable of identifying memory exhaustion attacks

How to Mitigate CVE-2026-23176

Immediate Actions Required

• Update the Linux kernel to a patched version containing the fix
• If updating is not immediately possible, consider blacklisting the toshiba_haps module if not required for system operation
• Monitor affected systems for signs of memory exhaustion
• Review system logs for any driver-related errors that may have triggered the leak

Patch Information

The vulnerability has been resolved by converting memory allocation from standard kzalloc() to device-managed devm_kzalloc(). This ensures automatic memory cleanup when the device is removed, eliminating both leak paths. Multiple kernel stable branches have received the fix:

• Kernel Commit 128497456756
• Kernel Commit 17f37c4cdf42
• Kernel Commit 5bce10f0f943
• Kernel Commit bf0474356875
• Kernel Commit ca9ff71c15bc
• Kernel Commit f2093e87ddec
• Kernel Commit f93ae43780b7

Workarounds

• Blacklist the toshiba_haps module if the HAPS functionality is not required: add blacklist toshiba_haps to /etc/modprobe.d/blacklist.conf
• Implement periodic system reboots as a temporary measure to reclaim leaked memory
• Monitor memory usage and proactively restart systems showing signs of memory pressure
• Consider disabling automatic module loading for the affected driver until patching is complete

# Configuration example
# Blacklist the toshiba_haps module to prevent loading
echo "blacklist toshiba_haps" | sudo tee /etc/modprobe.d/toshiba_haps-blacklist.conf

# If the module is currently loaded, unload it
sudo modprobe -r toshiba_haps

# Verify the module is not loaded
lsmod | grep toshiba_haps

# Update initramfs to apply blacklist on boot
sudo update-initramfs -u