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 <[email protected]> > > > > 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
