Hello, On Mon, Sep 28, 2026 at 04:57:50PM +0000, [email protected] wrote: > > diff --git a/drivers/base/bus.c b/drivers/base/bus.c > > index c51ad96d4de4b..d294c198ab0c3 100644 > > --- a/drivers/base/bus.c > > +++ b/drivers/base/bus.c > > @@ -606,6 +606,49 @@ int bus_add_device(struct device *dev) > > return error; > > } > > > > +static int __read_mostly allow_driver_override; > > + > > +static int __init allow_driver_override_setup(char *str) > > +{ > > + allow_driver_override = 1; > > [Severity: Medium] > Does this setup function ignore the user-provided string value? If an > administrator passes allow_driver_override=0 or allow_driver_override=off > on the kernel command line, it appears this will still unconditionally set > allow_driver_override = 1. Should standard boolean parsing such as > kstrtobool(str, &allow_driver_override) be used here instead to honor the > user intent?
I copied from sysrq_always_enabled_setup(), I guess both could indeed
benefit from kstrtobool().
> > + return 1;
> > +}
>
> [ ... ]
>
> > +int device_match_driver_override(struct device *dev,
> > + const struct device_driver *drv)
> > +{
> > + guard(spinlock)(&dev->driver_override.lock);
> > + if (dev->driver_override.name) {
> > + int ret = !strcmp(dev->driver_override.name, drv->name);
> > +
> > + if (ret > 0) {
> > + if (!allow_driver_override &&
> > !drv->support_driver_override) {
>
> [Severity: Critical]
> Could this unconditionally suppress the override match for drivers that
> haven't been updated, and break existing userspace ABIs? Userspace
> frameworks like libvirt, QEMU, or DPDK that rely on this feature for PCI
> passthrough via vfio-pci or uio_pci_generic might silently fail to bind
> devices if they lack the kernel command-line parameter.
The idea is to mark the relevant drivers with .support_driver_override =
1 before this patch is applied to minimize the fallout. I added the two
drivers pointed out to my list to check.
> > + pr_info("Suppress driver override binding.
> > Allow %ps to do overriding or boot with allow_driver_override on cmdline\n",
> > + drv);
>
> [Severity: High]
> Does applying the %ps specifier to a data pointer (drv) instead of a string
> (drv->name) leak a raw kernel address? If the kernel is built without
> CONFIG_KALLSYMS_ALL, kallsyms will fail to resolve the data symbol, and the
> print routine falls back to printing the unhashed hexadecimal pointer,
> which could bypass KASLR when exposed in dmesg.
I wasn't aware of that leak. Is that a real thing?
Best regards
Uwe
signature.asc
Description: PGP signature
