CVE-2026-43071

In the Linux kernel, the following vulnerability has been resolved:

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentry_hashtable when user sets

'dhash_entries=1':

BUG: unable to handle page fault for address: ffff888b30b774b0

#PF: supervisor read access in kernel mode

#PF: error_code(0x0000) - not-present page

Oops: Oops: 0000 [#1] SMP PTI

RIP: 0010:__d_lookup+0x56/0x120

Call Trace:

d_lookup.cold+0x16/0x5d

lookup_dcache+0x27/0xf0

lookup_one_qstr_excl+0x2a/0x180

start_dirop+0x55/0xa0

simple_start_creating+0x8d/0xa0

debugfs_start_creating+0x8c/0x180

debugfs_create_dir+0x1d/0x1c0

pinctrl_init+0x6d/0x140

do_one_initcall+0x6d/0x3d0

kernel_init_freeable+0x39f/0x460

kernel_init+0x2a/0x260

There will be only one bucket in dentry_hashtable when dhash_entries is

set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,

following process will access more than one buckets(which memory region

is not allocated) in dentry_hashtable:

d_lookup

b = d_hash(hash)

dentry_hashtable + ((u32)hashlen >> d_hash_shift)

// The C standard defines the behavior of right shift amounts

// exceeding the bit width of the operand as undefined. The

// result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen',

// so 'b' will point to an unallocated memory region.

hlist_bl_for_each_entry_rcu(b)

hlist_bl_first_rcu(head)

h->first // read OOB!

Fix it by limiting the minimal number of dentry_hashtable bucket to two,

so that 'd_hash_shift' won't exceeds the bit width of type u32.