NetBSD Problem Report #60812

From www@netbsd.org  Sun Sep 27 14:43:25 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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C87FD1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 27 Sep 2026 14:43:24 +0000 (UTC)
Message-Id: <20260927144323.616A71A923C@mollari.NetBSD.org>
Date: Sun, 27 Sep 2026 14:43:23 +0000 (UTC)
From: als@thangorodrim.ch
Reply-To: als@thangorodrim.ch
To: gnats-bugs@NetBSD.org
Subject: UBSan: Undefined Behavior in [sys-src]  member access within misaligned address  [..] for type '[..]' which requires 128 byte alignment
X-Send-Pr-Version: www-1.0
X-From4GNATS: "als@thangorodrim.ch via gnats" <gnats-admin@NetBSD.org>

>Number:         60812
>Category:       port-evbmips
>Synopsis:       UBSan: Undefined Behavior in [sys-src]  member access within misaligned address  [..] for type '[..]' which requires 128 byte alignment
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    simonb
>State:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 27 14:45:01 +0000 2026
>Closed-Date:    
>Last-Modified:  Thu Oct 01 22:52:35 +0000 2026
>Originator:     Alexander Schreiber
>Release:        HEAD/20260925044118Z snapshot
>Organization:
Not Much
>Environment:
NetBSD 11.99.8 (ERLITE3)
>Description:
Kernel configured with MULTIPROCESSOR disabled and all available diagnosis turned on. On boot during kernel startup, the console gets flooded with hundreds of variants of:

[  20.8144451] UBSan: Undefined Behavior in /usr/build/HEAD_20260925044118Z/usr/src/sys/kern/vfs_vnops.c:441:20, member access within misaligned address 0x980000041fbeae58 for type 'struct vnode' which requires 128 byte alignment
[  20.8447700] UBSan: Undefined Behavior in /usr/build/HEAD_20260925044118Z/usr/src/sys/kern/kern_descrip.c:728:6, member access within misaligned address 0x980000041fcd6038 for type 'struct proc_t' which requires 128 byte alignment

I trawled through the first 1000 lines of output to consolidate the complaints. It complaints about the following:

const struct vnode
struct pool_cache
struct proc
struct proc_t
struct vnode
struct vnode_impl
struct vnode_impl_t
struct vnode_t

