From owner-freebsd-bugs Mon Sep 8 19:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25763 for bugs-outgoing; Mon, 8 Sep 1997 19:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25756; Mon, 8 Sep 1997 19:30:02 -0700 (PDT) Resent-Date: Mon, 8 Sep 1997 19:30:02 -0700 (PDT) Resent-Message-Id: <199709090230.TAA25756@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, serge@jbj.org Received: from serge.jbj.org (serge.JBJ.ORG [198.178.231.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25698 for ; Mon, 8 Sep 1997 19:29:09 -0700 (PDT) Received: (from serge@localhost) by serge.jbj.org (8.8.6/8.6.12) id WAA04878; Mon, 8 Sep 1997 22:29:07 -0400 (EDT) Message-Id: <199709090229.WAA04878@serge.jbj.org> Date: Mon, 8 Sep 1997 22:29:07 -0400 (EDT) From: Serge Pashenkov Reply-To: serge@jbj.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4501: df on a stale file system panics Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4501 >Category: kern >Synopsis: df on a stale file system panics >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 8 19:30:01 PDT 1997 >Last-Modified: >Originator: Serge Pashenkov >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: 2.2 stable circa Sep 8 >Description: on a server export something like /mnt with something mounted there (floppy would be just fine), mount it on 2.2 stable client, unmount /mnt on the server. Now, simple df panics the client. >How-To-Repeat: see description. >Fix: nfs_statfs() does not parse the packet quite right in case of a stale file handle. Local variable register struct nfs_statfs *sfp; is assigned 0 and never reassigned the real value, but still gets used as a pointer later. I'm not sure how to really fix the problem for I don't quite frok nfsm_ macros, but following is a prop which just checks for 0 value of sfp. It fixes the panic, and actually I see no problems with that, but probably right fix is in the nfsm_ ... RCS file: /spare/ncvs/src/sys/nfs/nfs_vfsops.c,v retrieving revision 1.30.2.4 diff -c -r1.30.2.4 nfs_vfsops.c *** nfs_vfsops.c 1997/05/14 08:19:29 1.30.2.4 --- nfs_vfsops.c 1997/09/02 13:49:13 *************** *** 245,250 **** --- 245,256 ---- nfsm_postop_attr(vp, retattr); if (!error) nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3)); + + if (sfp == NULL) { + error = ESTALE; + goto nfsmout; + } + #ifdef __NetBSD__ #ifdef COMPAT_09 sbp->f_type = 2; >Audit-Trail: >Unformatted: