NetBSD Problem Report #38219

From martin@duskware.de  Tue Mar 11 14:42:08 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 4B18A63B8E3
	for <gnats-bugs@gnats.netbsd.org>; Tue, 11 Mar 2008 14:42:08 +0000 (UTC)
Message-Id: <20080311121933.B6B4763B8E3@narn.NetBSD.org>
Date: Tue, 11 Mar 2008 12:19:33 +0000 (UTC)
From: pooka@iki.fi
Reply-To: pooka@iki.fi
To: netbsd-bugs-owner@NetBSD.org
Subject: tmpfs rename locking meltdown
X-Send-Pr-Version: www-1.0

>Number:         38219
>Category:       kern
>Synopsis:       tmpfs rename locking meltdown
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 11 14:45:00 +0000 2008
>Closed-Date:    Sun Feb 08 16:51:17 +0000 2009
>Last-Modified:  Mon Feb 16 03:30:02 +0000 2009
>Originator:     Antti Kantee
>Release:        
>Organization:
>Environment:
>Description:
Due to recent changes to tmpfs_rename in current, it is easy to fool
rename to try to lock against itself.

No NetBSD release is vulnerable to the local panic DoS.
>How-To-Repeat:
cd /tmpfs ; mkdir foo foo/bar ; rename foo/bar foo
(HOX! rename, not mv(1))
>Fix:
Either a) add more indecipherable checks which break down with every
change that hasn't been meditated upon for 10 years or b) fix rename
over all file systems so that it's actually possible for a human to
implement it right.  "a" is trivial and "b" might be slightly more
difficult.

>Release-Note:

>Audit-Trail:
From: Antti Kantee <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38219 CVS commit: src/sys/fs/tmpfs
Date: Sat,  7 Feb 2009 19:42:57 +0000 (UTC)

 Module Name:	src
 Committed By:	pooka
 Date:		Sat Feb  7 19:42:57 UTC 2009

 Modified Files:
 	src/sys/fs/tmpfs: tmpfs_vnops.c

 Log Message:
 If fdvp is tvp, do nothing.  Prevents local DoS panic described in
 PR kern/38219... maybe.  This is hastily concocted fix for 5.0 and
 I'm not sure if it has side-effects.


 To generate a diff of this commit:
 cvs rdiff -r1.52 -r1.53 src/sys/fs/tmpfs/tmpfs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Sun, 08 Feb 2009 18:51:17 +0200
State-Changed-Why:
most likely fixed (at least until someone breaks it again)


From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38219 CVS commit: [netbsd-5] src/sys/fs/tmpfs
Date: Mon, 16 Feb 2009 03:29:01 +0000 (UTC)

 Module Name:	src
 Committed By:	snj
 Date:		Mon Feb 16 03:29:01 UTC 2009

 Modified Files:
 	src/sys/fs/tmpfs [netbsd-5]: tmpfs_vnops.c

 Log Message:
 Pull up following revision(s) (requested by pooka in ticket #432):
 	sys/fs/tmpfs/tmpfs_vnops.c: revision 1.53
 If fdvp is tvp, do nothing.  Prevents local DoS panic described in
 PR kern/38219... maybe.  This is hastily concocted fix for 5.0 and
 I'm not sure if it has side-effects.


 To generate a diff of this commit:
 cvs rdiff -r1.51 -r1.51.6.1 src/sys/fs/tmpfs/tmpfs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search