Source files mentioned just in those first 1000 lines:
/usr/src/sys/arch/mips/mips/cpu_exec.c
/usr/src/sys/arch/mips/mips/mips_machdep.c
/usr/src/sys/arch/mips/mips/netbsd32_machdep.c
/usr/src/sys/arch/mips/mips/syscall.c
/usr/src/sys/arch/mips/mips/trap.c
/usr/src/sys/arch/mips/mips/vm_machdep.c
/usr/src/sys/dev/dkwedge/dk.c
/usr/src/sys/kern/exec_elf.c
/usr/src/sys/kern/exec_subr.c
/usr/src/sys/kern/init_main.c
/usr/src/sys/kern/kern_auth.c
/usr/src/sys/kern/kern_clock.c
/usr/src/sys/kern/kern_descrip.c
/usr/src/sys/kern/kern_exec.c
/usr/src/sys/kern/kern_fork.c
/usr/src/sys/kern/kern_lwp.c
/usr/src/sys/kern/kern_proc.c
/usr/src/sys/kern/kern_prot.c
/usr/src/sys/kern/kern_ras.c
/usr/src/sys/kern/kern_sig.c
/usr/src/sys/kern/kern_synch.c
/usr/src/sys/kern/kern_syscall.c
/usr/src/sys/kern/kern_time.c
/usr/src/sys/kern/sched_4bsd.c
/usr/src/sys/kern/subr_copy.c
/usr/src/sys/kern/subr_disk_open.c
/usr/src/sys/kern/subr_pool.c
/usr/src/sys/kern/subr_vmem.c
/usr/src/sys/kern/sys_sig.c
/usr/src/sys/kern/vfs_bio.c
/usr/src/sys/kern/vfs_cache.c
/usr/src/sys/kern/vfs_cwd.c
/usr/src/sys/kern/vfs_lookup.c
/usr/src/sys/kern/vfs_mount.c
/usr/src/sys/kern/vfs_subr.c
/usr/src/sys/kern/vfs_syscalls.c
/usr/src/sys/kern/vfs_vnode.c
/usr/src/sys/kern/vfs_vnops.c
/usr/src/sys/kern/vnode_if.c
/usr/src/sys/miscfs/deadfs/dead_vfsops.c
/usr/src/sys/miscfs/genfs/genfs_io.c
/usr/src/sys/miscfs/genfs/genfs_vnops.c
/usr/src/sys/miscfs/procfs/procfs_vfsops.c
/usr/src/sys/miscfs/specfs/spec_vnops.c
/usr/src/sys/sys/proc.h
/usr/src/sys/sys/syscallvar.h
/usr/src/sys/sys/vnode.h
/usr/src/sys/sys/wapbl.h
/usr/src/sys/ufs/ffs/ffs_vfsops.c
/usr/src/sys/ufs/ffs/ffs_vnops.c
/usr/src/sys/ufs/ufs/ufs_bmap.c
/usr/src/sys/ufs/ufs/ufs_dirhash.c
/usr/src/sys/ufs/ufs/ufs_inode.c
/usr/src/sys/ufs/ufs/ufs_lookup.c
/usr/src/sys/ufs/ufs/ufs_readwrite.c
/usr/src/sys/ufs/ufs/ufs_vnops.c
/usr/src/sys/uvm/pmap/pmap.c
/usr/src/sys/uvm/pmap/pmap_segtab.c
/usr/src/sys/uvm/uvm_fault.c
/usr/src/sys/uvm/uvm_glue.c
/usr/src/sys/uvm/uvm_map.c
/usr/src/sys/uvm/uvm_mmap.c
/usr/src/sys/uvm/uvm_page.c
/usr/src/sys/uvm/uvm_unix.c
/usr/src/sys/uvm/uvm_vnode.c

Actual code locations mentions after uniq(1): 823, so I'm not including those right now, but can dig them up if needed.
>How-To-Repeat:
Grab HEAD/20260925044118Z daily snapshot of source from https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/

Apply the following diff to get from the included OCTEON to the ERLITE3 config used for this test:

--- src/sys/arch/evbmips/conf/OCTEON    2026-07-07 08:14:15.000000000 +0000
+++ src/sys/arch/evbmips/conf/ERLITE3   2026-09-27 14:40:37.840915141 +0000
@@ -1,17 +1,42 @@
-#      $NetBSD: OCTEON,v 1.19 2026/07/07 08:14:15 kbowling Exp $
+#      $NetBSD: OCTEON,v 1.14 2024/01/29 18:27:11 christos Exp $

 include        "arch/mips/conf/std.octeon"
 include        "arch/evbmips/conf/files.octeon"

 #options       INCLUDE_CONFIG_FILE     # embed config file in kernel binary

-#ident                 "OCTEON-$Revision: 1.19 $"
+#ident                 "OCTEON-$Revision: 1.14 $"

 maxusers       32

 options        FDT
 options        FDT_DEFAULT_STDOUT_PATH="\"uart0:115200n8\""

+
+
+# MP
+# options      MULTIPROCESSOR
+
+# Kernel Undefined Behavior Sanitizer (kUBSan).
+options        KUBSAN                  # mandatory
+# options        UBSAN_ALWAYS_FATAL      # optional: panic on all kUBSan reports
+
+# Kernel Code Coverage Driver.
+makeoptions    KCOV=1
+options        KCOV
+
+# Heartbeat checks
+options         HEARTBEAT
+options         HEARTBEAT_MAX_PERIOD_DEFAULT=15
+
+
+
+
+
+
+# config
+options                INCLUDE_CONFIG_FILE
+
 # Options for necessary to use MD
 #options       MEMORY_DISK_HOOKS
 #options       MEMORY_DISK_IS_ROOT     # force root on memory disk
