linux-kernel - Re: [PATCH] usb: typec: mux: fix NULL pointer dereference in {typec_switch,mux}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2026011554-chute-sloppily-34bb@gregkh>
Date: Thu, 15 Jan 2026 07:34:19 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: 齐柯宇 <qikeyu2017@...il.com>
Cc: heikki.krogerus@...ux.intel.com, andersson@...nel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: typec: mux: fix NULL pointer dereference in
 {typec_switch,mux}_put

On Thu, Jan 15, 2026 at 02:56:24AM +0800, 齐柯宇 wrote:
> This fix was discovered through static code analysis.
> 
> In typec_switch_put() and typec_mux_put(), the code directly dereferences
> sw_dev->dev.parent->driver->owner without checking if 'driver' is NULL.
> This can lead to a NULL pointer dereference kernel crash.
> 
> [Call Chain Analysis]
> The vulnerable functions are called through the following paths:
> 
>   Acquisition path (fwnode_typec_switch_get):
>     typec_port_register()           [class.c]
>       -> typec_switch_get()         [typec_mux.h]
>         -> fwnode_typec_switch_get() [mux.c]
>           -> class_find_device()    (gets device reference)
>           -> try_module_get(sw_devs[i]->dev.parent->driver->owner)
>           -> stores to sw->sw_devs[i]
> 
>   Release path (typec_switch_put):
>     typec_release()                 [class.c]
>       -> typec_switch_put()         [mux.c]
>         -> module_put(sw_dev->dev.parent->driver->owner)  <- BUG!
>         -> put_device(&sw_dev->dev)
> 
>   Registration path (typec_switch_register):
>     I2C/Platform driver probe()
>       -> typec_switch_register(dev, &sw_desc) [mux.c]
>         -> sw_dev->dev.parent = parent  (sets parent device)
>         -> device_add(&sw_dev->dev)
> 
> [Data Flow Analysis]
> The critical data flow is:
> 
>   sw_dev->dev.parent:
>     - Set by typec_switch_register() from the 'parent' parameter
>     - Typically an I2C or Platform device (e.g., &client->dev)
> 
>   sw_dev->dev.parent->driver:
>     - Managed by kernel driver model (drivers/base/dd.c)
>     - Set to driver pointer when driver binds (really_probe)
>     - Set to NULL when driver unbinds (__device_release_driver)
> 
> [Race Condition Scenario]
> The vulnerability can be triggered by the following race condition:
> 
>   Thread A (normal operation)        Thread B (attacker/event)
>   ----------------------------       -------------------------
>   T1: typec_port_register()
>   T2: fwnode_typec_switch_get()
>   T3: try_module_get(parent->driver->owner)
>   T4: store sw_devs[i]
>       ...
>                                      T5: echo <dev> > unbind
>                                      T6: device_driver_detach()

Are you sure that at this point things don't get synced up?

>                                      T7: parent->driver = NULL
>   T8: typec_switch_put(sw)
>   T9: module_put(parent->driver->owner)
>       -> NULL pointer dereference!

A parent should never be null.

> 
> [User-Triggerable Paths]
> Users can trigger this vulnerability through:

It's not a "vulnerability" given the definition of that word.

>   1. sysfs unbind interface (requires root):
>      # echo "<device>" > /sys/bus/i2c/drivers/<driver>/unbind
> 
>   2. Module unloading (requires root):
>      # rmmod <switch_driver_module>
> 
>   3. USB Type-C hot-unplug (physical access):
>      Physically removing the USB-C device or its parent device

I don't think that removing the device can cause this, have you tried?

What AI tool wrote this?  You always have to document your tools, right?

thanks,

greg k-h