Date: Wed, 19 Feb 2003 17:01:35 -0800 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: Yevgeniy Aleynikov <eugenea@infospace.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: <200302200101.h1K11ZFL056229@beastie.mckusick.com> In-Reply-To: Your message of "Wed, 19 Feb 2003 15:10:09 PST." <3E540ED1.6090605@infospace.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?200302200101.h1K11ZFL056229>