{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-40028", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-40028" ], "published": "2025-10-28T09:32:47Z", "summary": "binder: fix double-free in dbitmap", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix double-free in dbitmap\n\nA process might fail to allocate a new bitmap when trying to expand its\nproc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap\nvia dbitmap_free(). However, the driver calls dbitmap_free() again when\nthe same process terminates, leading to a double-free error:\n\n ==================================================================\n BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c\n Free of addr ffff00000b7c1420 by task kworker/9:1/209\n\n CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n Workqueue: events binder_deferred_func\n Call trace:\n kfree+0x164/0x31c\n binder_proc_dec_tmpref+0x2e0/0x55c\n binder_deferred_func+0xc24/0x1120\n process_one_work+0x520/0xba4\n [...]\n\n Allocated by task 448:\n __kmalloc_noprof+0x178/0x3c0\n bitmap_zalloc+0x24/0x30\n binder_open+0x14c/0xc10\n [...]\n\n Freed by task 449:\n kfree+0x184/0x31c\n binder_inc_ref_for_node+0xb44/0xe44\n binder_transaction+0x29b4/0x7fbc\n binder_thread_write+0x1708/0x442c\n binder_ioctl+0x1b50/0x2900\n [...]\n ==================================================================\n\nFix this issue by marking proc->map NULL in dbitmap_free().", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.20-1+rpt1~bpo12+1", "1:6.12.25-1+rpt1", "1:6.12.34-1+rpt1~bookworm", "1:6.12.47-1+rpt1~bookworm" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-2712", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8-rt", "binary_version": "1:6.12.34-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-2712", "binary_version": "1:6.12.47-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-v8", "binary_version": "1:6.12.47-1+rpt1~bookworm" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-v8-rt", "binary_version": "1:6.12.47-1+rpt1~bookworm" } ] }, "database_specific": { "per_version": { "1:6.12.20-1+rpt1~bpo12+1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.25-1+rpt1": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.34-1+rpt1~bookworm": { "linux_commit": "8f77e03530f65209a377d25023e912b288e039cd", "upstream_version": "6.12.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.47-1+rpt1~bookworm": { "linux_commit": "359f37f0faefb712add32a39f98751aea67d5c1f", "upstream_version": "6.12.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.12.19-1+rpt1~bpo12+1", "1:6.12.19-1+rpt1", "1:6.12.20-1+rpt1", "1:6.12.25-1+rpt1+trixie", "1:6.12.34-1+rpt1", "1:6.12.47-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8-rt", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-2712", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.34+rpt-rpi-v8-rt", "binary_version": "1:6.12.34-1+rpt1" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-2712", "binary_version": "1:6.12.47-1+rpt1" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-v8", "binary_version": "1:6.12.47-1+rpt1" }, { "binary_name": "linux-image-6.12.47+rpt-rpi-v8-rt", "binary_version": "1:6.12.47-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.19-1+rpt1~bpo12+1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.19-1+rpt1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.20-1+rpt1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.25-1+rpt1+trixie": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.34-1+rpt1": { "linux_commit": "8f77e03530f65209a377d25023e912b288e039cd", "upstream_version": "6.12.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" }, "1:6.12.47-1+rpt1": { "linux_commit": "359f37f0faefb712add32a39f98751aea67d5c1f", "upstream_version": "6.12.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.52" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-40028" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c301ec61ce6f16e21a36b99225ca8a20c1591e10" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0390633979969c54c0ce6a198d6f45cdbe2c84b1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b781e5635a3398e2b64440371233c2c5102cd6cb" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3ebcd3460cad351f198c39c6edb4af519a0ed934" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only through `ioctl()`/`write()` on a binder character device (`/dev/binder` or a binderfs device node), requiring a local process on the system. There is no remote or network-facing path into `binder_transaction()`.\nAC:L - The attacker fully controls both preconditions: the size of the failing `bitmap_zalloc()` (by creating hundreds of thousands of binder references so the doubling bitmap enters costly-order allocations that fail without invoking the OOM killer) and the memory pressure/fragmentation that makes it fail, then chooses exactly when the second free occurs by closing the fd. The window between the two frees is arbitrarily long, making heap grooming reliable.\nPR:L - Binder contains no `capable()` checks at all on this path; on Android every unprivileged app can open a binder device, and on distro kernels with CONFIG_ANDROID_BINDERFS an unprivileged user can mount binderfs inside a user namespace (`FS_USERNS_MOUNT`) and create devices without any capability. Only a basic local account is needed.\nUI:N - The attacking process performs everything itself \u2014 open the device, drive transactions to grow the bitmap, exhaust memory, then close the fd. No victim action is involved.\nS:U - The corruption is confined to the kernel's own heap/page allocator within the same security authority; there is no VM, IOMMU, or hypervisor boundary crossed.\nC:H - The double free lets the attacker reclaim the chunk with a chosen object and then have the kernel free it while still in use, producing a use-after-free with overlapping allocations that can be leveraged to read arbitrary kernel memory (credentials, keys, KASLR data).\nI:H - Freeing an in-use, attacker-sprayed object (or a costly-order page, giving cross-cache/physical-page reuse) yields a write primitive over kernel objects, enabling control-flow hijack and privilege escalation to root.\nA:H - Even unweaponized, the double free corrupts the SLUB freelist or page allocator and reliably panics the kernel (KASAN reports it as a `double-free` BUG), and the attacker can repeat it across many binder fds." } } }