Linux vulnerability

What happened

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.

Affected versions

Linux: 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before 45b06bb5ea96f75ad81d7ef446f832ea6b0026fe (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before 426ef05e82ee52c8d0e95fc0808b7383d8352d73 (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before ddd57ebce245f9c7e2f6902a6c087d6186d2385d (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before 755b40903eff563768d4d96fd4ef51ec48adde3b (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before 5718df131ab78897a9dd1f2e71c3ba732d4392af (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before 277cedabb0ab86baae83fa58218be13c6d3e5526 (git); 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 through before f08fe8891c3eeb63b73f9f1f6d97aa629c821579 (git); d4c96061fddd129778ce8b70fb093aa532f422d0 (git); be2378cbffe50ce0161f0fdee914adee98af53dc (git); a8be8af18485f9fade90e1743d940252a39eec84 (git); b5cf3193759f7cd1cfbeef11f5cf067bbce22e55 (git); 3.10.55 through before 3.11 (semver); 3.12.29 through before 3.13 (semver); 3.14.19 through before 3.15 (semver); 3.16.3 through before 3.17 (semver); 3.17; V3.1.6 through before * (custom) Fixed: See vendor advisory.

Why it matters

Review the vendor advisory and exposure of the affected product to determine operational impact.

Detection & mitigation

• Apply vendor-provided updates or mitigations.
• Review affected product exposure and access logs.