In nvmm_open(), make sure an implementation was found. This fixes an

initialization bug triggerable in certain conditions.

If you build nvmm inside the kernel, AND have a cpu that is not supported,
AND run nvmmctl (or qemu-nvmm, both being the only binaries in the "nvmm"
group), you get a page fault.

This is because when nvmm is built inside the kernel, the kernel registers
nvmm_cdevsw behind nvmm's back. The ioctl is therefore always accessible,
and will hit NULL pointers if nvmm_init() failed.

Problem reported by Andrei M. on netbsd-users@, thanks.
This commit is contained in:
maxv 2020-04-26 19:31:36 +00:00
parent cb9aba0e17
commit 566cf4817b
1 changed files with 4 additions and 2 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: nvmm.c,v 1.25 2019/10/28 09:00:08 maxv Exp $ */
/* $NetBSD: nvmm.c,v 1.26 2020/04/26 19:31:36 maxv Exp $ */
/*
* Copyright (c) 2018-2019 The NetBSD Foundation, Inc.
@ -30,7 +30,7 @@
*/
#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD: nvmm.c,v 1.25 2019/10/28 09:00:08 maxv Exp $");
__KERNEL_RCSID(0, "$NetBSD: nvmm.c,v 1.26 2020/04/26 19:31:36 maxv Exp $");
#include <sys/param.h>
#include <sys/systm.h>
@ -1040,6 +1040,8 @@ nvmm_open(dev_t dev, int flags, int type, struct lwp *l)
struct file *fp;
int error, fd;
if (__predict_false(nvmm_impl == NULL))
return ENXIO;
if (minor(dev) != 0)
return EXDEV;
if (!(flags & O_CLOEXEC))