Re: use-after-free in inodedep_lookup() (Re: Panic: Memory modified after free)

On Sat, Feb 05, 2005 at 03:37:34PM -0800, Kris Kennaway wrote:
> On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote:
> 
> > Anyway, it panicked shortly after starting to exercise the FS, with:
> > 
> > login: panic: mutex  not owned at ../../../vm/vm_page.c:301
> > cpuid = 1
> > KDB: enter: panic
> > [thread pid 717 tid 100147 ]
> > Stopped at      kdb_enter+0x30: leave
> > db> tr
> > Tracing pid 717 tid 100147 td 0xc7f27a10
> > kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30
> > panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e
> > _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c
> > vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d
> > vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3
> > trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166
> > trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c
> > calltrap() at calltrap+0x5
> > --- trap 0xc, eip = 0xc063af4a, esp = 0xeeca0b44, ebp = 0xeeca0b60 ---
> > inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143
> 
> (kgdb) list *(inodedep_lookup+0x143)
> 0xc063c362 is in inodedep_lookup (../../../ufs/ffs/ffs_softdep.c:887).
> 882             if (inodedep_find(inodedephd, fs, inum, inodedeppp)) {
> 883                     FREE(inodedep, M_INODEDEP);
> 884                     return (1);
> 885             }
> 886             num_inodedep += 1;
> 887             inodedep->id_list.wk_type = D_INODEDEP;
> 888             inodedep->id_fs = fs;
> 889             inodedep->id_ino = inum;
> 890             inodedep->id_state = ALLCOMPLETE;
> 891             inodedep->id_nlinkdelta = 0;
> 
> This looks like a use-after-free of the inodedep.
> 
> Kris

   To elaborate a bit: the inodedep deref on line 887 triggers a fault
   because MemGuard has protected the page but the fault handling code
   panics while attempting to assert that the underlying object's mutex
   is owned.  The assertion is triggered as the mutex is not owned
   presumably because the object has been freed (it might be cached
   somewhere which explains why the deref of it did not trigger a second
   fault).

> > softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softdep_change_linkcnt+0x4f
> > ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153
> > ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60
> > VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78
> > kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186
> > unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22
> > syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4
> > Xint0x80_syscall() at Xint0x80_syscall+0x1f
> > --- syscall (10, FreeBSD ELF32, unlink), eip = 0x280c5b63, esp = 0xbfbfec2c, ebp = 0xbfbfec58 ---
> > 
> > I don't know if this is a memguard bug or a FreeBSD bug.
> > 
> > Kris


-- 
Bosko Milekic
bmilekic_at_technokratis.com
bmilekic_at_FreeBSD.org