@@ -34,10 +59,10 @@

 # Debugging options
 options        DIAGNOSTIC      # extra kernel sanity checking
-#options       DEBUG           # extra kernel debugging support
+options        DEBUG           # extra kernel debugging support
+options         LOCKDEBUG       # expensive locking checks/support
 #options       USERCONF        # userconf(4) support
-#options       SYSCTL_INCLUDE_DESCR    # Include sysctl descriptions in kernel
-#options       PMAP_DEBUG
+options        SYSCTL_INCLUDE_DESCR    # Include sysctl descriptions in kernel
 options        DDB             # kernel dynamic debugger
 options        DDB_HISTORY_SIZE=100 # enable history editing in DDB
 makeoptions    DEBUG="-g"      # compile full symbol table

>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 27 Sep 2026 22:03:30 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10

May also warrant reconsidering the use of __aligned in these structures;
perhaps the uniprocessor optimization would be better done with explicit
padding, so we retain the same module ABI for MP and UP builds, but we
needn't incur the extra memory padding cost on allocation in UP builds.


From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60812 CVS commit: src/sys/kern
Date: Sun, 27 Sep 2026 22:00:05 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Sep 27 22:00:05 UTC 2026

 Modified Files:
 	src/sys/kern: vfs_vnode.c

 Log Message:
 vnode(9): Allocate vnodes with declared alignment.

 The definition of struct vnode_impl includes various
 __aligned(COHERENCY_UNIT), so the compiler will assume struct vnode
 pointers are aligned as such.

 As a space optimization on uniprocessor systems, we define the
 variable `coherency_unit' (as part of the module ABI) to be
 COHERENCY_UNIT (often 64 or 128) in MULTIPROCESSOR builds, but
 toALIGNBYTES+1 (often 4, 8, or 16) for !MULTIPROCESSOR builds where
 cache line sharing isn't as much of a problem.

 But this isn't safe as an optimization for allocating objects that
 have statically declared (as part of their ABI) COHERENCY_UNIT
 alignment.

 PR port-evbmips/60812: UBSan: Undefined Behavior in [sys-src]  member
 access within misaligned address  [..] for type '[..]' which requires
 128 byte alignment


 To generate a diff of this commit:
 cvs rdiff -u -r1.159 -r1.160 src/sys/kern/vfs_vnode.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60812 CVS commit: src/sys/kern
Date: Sun, 27 Sep 2026 22:00:33 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Sep 27 22:00:33 UTC 2026

 Modified Files:
 	src/sys/kern: kern_proc.c

 Log Message:
 proc(9): Allocate struct proc with declared alignment.

 The definition of struct proc includes __aligned(COHERENCY_UNIT) on
 the p_auxlock member, so the compiler will assume struct proc
 pointers are aligned as such.

 As a space optimization on uniprocessor systems, we define the
 variable `coherency_unit' (as part of the module ABI) to be
 COHERENCY_UNIT (often 64 or 128) in MULTIPROCESSOR builds, but
 toALIGNBYTES+1 (often 4, 8, or 16) for !MULTIPROCESSOR builds where
 cache line sharing isn't as much of a problem.

 But this isn't safe as an optimization for allocating objects that
 have statically declared (as part of their ABI) COHERENCY_UNIT
 alignment.

 PR port-evbmips/60812: UBSan: Undefined Behavior in [sys-src]  member
 access within misaligned address  [..] for type '[..]' which requires
 128 byte alignment


 To generate a diff of this commit:
 cvs rdiff -u -r1.286 -r1.287 src/sys/kern/kern_proc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60812 CVS commit: src/sys/kern
