In the Linux kernel, the following vulnerability has been resolved:
bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()
bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below:
unreferenced object 0xffff88812628c8c0 (size 32): comm "swapper/0", pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30
That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated.
Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to check whether the iteration is complete and still use "nr_bits > 64" to indicate whether bits are dynamically allocated. The "!nr_bits" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits.
Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.
| Product | Vendor Advisory | Solution File | Added | Published |
|---|---|---|---|---|
| Debian | — | Upgrade linux | Jul 27, 2026 | Jul 27, 2026 |
| Redhat_linux | — | No solution exists | Jul 9, 2025 | Nov 9, 2024 |
| Ubuntu | — | Upgrade linux-image-genericUpgrade linux-image-azureUpgrade linux-image-oem-24.04Upgrade linux-image-6.11.0-18-genericUpgrade linux-image-generic-64kUpgrade linux-image-oracleUpgrade linux-image-6.11.0-18-generic-64kUpgrade linux-image-raspiUpgrade linux-image-realtimeUpgrade linux-image-6.11.0-1009-azure-fdeUpgrade linux-image-6.11.0-1010-lowlatency-64kUpgrade linux-image-lowlatency-64kUpgrade linux-image-6.11.0-1009-awsUpgrade linux-image-6.11.0-1008-raspiUpgrade linux-image-gcpUpgrade linux-image-azure-fdeUpgrade linux-image-oracle-64kUpgrade linux-image-6.11.0-1015-oemUpgrade linux-image-oem-24.04bUpgrade linux-image-6.11.0-1010-lowlatencyUpgrade linux-image-realtime-hwe-24.04Upgrade linux-image-oem-24.04aUpgrade linux-image-virtual-hwe-24.04Upgrade linux-image-6.11.0-1009-azureUpgrade linux-image-6.11.0-1011-oracle-64kUpgrade linux-image-virtualUpgrade linux-image-awsUpgrade linux-image-6.11.0-1005-realtimeUpgrade linux-image-6.11.0-1009-gcpUpgrade linux-image-generic-hwe-24.04Upgrade linux-image-generic-64k-hwe-24.04Upgrade linux-image-6.11.0-1011-oracleUpgrade linux-image-lowlatency | Feb 20, 2025 | Nov 9, 2024 |
With curated Threat Intelligence, you can see which vulnerabilities truly put you at risk, prioritize what matters most, and act before attackers do.
Explore Intelligence Hub