NetBSD Problem Report #3786

Received: (qmail 2454 invoked from network); 24 Jun 1997 20:50:55 -0000
Message-Id: <199706242046.WAA00486@lemming.swb.de>
Date: Tue, 24 Jun 1997 22:46:04 +0200 (MEST)
From: Michael van Elst <mlelstv@serpens.swb.de>
Reply-To: mlelstv@serpens.swb.de
To: gnats-bugs@gnats.netbsd.org
Subject: adosfs silently aborts a readdir() on a corrupted directory
X-Send-Pr-Version: 3.95

>Number:         3786
>Category:       lib
>Synopsis:       adosfs silently aborts a readdir() on a corrupted directory
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          analyzed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 24 14:05:01 +0000 1997
>Closed-Date:    
>Last-Modified:  Wed Jul 05 14:38:41 +0000 2000
>Originator:     Michael van Elst
>Release:        NetBSD-current 20 June 1997
>Organization:
dis-
>Environment:
Amiga A3000/060, NetBSD-current, adosfs
System: NetBSD lemming 1.2G NetBSD 1.2G (LEMMING) #10: Sun Jun 22 21:26:36 MEST 1997 root@lemming:/usr/src/sys/arch/amiga/compile/LEMMING amiga


>Description:
	adosfs_readdir traverses a directory hash table and associated
	hash chains. When encountering an invalid meta block then adosfs_vget()
	returns an error and the readdir loop is aborted. No data is
	returned by readdir().

	As a result it is possible and likely that a directory is listed
	as empty (ls doesn't even show an error, maybe a ls or fts bug ?)
	but files and directories in this corrupted directory can still
	be accessed.

>How-To-Repeat:
	create a corrupted adosfs partition and see an empty directory
	when doing an ls of the corrupted directory.

>Fix:
	Apply the following change to advnops.c:
	751,761c751,756
	<                       if (error) {
	<                               if (error != EINVAL)
	<                                       goto reterr;
	<                               ap = NULL;
	<                               nextbn = 0;
	<                       } else {
	<                               ap = VTOA(vp);
	<                               scanned++;
	<                               chainc++;
	<                               nextbn = ap->hashf;
	<                       }
	---
	>                       if (error)
	>                               goto reterr;
	>                       ap = VTOA(vp);
	>                       scanned++;
	>                       chainc++;
	>                       nextbn = ap->hashf;
	785d779
	< 

	This basically aborts following a corrupted hash chain and
	continues with further hash entries.

	BUG: the error condition is not passed to userland, however
	a DIAGNOSTIC is usually generated by lower level code.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: is 
State-Changed-When: Wed Sep 17 07:09:34 PDT 1997 
State-Changed-Why:  
Is this diff reversed? 
-is 
Responsible-Changed-From-To: kern-bug-people->is 
Responsible-Changed-By: is 
Responsible-Changed-When: Wed Sep 17 07:13:54 PDT 1997 
Responsible-Changed-Why:  
Somebody has to take the burden. 
State-Changed-From-To: feedback->open 
State-Changed-By: is 
State-Changed-When: Sun Jul 19 12:54:08 PDT 1998 
State-Changed-Why:  
Answer received. 
State-Changed-From-To: open->analyzed 
State-Changed-By: is 
State-Changed-When: Sun Jul 19 13:39:22 PDT 1998 
State-Changed-Why:  
adosfs is innocent. It correctly passes EINVAL to the upper layer. 
Hoever, ls calls fts which in turn calls readdir(). Per its documentation, 
readdir() can not tell its caller that the directory is corrupted. 

fts should be changed to use getdirentries(), which does return errors. 
-is 
Responsible-Changed-From-To: is->bin-bug-people 
Responsible-Changed-By: is 
Responsible-Changed-When: Sun Jul 19 13:57:22 PDT 1998 
Responsible-Changed-Why:  
This is no longer a kernel problem. 
Responsible-Changed-From-To: bin-bug-people->lib-bug-people 
Responsible-Changed-By: sommerfeld 
Responsible-Changed-When: Wed Jul 5 07:38:21 PDT 2000 
Responsible-Changed-Why:  
fts() is in lib, not bin. 
>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.