CVE-2026-23032

What it actually does

The flaw is a memory leak in the Linux kernel null_blk driver (when CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled): references to the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items under each nullbX group are never released when the device is removed, producing kmemleak reports of unreferenced objects allocated via kvasprintf/config_item_set_name.

Why it matters to the business

Repeated creation and removal of null_blk devices in fault-injection test or CI environments causes gradual kernel memory exhaustion, risking system instability or out-of-memory conditions in long-running test farms or development setups that rely on this driver.

How an attack unfolds

An attacker or automated test harness repeatedly issues mkdir operations under the nullb configfs tree to instantiate null_blk devices with fault injection enabled, then removes the devices; each cycle leaks the fault-config configfs items because their references are not dropped when the parent group reference is released.

How to fix it

Upgrade the Linux kernel to a version containing commit 1a3286edf4d48ce37f8982ff3c3b65159a5ecbb2 (or later stable equivalent) which explicitly releases references to the fault-config configfs items when the nullbX group reference is dropped; for gomplate-fips (MinimOS) upgrade to 4.3.3-r5.

How to confirm the fix worked

After patching, create and remove multiple null_blk devices with fault injection enabled, then run kmemleak scan and confirm absence of unreferenced objects whose names begin with timeout_inject, requeue_inject, or init_hctx_fault_inject.

Typical attack path

1. Mount configfs and enable null_blk fault injection via module parameters
2. Repeatedly create nullbX groups and their child fault inject items via mkdir
3. Remove the nullbX devices (rmdir or device deletion)
4. Observe accumulating unreferenced objects via kmemleak scan
5. Continue until memory pressure or OOM occurs

How to detect it

Scan kernel logs and kmemleak output for messages containing unreferenced object together with names such as init_hctx_fault_inject, timeout_inject or requeue_inject; inspect processes performing repeated configfs_mkdir operations under nullb groups.

• init_hctx_fault_inject
• timeout_inject
• requeue_inject
• fault_config_init
• unreferenced object .* config_item_set_name

What your security team should do

• Apply the referenced kernel commit or distribution update on all systems that enable null_blk fault injection
• Add kmemleak monitoring to CI pipelines that exercise null_blk
• Limit use of null_blk fault injection to short-lived test containers or VMs where leaks have bounded impact