linux-stable.git/drivers/thunderbolt, branch v6.14

thunderbolt: Prevent use-after-free in resume from hibernate

2025-03-07T12:00:58+00:00

Kenneth noticed that his laptop crashes randomly when resuming from
hibernate if there is device connected and display tunneled. I was able
to reproduce this as well with the following steps:

  1. Boot the system up, nothing connected.
  2. Connect Thunderbolt 4 dock to the host.
  3. Connect monitor to the Thunderbolt 4 dock.
  4. Verify that there is picture on the screen.
  5. Enter hibernate.
  6. Exit hibernate.
  7. Wait for the system to resume.

  Expectation: System resumes just fine, the connected monitor still
               shows screen.
  Actual result: There is crash during resume, screen is blank.

What happens is that during resume from hibernate we tear down any
existing tunnels created by the boot kernel and this ends up calling
tb_dp_dprx_stop() which calls tb_tunnel_put() dropping the reference
count to zero even though we never called tb_dp_dprx_start() for it (we
never do that for discovery). This makes the discovered DP tunnel memory
to be released and any access after that causes use-after-free and
possible crash.

Fix this so that we only stop DPRX flow if it has been started in the
first place.

Reported-by: Kenneth Crudup 
Closes: https://lore.kernel.org/linux-usb/8e175721-806f-45d6-892a-bd3356af80c9@panix.com/
Cc: stable@vger.kernel.org
Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously")
Reviewed-by: Yehezkel Bernat 
Signed-off-by: Mika Westerberg

Merge tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2025-01-28T20:25:12+00:00

Pull driver core and debugfs updates from Greg KH:
 "Here is the big set of driver core and debugfs updates for 6.14-rc1.

  Included in here is a bunch of driver core, PCI, OF, and platform rust
  bindings (all acked by the different subsystem maintainers), hence the
  merge conflict with the rust tree, and some driver core api updates to
  mark things as const, which will also require some fixups due to new
  stuff coming in through other trees in this merge window.

  There are also a bunch of debugfs updates from Al, and there is at
  least one user that does have a regression with these, but Al is
  working on tracking down the fix for it. In my use (and everyone
  else's linux-next use), it does not seem like a big issue at the
  moment.

  Here's a short list of the things in here:

   - driver core rust bindings for PCI, platform, OF, and some i/o
     functions.

     We are almost at the "write a real driver in rust" stage now,
     depending on what you want to do.

   - misc device rust bindings and a sample driver to show how to use
     them

   - debugfs cleanups in the fs as well as the users of the fs api for
     places where drivers got it wrong or were unnecessarily doing
     things in complex ways.

   - driver core const work, making more of the api take const * for
     different parameters to make the rust bindings easier overall.

   - other small fixes and updates

  All of these have been in linux-next with all of the aforementioned
  merge conflicts, and the one debugfs issue, which looks to be resolved
  "soon""

* tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits)
  rust: device: Use as_char_ptr() to avoid explicit cast
  rust: device: Replace CString with CStr in property_present()
  devcoredump: Constify 'struct bin_attribute'
  devcoredump: Define 'struct bin_attribute' through macro
  rust: device: Add property_present()
  saner replacement for debugfs_rename()
  orangefs-debugfs: don't mess with ->d_name
  octeontx2: don't mess with ->d_parent or ->d_parent->d_name
  arm_scmi: don't mess with ->d_parent->d_name
  slub: don't mess with ->d_name
  sof-client-ipc-flood-test: don't mess with ->d_name
  qat: don't mess with ->d_name
  xhci: don't mess with ->d_iname
  mtu3: don't mess wiht ->d_iname
  greybus/camera - stop messing with ->d_iname
  mediatek: stop messing with ->d_iname
  netdevsim: don't embed file_operations into your structs
  b43legacy: make use of debugfs_get_aux()
  b43: stop embedding struct file_operations into their objects
  carl9170: stop embedding file_operations into their objects
  ...

Merge 6.13-rc7 into driver-core-next

2025-01-13T05:40:34+00:00

We need the debugfs / driver-core fixes in here as well for testing and
to build on top of.

Signed-off-by: Greg Kroah-Hartman

thunderbolt: Expose router DROM through debugfs

