[PATCH 0/2] iio: hid-sensors: fix shared callbacks in temperature and humidity

hid-sensor-temperature and hid-sensor-humidity keep a single static
struct hid_sensor_hub_callbacks for all of their instances and
overwrite its pdev on every probe.  The other HID sensor drivers keep
theirs per instance.  With two temperature sensors, input reports for
one are delivered with the other's platform device; once that device
is removed, platform_get_drvdata() returns NULL and
temperature_capture_sample() dereferences it:

  BUG: kernel NULL pointer dereference, address: 00000000000003a8
  RIP: 0010:temperature_capture_sample+0xd/0x50 [hid_sensor_temperature]
  Call Trace:
   sensor_hub_raw_event+0x3fc/0x7a0 [hid_sensor_hub]
   __hid_input_report+0x140/0x230 [hid]
   hid_safe_input_report+0x14/0x30 [hid]
   uhid_char_write+0x1f6/0x340 [uhid]

The oops happens with the hub's spinlock held, so the hub's removal
then hangs until reboot.

I hit this with a userspace daemon that presents a USB thermometer as
a HID temperature sensor through uhid: creating a second uhid sensor
and destroying it while the first keeps sending input reports
reproduced it twice on 7.0. 

The patches move the callbacks into each driver's state, as
hid-sensor-accel-3d does.  Humidity has the same code but I have not
reproduced it there.

Not addressed here: sensor_hub_raw_event() looks up the callback under
dyn_callback_lock and calls it under pdata->lock, while
sensor_hub_remove_callback() takes only dyn_callback_lock, so a
report racing a remove can still reach a callback whose driver is
going away.  That predates this series.

Christopher Hoover (2):
  iio: temperature: hid-sensor-temperature: Use per-instance callbacks
  iio: humidity: hid-sensor-humidity: Use per-instance callbacks

 drivers/iio/humidity/hid-sensor-humidity.c       | 12 +++++-------
 drivers/iio/temperature/hid-sensor-temperature.c | 12 +++++-------
 2 files changed, 10 insertions(+), 14 deletions(-)


base-commit: 9ee8306121495d2a25aa5d1bfd519f2748786b83
-- 
2.43.0