CVE-2026-98776: binderfs: fix UAF write in binder_add_device
In the Linux kernel, the following vulnerability has been resolved:
binderfs: fix UAF write in binderadddevice
binderfsbinderdevicecreate() publishes the new dentry with dmakepersistent() and then calls simpledonecreating(), which drops the parent directory lock and the creator's dentry reference. It then calls binderadddevice() to register the device in the global binderdevices list.
After simpledonecreating() releases the parent directory lock, a concurrent unlinkat() can remove the new device entry. Dropping the creator's dentry reference can then trigger binderfsevictinode(), freeing the device. binderadddevice() later accesses the freed object, causing UAF write.
Found by a modified Syzkaller:
BUG: KASAN: slab-use-after-free in hlistaddhead include/linux/list.h:1073 [inline] BUG: KASAN: slab-use-after-free in binderadddevice+0xa9/0xc0 drivers/android/binder.c:7068 Write of size 8 at addr ffff88805b340c00 by task syz.1.532/11389
CPU: 0 UID: 0 PID: 11389 Comm: syz.1.532 Not tainted 7.2.0 #4 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x10e/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xf7/0x600 mm/kasan/report.c:482 kasanreport+0xe4/0x120 mm/kasan/report.c:595 hlistaddhead include/linux/list.h:1073 [inline] binderadddevice+0xa9/0xc0 drivers/android/binder.c:7068 binderfsbinderdevicecreate.isra.0+0x724/0x990 drivers/android/binderfs.c:196 binderctlioctl+0x186/0x1b0 drivers/android/binderfs.c:241 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x116/0x800 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7ff9027a833d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ff903674018 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ff902a35fa0 RCX: 00007ff9027a833d RDX: 0000200000000500 RSI: 00000000c1086201 RDI: 0000000000000004 RBP: 00007ff902850733 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ff902a36038 R14: 00007ff902a35fa0 R15: 00007ffd7166bfa0 </TASK>
Allocated by task 11389: kasansavestack+0x33/0x60 mm/kasan/common.c:57 kasansavetrack+0x14/0x30 mm/kasan/common.c:78 poisonkmallocredzone mm/kasan/common.c:398 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasankmalloc include/linux/kasan.h:263 [inline] kmalloccachenoprof+0x2e4/0x6f0 mm/slub.c:5489 kmallocnoprof include/linux/slab.h:988 [inline] kzallocnoprof include/linux/slab.h:1309 [inline] binderfsbinderdevicecreate.isra.0+0x17a/0x990 drivers/android/binderfs.c:148 binderctlioctl+0x186/0x1b0 drivers/android/binderfs.c:241 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x116/0x800 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 11389: kasansavestack+0x33/0x60 mm/kasan/common.c:57 kasansavetrack+0x14/0x30 mm/kasan/common.c:78 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:253 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:285 kasanslabfree include/linux/kasan.h:235 [inline] slabfreehook mm/slub.c:2677 [inline] slabfree mm/slub.c:6377 [inline] kfree+0x2fc/0x6e0 mm/slub.c:6692 binderf ---truncated---
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
A binderfs device must be created, and a concurrent unlinkat() must remove that newly created device entry after simple_done_creating() releases the parent directory lock but before binder_add_device() registers it in the global device list.
Who can realistically reach the vulnerable code path?
The triggering process shown in the report ran as UID 0. The provided data does not establish whether unprivileged users can create or unlink binderfs device entries in a particular deployment.
What is the observable failure mode?
The kernel performs a use-after-free write when binder_add_device() accesses a device object that was freed during binderfs inode eviction. The reported KASAN trace identifies the write in hlist_add_head called by binder_add_device().
How can administrators determine whether they may be exposed?
Review whether binderfs is in use and whether processes can create binderfs device entries while other processes can concurrently unlink them. Kernel memory-safety diagnostics may report a KASAN slab-use-after-free involving binder_add_device() and hlist_add_head.