From owner-freebsd-fs@FreeBSD.ORG  Fri Jan 24 18:41:48 2014
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id F098354B
 for <fs@freebsd.org>; Fri, 24 Jan 2014 18:41:48 +0000 (UTC)
Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251])
 by mx1.freebsd.org (Postfix) with ESMTP id B868B1D95
 for <fs@freebsd.org>; Fri, 24 Jan 2014 18:41:48 +0000 (UTC)
Received: by vlakno.cz (Postfix, from userid 1002)
 id 1E3501CC558B; Fri, 24 Jan 2014 19:41:41 +0100 (CET)
Date: Fri, 24 Jan 2014 19:41:41 +0100
From: Roman Divacky <rdivacky@freebsd.org>
To: fs@freebsd.org
Subject: BUG: possible NULL pointer dereference in nfs server
Message-ID: <20140124184141.GA19458@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.22 (2013-10-16)
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 18:41:49 -0000

Hi,

In nfs_nfsdstate.c:nfsrv_lockctrl() we call 

getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags, NULL, &nfh, p);

then in nfsrv_getlockfh() we, based on the value of flags, might
dereference the NULL pointer:


nfsrv_getlockfh(vnode_t vp, u_short flags,
    struct nfslockfile **new_lfpp, fhandle_t *nfhp, NFSPROC_T *p)


        if (flags & NFSLCK_OPEN) {
                new_lfp = *new_lfpp;
                fhp = &new_lfp->lf_fh;


I am not sure what the right fix is. Or if it's even possible to hit
(but I think it is). Anyway the compiler currently generates
a trap instruction (ud2 on x86) in this code. It's the only trap
in GENERIC btw.

Would be lovely to fix this.

Roman

P.S. CC me on your replies as I am not subscribed to the list.