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:
parent
cb9aba0e17
commit
566cf4817b
|
@ -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))
|
||||
|
|
Loading…
Reference in New Issue