Date: Sun, 27 Sep 2026 22:01:23 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Sep 27 22:01:23 UTC 2026

 Modified Files:
 	src/sys/kern: subr_pool.c

 Log Message:
 pool_cache(9): Allocate struct pool_cache with declared alignment.

 The definition of struct pool_cache has __aligned(CACHE_LINE_SIZE) on
 the pc_fullgroups member, so the compiler will assume struct
 pool_cache pointers are aligned as such.

 As a space optimization on uniprocessor systems, we define the
 variable `coherency_unit' (as part of the module ABI) to be
 COHERENCY_UNIT (often 64 or 128) in MULTIPROCESSOR builds, but
 to ALIGNBYTES+1 (often 4, 8, or 16) for !MULTIPROCESSOR builds where
 cache line sharing isn't as much of a problem.

 But this isn't safe as an optimization for allocating objects that
 have statically declared (as part of their ABI) CACHE_LINE_SIZE
 alignment.

 PR port-evbmips/60812: UBSan: Undefined Behavior in [sys-src]  member
 access within misaligned address  [..] for type '[..]' which requires
 128 byte alignment


 To generate a diff of this commit:
 cvs rdiff -u -r1.298 -r1.299 src/sys/kern/subr_pool.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Alexander Schreiber <als@thangorodrim.ch>
To: gnats-bugs@netbsd.org
Cc: port-evbmips-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, riastradh@netbsd.org
Subject: Re: port-evbmips/60812 (UBSan: Undefined Behavior in [sys-src]
 member access within misaligned address  [..] for type '[..]' which requires
 128 byte alignment)
Date: Thu, 1 Oct 2026 21:48:06 +0200

 Update:
  - I've built and booted another debug kernel from HEAD/20260930062955Z
  - booted on the EdgeRouter4 (essentially same hardware as Erlite3,
    but the "big brother": 4x 1 GHz mips64, 1 G RAM)
  - we're down to two UBSan complaints about integer shifts:

 --------------- cut here -------------------
 [   1.0000000] cpu0: 256 TLB entries, 512TB (49-bit) VAsUBSan: Undefined Behavior in /usr/build/HEAD_20260930062955Z/usr/src/sys/arch/mips/mips/mips_machdep.c:1640:37, left shift of 9223372036787666944 by 1 places cannot be represented in type 'long int'
 [   1.0000000] UBSan: Undefined Behavior in /usr/build/HEAD_20260930062955Z/usr/src/sys/lib/libkern/../../../common/lib/libc/string/memset2.c:104:15, left shift of 4294967295 by 32 places cannot be represented in type 'long int'
 --------------- cut here -------------------

 Kind regards,
            Alex.
 -- 
 "Opportunity is missed by most people because it is dressed in overalls and
  looks like work."                                      -- Thomas A. Edison

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60812 CVS commit: src/sys/arch/mips/mips
Date: Thu, 1 Oct 2026 21:58:53 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Thu Oct  1 21:58:53 UTC 2026

 Modified Files:
 	src/sys/arch/mips/mips: mips_machdep.c

 Log Message:
 mips: Avoid shifting into sign bit by using unsigned type instead.

 Maybe this loop should do arithmetic in the other direction?  But at
 least left shifts on unsigned t-bit types are reduced mod 2^t and not
 undefined, so this is a simpler change to avoid UB.

 PR port-evbmips/60812: UBSan: Undefined Behavior in [sys-src] member
 access within misaligned address [..] for type '[..]' which requires
 128 byte alignment


 To generate a diff of this commit:
 cvs rdiff -u -r1.310 -r1.311 src/sys/arch/mips/mips/mips_machdep.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: port-evbmips-maintainer->simonb
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Thu, 01 Oct 2026 22:52:35 +0000
Responsible-Changed-Why:
The remaining issue is about __register_t, which is signed on mips.
This code was switched from uregister_t (guaranteed unsigned but only
available on mips and riscv) to __register_t (assumed unsigned, and,
well, you know what it does to you and me when you assume!) by simonb
in 2021:

Module Name:    src
Committed By:   simonb
Date:           Sat Apr 17 08:06:58 UTC 2021

Modified Files:
        src/common/lib/libc/string: memset2.c

Log Message:
Use __register_t instead of uregister_t - this is available to all ports
and both userland and kernel.


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/common/lib/libc/string/memset2.c

https://mail-index.netbsd.org/source-changes/2021/04/17/msg128892.html

simonb: Can you sort this one out, either by going back to uregister_t
or finding some other way to make it always unsigned?


>Unformatted:

Home	PR Database Search