Date: Fri, 21 Feb 2003 14:21:55 -0800 From: Yevgeniy Aleynikov <eugenea@infospace.com> To: Kirk McKusick <mckusick@beastie.mckusick.com> Cc: Matt Dillon <dillon@earth.backplane.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: <3E56A683.5070504@infospace.com> In-Reply-To: <200302200101.h1K11ZFL056229@beastie.mckusick.com> References: <200302200101.h1K11ZFL056229@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As pointed by Ken - we do have alot of file renames (qmail). But 2-nd solution, directory-only rename serialization, probably won't affect performance as much. But i believe it's not only us who's gonna have problem when exploit code will be known by everybody sooner or later.... Thanks! Kirk McKusick wrote: > The potentially slow, but utterly effective way to fix this race > is to only allow one rename at a time per filesystem. It is > implemented by adding a flag in the mount structure and using > it to serialize calls to rename. When only one rename can happen > at a time, the race cannot occur. > > If this proves to be too much of a slow down, it would be possible > to only serialize directory renames. As these are (presumably) much > rarer the slow down would be less noticable. > > Kirk McKusick > > =-=-=-=-=-= > > 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 > X-ASK-Info: Confirmed by User > > 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?3E56A683.5070504>