Date: Wed, 19 Feb 2003 15:10:09 -0800 From: Yevgeniy Aleynikov <eugenea@infospace.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Kirk McKusick <mckusick@mckusick.com>, Ian Dowse <iedowse@maths.tcd.ie>, peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini <kenp@infospace.com>, hackers@FreeBSD.ORG, security-officer@FreeBSD.org, nectar@FreeBSD.org, jedgar@FreeBSD.org, rwatson@FreeBSD.org, imp@FreeBSD.org, security-team@FreeBSD.org, wes@FreeBSD.org, guido@FreeBSD.org Subject: Re: bleh. Re: ufs_rename panic Message-ID: <3E540ED1.6090605@infospace.com> In-Reply-To: <200110080018.f980IQK01299@earth.backplane.com> References: <200110030610.f936AbR11859@beastie.mckusick.com> <3BBE3F7A.98FBC714@infospace.com> <200110080018.f980IQK01299@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just reminder that this problem is local kernel panic DoS (which can do filesystem corruption) with very simple trigger code and it still exists. And it's been almost 2 years since i wrote about it. Workaround (commenting out panic call) doesnt fix the problem. Server still crashes (not so often though) from virtual memory failures like this: panic: vm_fault: fault on nofault entry, addr: d0912000 mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 (kgdb) bt #0 0xc0175662 in dumpsys () #1 0xc017542c in boot () #2 0xc0175894 in poweroff_wait () #3 0xc01e7c18 in vm_fault () #4 0xc0219d32 in trap_pfault () #5 0xc021990b in trap () #6 0xc01e008a in ufs_dirrewrite () #7 0xc01e31a4 in ufs_rename () #8 0xc01e4645 in ufs_vnoperate () #9 0xc01a9121 in rename () #10 0xc021a44d in syscall2 () #11 0xc02077cb in Xint0x80_syscall () How can i help to resolve this problem ASAP? Thanks! Matt Dillon wrote: > Well, I've gone through hell trying to fix the rename()/rmdir()/remove() > races and failed utterly. There are far more race conditions then even > my last posting indicated, and there are *severe* problems fixing NFS > to deal with even Ian's suggestion... it turns out that NFS's nfs_namei() > permanently adjusts the mbuf while processing the path name, making > restarts impossible. > > The only solution is to implement namei cache path locking and formalize > the 'nameidata' structure, which means ripping up a lot of code because > nearly the entire code base currently plays with the contents of > 'nameidata' willy-nilly. Nothing else will work. It's not something > that I can consider doing now. > > In the mean time I am going to remove the panic()'s in question. This > means that in ufs_rename() the machine will silently ignore the race > (not do the rename) instead of panic. It's all that can be done for > the moment. It solve the security/attack issue. We'll have to attack > the races as a separate issue. The patch to remove the panics is utterly > trivial and I will commit it after I test it. > > -Matt > > > -- Yevgeniy Aleynikov | Sr. Systems Engineer - USE InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924 eugene.aleynikov@infospace.com | http://www.infospaceinc.com Discover what you can do.TM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E540ED1.6090605>