CVE-2026-43071

What it actually does

CVE-2026-43071 is an out-of-bounds read in the Linux kernel dcache subsystem. When the kernel is booted with the dentry hash table size forced to a single bucket using dhash_entries=1, dcache initialization can calculate an invalid d_hash_shift value. Later pathname lookup operations may compute a bucket pointer outside the allocated dentry_hashtable and dereference it in kernel context. The observed result is a kernel page fault/oops during filesystem or debugfs-related initialization and lookup paths, with potential information exposure from unintended kernel memory reads and a high likelihood of denial of service through kernel crash or instability. Practical exploitation depends on the ability to influence kernel boot parameters or otherwise run a vulnerable kernel with this unsafe configuration.

Why it matters to the business

Affected Linux systems can become unstable or crash if booted with the vulnerable dcache configuration, potentially causing service outages, failed boots, interrupted workloads, and recovery effort for servers, appliances, containers hosts, or embedded systems that rely on the affected kernel. Although the EPSS score is low and there is no known CISA KEV listing or reported ransomware use, the high CVSS score reflects serious impact if the vulnerable condition is reachable, especially for systems where kernel boot parameters are centrally managed, templated, or exposed through virtualization, provisioning, or appliance configuration workflows.

How an attack unfolds

An attacker first needs a path to cause the system to boot a vulnerable Linux kernel with dhash_entries set to 1, such as control over kernel command-line parameters, bootloader configuration, provisioning images, hypervisor or appliance boot settings, or another administrative configuration channel. After the system starts, normal filesystem activity triggers dcache lookups. Because the dentry hash table contains only one bucket, the kernel computes a shift value that can exceed the width of a 32-bit operand. During d_lookup and related functions, the computed bucket pointer can reference memory beyond the allocated dentry_hashtable. The kernel then attempts to read from that invalid location, commonly producing a page fault or oops in kernel mode. The most likely end result is denial of service through crash, boot failure, or system instability; any confidentiality impact would depend on whether the out-of-bounds read can be made observable, which is not indicated by the available public details. No public exploit maturity or known in-the-wild exploitation is currently reported.

How to fix it

Upgrade to a Linux kernel version that includes the upstream dcache fix limiting the minimum number of dentry_hashtable buckets to two. No exact fixed package versions were provided in the input, so use the fixed kernel packages published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel branch maintainer. As an immediate mitigation, ensure systems are not booted with dhash_entries=1 and remove that parameter from bootloader, kernel command-line, PXE, image build, appliance, or virtualization configuration. Where possible, restrict administrative access to boot parameter management and enforce configuration baselines that prevent unsafe kernel command-line options. Reboot is required after installing a fixed kernel or changing kernel boot parameters.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the dcache bucket minimum fix. Verify that the active kernel command line does not include dhash_entries=1 by checking /proc/cmdline. Review persistent bootloader and provisioning configuration, including GRUB, systemd-boot, PXE, cloud image templates, appliance profiles, and hypervisor kernel-argument settings, to ensure the unsafe parameter is absent. After remediation, reboot into the fixed kernel and confirm the system remains stable during boot and normal filesystem activity. Validate package state using the distribution’s package manager and compare the installed kernel against the vendor advisory or changelog for this vulnerability.

Typical attack path

1. Gain the ability to modify or influence Linux kernel boot parameters or boot configuration.
2. Configure the affected kernel to boot with dhash_entries=1.
3. Reboot or cause the target system to start with the unsafe dcache hash table size.
4. Allow or trigger normal filesystem activity that performs dentry lookup operations, such as initialization, debugfs creation, or pathname lookups.
5. The vulnerable kernel calculates an invalid dentry hash bucket pointer and performs an out-of-bounds read.
6. The system experiences a kernel oops, panic, failed boot, or instability, resulting in denial of service.

How to detect it

To determine whether this issue was already triggered, review kernel logs, crash dumps, and boot history for evidence of systems running with dhash_entries=1 followed by kernel page faults or oops events in dcache lookup paths. Primary sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, crashkernel output, serial console logs, hypervisor console logs, and centralized logging from Linux hosts. Look for boot command lines containing dhash_entries=1 and kernel traces referencing __d_lookup, d_lookup, lookup_dcache, dentry_hashtable, d_hash_shift, debugfs_create_dir, or pinctrl_init. Also search bootloader and provisioning artifacts for the unsafe parameter to identify systems that may have been exposed even if they have not crashed. There are no known public threat actors, ransomware campaigns, or mature exploit artifacts associated with this vulnerability in the provided intelligence, so detection should focus on configuration exposure and crash artifacts rather than attacker-specific indicators.

• dhash_entries=1
• BUG: unable to handle page fault for address
• supervisor read access in kernel mode
• Oops: 0000
• RIP: 0010:__d_lookup
• __d_lookup+0x56/0x120
• d_lookup.cold
• lookup_dcache
• lookup_one_qstr_excl
• debugfs_start_creating
• debugfs_create_dir
• pinctrl_init
• dentry_hashtable
• d_hash_shift
• /proc/cmdline
• /boot/grub/grub.cfg
• /etc/default/grub

What your security team should do

• Prioritize patching Linux systems where kernel boot parameters are centrally managed, exposed through appliance settings, or modified by automation, because a single bad template can propagate the vulnerable configuration widely.
• Search configuration management, image build pipelines, bootloader files, and provisioning templates for dhash_entries=1 and remove it immediately.
• Upgrade affected Linux kernels to vendor-fixed releases and schedule required reboots through normal change windows, with expedited handling for critical infrastructure and externally managed appliances.
• Monitor kernel logs for oops, page faults, or crashes involving __d_lookup, d_lookup, dentry_hashtable, dcache_init, or debugfs initialization paths.
• Restrict who can modify bootloader entries, kernel command-line parameters, PXE profiles, and VM or appliance boot settings.
• Because EPSS is currently low, not in KEV, and no public exploit maturity is reported, treat this as a high-impact hardening and reliability issue unless local evidence shows exposed boot-parameter control or crash activity.