In the Linux kernel, the following vulnerability has been resolved:
proc: fix UAF in procgetinode()
Fix race between rmmod and /proc/XXX's inode instantiation.
The bug is that pde->procops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless usepde/unuse_pde() pair has been used.
usepde/unusepde can be avoided (2 atomic ops!) because pde->procops never changes so information necessary for inode instantiation can be saved _before procregister() in PDE itself and used later, avoiding pde->procops->... dereference.
rmmod lookup
sysdeletemodule proclookupde pdeget(de); procgetinode(dir->isb, de); mod->exit() procremove removeprocsubtree procentryrundown(de); freemodule(mod);
if (S_ISREG(inode->i_mode))
if (de->proc_ops->proc_read_iter)
--> As module is already freed, will trigger UAF
BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:procgetinode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proclookupde+0x11f/0x2e0 _lookupslow+0x188/0x350 walkcomponent+0x2ab/0x4f0 pathlookupat+0x120/0x660 filenamelookup+0x1ce/0x560 vfsstatx+0xac/0x150 _dosysnewstat+0x96/0x110 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e
[adobriyan@gmail.com: don't do 2 atomic ops on the common path]