| From bippy-1.2.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-37807: bpf: Fix kmemleak warning for percpu hashmap |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| bpf: Fix kmemleak warning for percpu hashmap |
| |
| Vlad Poenaru reported the following kmemleak issue: |
| |
| unreferenced object 0x606fd7c44ac8 (size 32): |
| backtrace (crc 0): |
| pcpu_alloc_noprof+0x730/0xeb0 |
| bpf_map_alloc_percpu+0x69/0xc0 |
| prealloc_init+0x9d/0x1b0 |
| htab_map_alloc+0x363/0x510 |
| map_create+0x215/0x3a0 |
| __sys_bpf+0x16b/0x3e0 |
| __x64_sys_bpf+0x18/0x20 |
| do_syscall_64+0x7b/0x150 |
| entry_SYSCALL_64_after_hwframe+0x4b/0x53 |
| |
| Further investigation shows the reason is due to not 8-byte aligned |
| store of percpu pointer in htab_elem_set_ptr(): |
| *(void __percpu **)(l->key + key_size) = pptr; |
| |
| Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size |
| is 4, that means pptr is stored in a location which is 4 byte aligned but |
| not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based |
| on 8 byte stride, so it won't detect above pptr, hence reporting the memory |
| leak. |
| |
| In htab_map_alloc(), we already have |
| |
| htab->elem_size = sizeof(struct htab_elem) + |
| round_up(htab->map.key_size, 8); |
| if (percpu) |
| htab->elem_size += sizeof(void *); |
| else |
| htab->elem_size += round_up(htab->map.value_size, 8); |
| |
| So storing pptr with 8-byte alignment won't cause any problem and can fix |
| kmemleak too. |
| |
| The issue can be reproduced with bpf selftest as well: |
| 1. Enable CONFIG_DEBUG_KMEMLEAK config |
| 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. |
| The purpose is to keep map available so kmemleak can be detected. |
| 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported. |
| |
| The Linux kernel CVE team has assigned CVE-2025-37807 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Fixed in 6.12.26 with commit 7758e308aeda1038aba1944f7302d34161b3effe |
| Fixed in 6.14.5 with commit 1f1c29aa1934177349c17e3c32e68ec38a7a56df |
| Fixed in 6.15 with commit 11ba7ce076e5903e7bdc1fd1498979c331b3c286 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2025-37807 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| kernel/bpf/hashtab.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe |
| https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df |
| https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286 |
