CVE-2025-37807

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix kmemleak warning for percpu hashmap<br /> <br /> Vlad Poenaru reported the following kmemleak issue:<br /> <br /> unreferenced object 0x606fd7c44ac8 (size 32):<br /> backtrace (crc 0):<br /> pcpu_alloc_noprof+0x730/0xeb0<br /> bpf_map_alloc_percpu+0x69/0xc0<br /> prealloc_init+0x9d/0x1b0<br /> htab_map_alloc+0x363/0x510<br /> map_create+0x215/0x3a0<br /> __sys_bpf+0x16b/0x3e0<br /> __x64_sys_bpf+0x18/0x20<br /> do_syscall_64+0x7b/0x150<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Further investigation shows the reason is due to not 8-byte aligned<br /> store of percpu pointer in htab_elem_set_ptr():<br /> *(void __percpu **)(l-&gt;key + key_size) = pptr;<br /> <br /> Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size<br /> is 4, that means pptr is stored in a location which is 4 byte aligned but<br /> not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based<br /> on 8 byte stride, so it won&amp;#39;t detect above pptr, hence reporting the memory<br /> leak.<br /> <br /> In htab_map_alloc(), we already have<br /> <br /> htab-&gt;elem_size = sizeof(struct htab_elem) +<br /> round_up(htab-&gt;map.key_size, 8);<br /> if (percpu)<br /> htab-&gt;elem_size += sizeof(void *);<br /> else<br /> htab-&gt;elem_size += round_up(htab-&gt;map.value_size, 8);<br /> <br /> So storing pptr with 8-byte alignment won&amp;#39;t cause any problem and can fix<br /> kmemleak too.<br /> <br /> The issue can be reproduced with bpf selftest as well:<br /> 1. Enable CONFIG_DEBUG_KMEMLEAK config<br /> 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.<br /> The purpose is to keep map available so kmemleak can be detected.<br /> 3. run &amp;#39;./test_progs -t for_each/hash_map &amp;&amp;#39; and a kmemleak should be reported.