Description
npf_conn_establish (invoked from the packet-processing path in softint context) has an error branch to handle memory allocation failure in thmap_put (via npf_conndb_insert), but the error branch calls thmap_del (via npf_conndb_remove), which relies on memory allocation to succeed (rmind/thmap#11):
|
if (!npf_conndb_insert(conn_db, bk, con, NPF_FLOW_BACK)) { |
|
npf_conn_t *ret __diagused; |
|
ret = npf_conndb_remove(conn_db, fw); |
|
KASSERT(ret == con); |
This error branch is essentially guaranteed to crash -- see, e.g.: https://gnats.netbsd.org/57208
Environment and configuration
Environment:
- NPF environment: NetBSD
- Operating system version: NetBSD xxx.xxxx.net 9.2 NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
- NPF version: NetBSD 9.2 (but the problem persists in npf master, NetBSD HEAD)
Configuration:
N/A
Any additional information
- For userspace where allocation is never guaranteed to succeed, thmap_del callers need to be taught to handle failure and retry later.
- For kernel where allocation can sleep, thmap_del needs to be made to sleep, and callers must defer it to thread context (with no spin locks held) where it can safely do so. npf_tableset.c needs to do this outside any spin locks.
Description
npf_conn_establish (invoked from the packet-processing path in softint context) has an error branch to handle memory allocation failure in thmap_put (via npf_conndb_insert), but the error branch calls thmap_del (via npf_conndb_remove), which relies on memory allocation to succeed (rmind/thmap#11):
npf/src/kern/npf_conn.c
Lines 477 to 480 in 2efbe28
This error branch is essentially guaranteed to crash -- see, e.g.: https://gnats.netbsd.org/57208
Environment and configuration
Environment:
Configuration:
N/A
Any additional information