NetBSD Problem Report #60688

From www@netbsd.org  Mon Sep  7 14:15:09 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 936C21A923C
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  7 Sep 2026 14:15:09 +0000 (UTC)
Message-Id: <20260907141508.427D01A923E@mollari.NetBSD.org>
Date: Mon,  7 Sep 2026 14:15:08 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: npf: wrong module/config dependency for bpf filter?
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60688
>Category:       kern
>Synopsis:       npf: wrong module/config dependency for bpf filter?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tls
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 07 14:20:01 +0000 2026
>Last-Modified:  Tue Sep 08 15:00:02 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, ...
>Organization:
The NpfBpf Dependency, Inc.
>Environment:
>Description:

	Something appears to be wrong with the module dependencies of
	npf.kmod but the details are unclear:

> Fix npf crash in kernels without "pseudo-device bpfilter".

>How-To-Repeat:

	1. build a kernel without `pseudo-device bpfilter'
	2. load npf.kmod

>Fix:

	First: The symptom should be documented so if anyone has
	stumbled upon it, they can find the symptom and learn that it
	is fixed now.

	Second: The dependencies of npf, and perhaps of bpf, should be
	clarified, if not also fixed.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->tls
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 07 Sep 2026 14:34:28 +0000
Responsible-Changed-Why:
Can you please post the symptom (panic message, stack trace, whatever),
and make sure the dependencies are actually correct?

In particular, the change below looks suspicious for several reasons:

1. The `bpf' module already depends on `bpf_filter', so if depending on
   `bpf' wasn't enough, then surely depending on `bpf_filter' alone
   can't be enough!

   2680 MODULE(MODULE_CLASS_DRIVER, bpf, "bpf_filter");

https://nxr.netbsd.org/xref/src/sys/net/bpf.c?r=1.258#2680

   But perhaps the dependencies are not adequately matched in modules
   vs config(5) in files.net.

2. There are two MODULE declarations in npf_os.c which now disagree on
   the dependencies -- one branch depends on bpf, the other on
   bpf_filter:

diff -r aa99cd559912 -r 721be25199e5 sys/net/npf/npf_os.c
--- a/sys/net/npf/npf_os.c	Sat Sep 05 17:39:23 2026 +0000
+++ b/sys/net/npf/npf_os.c	Sat Sep 05 17:43:56 2026 +0000
...
@@ -81,7 +81,7 @@
 MODULE(MODULE_CLASS_MISC, npf, "bpf");
 #else
 /* This module autoloads via /dev/npf so it needs to be a driver */
-MODULE(MODULE_CLASS_DRIVER, npf, "bpf");
+MODULE(MODULE_CLASS_DRIVER, npf, "bpf_filter");
 #endif

3. It looks to me like npf actually _does_ depend on `bpf' per se,
   because it uses (e.g.) bpf_mtap2 and bpf_jit_generate, not just on
   `bpf_filter' (which it needs for bpf_create, bpf_set_cop,
   bpf_set_extmem, bpf_validate_ext, bpf_filter_ext):

    137 void *
    138 npf_bpf_compile(void *code, size_t size)
    139 {
    140 	return bpf_jit_generate(npf_bpfctx, code, size);
    141 }
https://nxr.netbsd.org/xref/src/sys/net/npf/npf_bpf.c?r=1.14#137

    144 		/* Pass through BPF. */
    145 		bpf_mtap2(ifp->if_bpf, &hdr, NPFLOG_HDRLEN, m, BPF_D_OUT);
https://nxr.netbsd.org/xref/src/sys/net/npf/npf_ext_log.c?r=1.17#144

   These come from bpf.c and thus from the `bpf' module, not from
   bpf_filter.c or the `bpf_filter' module (which `bpf' depends on).

https://nxr.netbsd.org/xref/src/sys/net/bpf.c?r=1.258#303


Change that was supposed to fix this bug but I suspect doesn't quite:

https://mail-index.netbsd.org/source-changes/2026/09/05/msg163893.html

Module Name:    src
Committed By:   tls
Date:           Sat Sep  5 17:43:56 UTC 2026

Modified Files:
        src/sys/net/npf: files.npf npf_os.c

Log Message:
Fix npf crash in kernels without "pseudo-device bpfilter".


To generate a diff of this commit:
cvs rdiff -u -r1.25 -r1.26 src/sys/net/npf/files.npf
cvs rdiff -u -r1.23 -r1.24 src/sys/net/npf/npf_os.c


From: Thor Lancelot Simon <tls@panix.com>
To: gnats-bugs@netbsd.org
Cc: tls@netbsd.org, kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, riastradh@NetBSD.org,
	campbell+netbsd@mumble.net
Subject: Re: kern/60688 (npf: wrong module/config dependency for bpf filter?)
Date: Mon, 7 Sep 2026 12:06:42 -0400

 Apologies - I had committed a mangled patch after test building in the wrong
 tree (sigh).  This should be fully fixed by npf_os.c 1.25, bpf.c 1.258, and
 bpg_filter.c 1.74.

 The symptom is that a kernel without MODULAR nor pseudo-device bpfilter,
 but with pseudo-device npf, fails module initialization for built-in module
 npf:

 WARNING: module error: Built-in module 'npf' prerequisite 'bpf' failed, error 2

 Subsequently, "npfctl reload" will yield a quick panic because the module is
 uninitialized - the usual uvm_fault from a NULL pointer dereference.

 I don't think there is an issue with bpf_mtap2; it's a static inline from the
 bpf.h header file and is supplied by bpf_stub.c, not bpf.c.

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Thor Lancelot Simon <tls@panix.com>
Cc: gnats-bugs@netbsd.org, tls@netbsd.org,
	kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org
Subject: Re: kern/60688 (npf: wrong module/config dependency for bpf filter?)
Date: Tue, 8 Sep 2026 14:57:02 +0000

 > Date: Mon, 7 Sep 2026 12:06:42 -0400
 > From: Thor Lancelot Simon <tls@panix.com>
 >=20
 > Apologies - I had committed a mangled patch after test building in the wr=
 ong
 > tree (sigh).  This should be fully fixed by npf_os.c 1.25, bpf.c 1.258, a=
 nd
 > bpg_filter.c 1.74.

 Thanks, I'll take a look.

 > The symptom is that a kernel without MODULAR nor pseudo-device bpfilter,
 > but with pseudo-device npf, fails module initialization for built-in modu=
 le
 > npf:
 >=20
 > WARNING: module error: Built-in module 'npf' prerequisite 'bpf' failed, e=
 rror 2
 >=20
 > Subsequently, "npfctl reload" will yield a quick panic because the module=
  is
 > uninitialized - the usual uvm_fault from a NULL pointer dereference.

 That sounds like another bug with module loading.  If the module load
 fails, `npfctl reload' should fail gracefully, not crash.

 However, that's also consistent with bpf_ops being null.  Can you show
 the stack trace?

 > I don't think there is an issue with bpf_mtap2; it's a static inline from=
  the
 > bpf.h header file and is supplied by bpf_stub.c, not bpf.c.

 Yes but it works via the global pointer bpf_ops which might be null if
 something went wrong with module initialization, and the logic I see
 in bpf_stub.c looks awfully sketchy at quick glance:

 https://nxr.netbsd.org/xref/src/sys/net/bpf_stub.c?r=3D1.8

>Unformatted:

Home	PR Database Search