External modules built with KBUILD_EXTMOD set inherit UBSAN sanitizer
flags from the kernel's KBUILD_CFLAGS because is-kernel-object is 'y'
for any obj-m object. This silently breaks third-party modules whose
source code (e.g. VMware vmnet/vmmon) triggers UBSAN UB checks at
runtime, causing packet-forwarding failures and VM instability while
the module itself loads successfully.

Make UBSAN opt-in for external modules: skip the is-kernel-object 'y'
fallback when KBUILD_EXTMOD is set. External modules that explicitly
need UBSAN can still opt in by setting UBSAN_SANITIZE := y.

In-kernel module builds are not affected.
Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
---
 scripts/Makefile.lib | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0718e39cedda..393af3f970af 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -74,10 +74,10 @@ endif
 
 ifeq ($(CONFIG_UBSAN),y)
 _c_flags += $(if $(patsubst n%,, \
-		$(UBSAN_SANITIZE_$(target-stem).o)$(UBSAN_SANITIZE)$(is-kernel-object)), \
+		$(UBSAN_SANITIZE_$(target-stem).o)$(UBSAN_SANITIZE)$(if $(KBUILD_EXTMOD),,$(is-kernel-object))), \
 		$(CFLAGS_UBSAN))
 _c_flags += $(if $(patsubst n%,, \
-		$(UBSAN_INTEGER_WRAP_$(target-stem).o)$(UBSAN_SANITIZE_$(target-stem).o)$(UBSAN_INTEGER_WRAP)$(UBSAN_SANITIZE)$(is-kernel-object)), \
+		$(UBSAN_INTEGER_WRAP_$(target-stem).o)$(UBSAN_SANITIZE_$(target-stem).o)$(UBSAN_INTEGER_WRAP)$(UBSAN_SANITIZE)$(if $(KBUILD_EXTMOD),,$(is-kernel-object))), \
 		$(CFLAGS_UBSAN_INTEGER_WRAP))
 endif

+ Kees and linux-hardening@ for visibility

On Thu, Aug 20, 2026 at 09:01:58PM +0200, Ferran Duarri wrote:
> External modules built with KBUILD_EXTMOD set inherit UBSAN sanitizer
> flags from the kernel's KBUILD_CFLAGS because is-kernel-object is 'y'
> for any obj-m object. This silently breaks third-party modules whose
> source code (e.g. VMware vmnet/vmmon) triggers UBSAN UB checks at
> runtime, causing packet-forwarding failures and VM instability while
> the module itself loads successfully.
> 
> Make UBSAN opt-in for external modules: skip the is-kernel-object 'y'
> fallback when KBUILD_EXTMOD is set. External modules that explicitly
> need UBSAN can still opt in by setting UBSAN_SANITIZE := y.
> 
> In-kernel module builds are not affected.
> Signed-off-by: Ferran Duarri <ferran.duarri@me.com>

I am open to other opinions but I am not inclined to apply this change.
If an external module has issues with these checks, it should either be
fixed or 'UBSAN_SANITIZE := n' can be added to the module's Makefile,
rather than making the default worse for everyone else, especially given
the importance of UBSAN_BOUNDS for avoiding out of bounds accesses and
writes.

-- 
Cheers,
Nathan

Nathan, Nicolas - fair, and it's the right call: making UBSAN weaker for
everyone to fix one out-of-tree module's problem is a bad trade. Dropping
this, thanks.

Cheers,
Ferran

On Fri, Aug 21, 2026 at 12:07:01PM -0700, Nathan Chancellor wrote:
> + Kees and linux-hardening@ for visibility
> 
> On Thu, Aug 20, 2026 at 09:01:58PM +0200, Ferran Duarri wrote:
> > External modules built with KBUILD_EXTMOD set inherit UBSAN sanitizer
> > flags from the kernel's KBUILD_CFLAGS because is-kernel-object is 'y'
> > for any obj-m object. This silently breaks third-party modules whose
> > source code (e.g. VMware vmnet/vmmon) triggers UBSAN UB checks at
> > runtime, causing packet-forwarding failures and VM instability while
> > the module itself loads successfully.
> > 
> > Make UBSAN opt-in for external modules: skip the is-kernel-object 'y'
> > fallback when KBUILD_EXTMOD is set. External modules that explicitly
> > need UBSAN can still opt in by setting UBSAN_SANITIZE := y.
> > 
> > In-kernel module builds are not affected.
> > Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
> 
> I am open to other opinions but I am not inclined to apply this change.
> If an external module has issues with these checks, it should either be
> fixed or 'UBSAN_SANITIZE := n' can be added to the module's Makefile,
> rather than making the default worse for everyone else, especially given
> the importance of UBSAN_BOUNDS for avoiding out of bounds accesses and
> writes.

Yes, I second that.

-- 
Nicolas

On Fri, Aug 21, 2026 at 09:52:28PM +0200, Nicolas Schier wrote:
> On Fri, Aug 21, 2026 at 12:07:01PM -0700, Nathan Chancellor wrote:
> > + Kees and linux-hardening@ for visibility
> > 
> > On Thu, Aug 20, 2026 at 09:01:58PM +0200, Ferran Duarri wrote:
> > > External modules built with KBUILD_EXTMOD set inherit UBSAN sanitizer
> > > flags from the kernel's KBUILD_CFLAGS because is-kernel-object is 'y'
> > > for any obj-m object. This silently breaks third-party modules whose
> > > source code (e.g. VMware vmnet/vmmon) triggers UBSAN UB checks at
> > > runtime, causing packet-forwarding failures and VM instability while
> > > the module itself loads successfully.
> > > 
> > > Make UBSAN opt-in for external modules: skip the is-kernel-object 'y'
> > > fallback when KBUILD_EXTMOD is set. External modules that explicitly
> > > need UBSAN can still opt in by setting UBSAN_SANITIZE := y.
> > > 
> > > In-kernel module builds are not affected.
> > > Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
> > 
> > I am open to other opinions but I am not inclined to apply this change.
> > If an external module has issues with these checks, it should either be
> > fixed or 'UBSAN_SANITIZE := n' can be added to the module's Makefile,
> > rather than making the default worse for everyone else, especially given
> > the importance of UBSAN_BOUNDS for avoiding out of bounds accesses and
> > writes.
> 
> Yes, I second that.

Correct. And (unsurprisingly) I take an even harder line: the
external module source should be fixed, full stop. Disabling it with
"UBSAN_SANITIZE := n" is just a localized version of the proposed patch.
The whole point of these defense in the kernel is to stop bad code
from operating.

The out-of-tree code needs to be fixed. If it can't run with these
features enabled, it is an active threat to the safety of the users of
systems with that code running in their kernels. If VMware can't fix
this, no one should be using that code.

-Kees

-- 
Kees Cook