2025-01-05T08:35:03+00:00

Router DROM contains information that might be usable for development
and debugging purposes. For example when new entries are added to the
USB4 spec it is useful to be able to look for them without need to
change the kernel.

For this reason expose the DROM through debugfs.

Signed-off-by: Mika Westerberg

driver core: Constify API device_find_child() and adapt for various usages

2025-01-03T10:19:35+00:00

Constify the following API:
struct device *device_find_child(struct device *dev, void *data,
		int (*match)(struct device *dev, void *data));
To :
struct device *device_find_child(struct device *dev, const void *data,
                                 device_match_t match);
typedef int (*device_match_t)(struct device *dev, const void *data);
with the following reasons:

- Protect caller's match data @*data which is for comparison and lookup
  and the API does not actually need to modify @*data.

- Make the API's parameters (@match)() and @data have the same type as
  all of other device finding APIs (bus|class|driver)_find_device().

- All kinds of existing device match functions can be directly taken
  as the API's argument, they were exported by driver core.

Constify the API and adapt for various existing usages.

BTW, various subsystem changes are squashed into this commit to meet
'git bisect' requirement, and this commit has the minimal and simplest
changes to complement squashing shortcoming, and that may bring extra
code improvement.

Reviewed-by: Alison Schofield 
Reviewed-by: Takashi Sakamoto 
Acked-by: Uwe Kleine-König  # for drivers/pwm
Signed-off-by: Zijun Hu 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Mathieu Poirier 
Link: https://lore.kernel.org/r/20241224-const_dfc_done-v5-4-6623037414d4@quicinc.com
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Handle DisplayPort tunnel activation asynchronously

2025-01-03T09:50:09+00:00

Sometimes setting up a DisplayPort tunnel may take quite long time. The
reason is that the graphics driver (DPRX) is expected to issue read of
certain monitor capabilities over the AUX channel and the "suggested"
timeout from VESA is 5 seconds. If there is no graphics driver loaded
this does not happen and currently we timeout and tear the tunnel down.
The reason for this is that at least Intel discrete USB4 controllers do
not send plug/unplug events about whether the DisplayPort cable from the
GPU to the controller is connected or not, so in order to "release" the
DisplayPort OUT adapter (the one that has monitor connected) we must
tear the tunnel down after this timeout has been elapsed.

In typical cases there is always graphics driver loaded, and also all
the cables are connected but for instance in Intel graphics CI they only
load the graphics driver after the system is fully booted up. This
makes the driver to tear down the DisplayPort tunnel. To help this case
we allow passing bigger or indefinite timeout through a new module
parameter (dprx_timeout). To keep the driver bit more responsive during
that time we change the way DisplayPort tunnels get activated. We first
do the normal tunnel setup and then run the polling of DPRX capabilities
read completion in a separate worker. This also makes the driver to
accept bandwidth requests to already established DisplayPort tunnels
more responsive.

If the tunnel still fails to establish we will tear it down and remove
the DisplayPort IN adapter from the dp_resource list to avoid using it
again (unless we get hotplug to that adapter).

Signed-off-by: Mika Westerberg

thunderbolt: Rework tb_tunnel_consumed_bandwidth()

2025-01-03T09:50:08+00:00

Rework to avoid the goto as it only makes it confusing. Move logging to
happen at the end so we can see all the tunnels this is being called.

Signed-off-by: Mika Westerberg

thunderbolt: Move forward declarations in one place

2025-01-03T09:50:08+00:00

Sometimes we need to have these but move them into one place so that the
code is bit more understanable.

Signed-off-by: Mika Westerberg

thunderbolt: Pass reason to tb_dp_resource_unavailable()

2025-01-03T09:50:08+00:00

Since we are going to call this also when DisplayPort tunnel
establishment fails it is useful to have the reason logged.

Signed-off-by: Mika Westerberg

thunderbolt: Drop tb_tunnel_restart()

2025-01-03T09:50:08+00:00

It is pretty much the same as tb_tunnel_activate() excepts does check
for already activated paths. This is not needed anymore and makes it
more streamlined so drop tb_tunnel_restart() in favour of
tb_tunnel_activate().

Signed-off-by: Mika Westerberg