[Letux-kernel] memory corruption in iio_input_bridge

Andreas Kemnade andreas at kemnade.info
Sun Jul 29 09:06:47 CEST 2018


On Sun, 29 Jul 2018 08:40:23 +0200
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> Hi,
> 
> > Am 28.07.2018 um 22:52 schrieb Andreas Kemnade <andreas at kemnade.info>:
> > 
> > Hi,
> > 
> > I think here is the final proof:
> > 
> > I am using this:
> > diff --git a/drivers/iio/industrialio-inputbridge.c b/drivers/iio/industrialio-inputbridge.c
> > index bd5807f31767..c37b55a85b1c 100644
> > --- a/drivers/iio/industrialio-inputbridge.c
> > +++ b/drivers/iio/industrialio-inputbridge.c
> > @@ -92,6 +92,8 @@ static int accel_open(struct input_dev *input)
> > #if 0
> > printk("accel_open()\n");
> > #endif
> > +                print_hex_dump(KERN_INFO, "iio delayed_work open:", DUMP_PREFIX_NONE,
> > +                                                16, 1, &input_work, sizeof(input_work), false);  
> 
> Ah, didn't know that this exists. And hex_dump_to_buffer...
> 
> > 
> >        // someone has opened the input device
> >        // make us start the iio_dev
> > @@ -175,7 +177,11 @@ static int iio_input_register_accel_channel(struct iio_dev *indio_dev, const str
> > //             indio_dev->input = idev;
> > 
> > #if POLLING
> > +               printk("iio delayed work at %px\n", &input_work);
> > +
> >                INIT_DELAYED_WORK(&input_work, inputbridge_work);
> > +                print_hex_dump(KERN_INFO, "iio delayed_work:", DUMP_PREFIX_NONE,
> > +                                                16, 1, &input_work, sizeof(input_work), false);
> > #else
> >                struct iio_cb_buffer *iio_channel_get_all_cb(struct device *dev,
> >                                int (*cb)(const void *data,
> > 
> > 
> > and then I do xxd /dev/input/eventX
> > 
> > from another shell:
> > dmesg | grep -C 3  iio\ delayed
> > 
[...]
> > [    6.092315] iio delayed_work:e0 ff ff ff 04 b4 06 bf 04 b4 06 bf 54 86 06 bf
[...]
> > [    6.195587] iio delayed_work:00 00 00 00 00 00 00 00 00 00 00 00 38 8e 14 c0
[...]
> > [    6.286590] iio delayed_work:00 00 20 00 00 00 00 00 00 00 00 00

> > [    6.309936] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> > [    6.346557] usb usb1: Product: MUSB HDRC host driver
> > [    6.376220] usb usb1: Manufacturer: Linux 4.18.0-rc6-letux+ musb-hcd
> > --
> > [   24.915069] systemd-logind[2717]: New seat seat0.
> > [   26.077636] systemd-logind[2717]: Failed to start user service: Unknown unit: user at 0.service
> > [   26.133728] systemd-logind[2717]: New session 1 of user root.
> > [   69.351837] iio delayed_work open:00 c8 7f ee 00 70 7e ee 00 f8 7d ee 54 86 06 bf
> > [   69.360107] iio delayed_work open:00 00 00 00 00 00 00 00 00 00 00 00 38 8e 14 c0
> > [   69.370056] iio delayed_work open:00 00 20 00 00 00 00 00 00 00 00 00  
> 
> ^^^ why is this print_hex_dump shorter? Or is it an effect of output buffering?

Hmm, same size for both. one print_hex_dump() gives multiple lines of
output if the buffer to be printed is too big.

> 
> > [   69.377502] ------------[ cut here ]------------
> > [   69.382385] WARNING: CPU: 0 PID: 3281 at ../kernel/workqueue.c:1513 __queue_delayed_work+0xd8/0x140
> > [   69.391845] Modules linked in: bnep bluetooth ecdh_generic ipv6 usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs dm_crypt dm_mod dax arc4 wl18xx wlcore mac80211 cfg80211 omapdrm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks pps_gpio panel_tpo_td028ttec1 snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_twl4030 pps_core encoder_opa362 wwan_on_off snd_soc_gtm601 pwm_omap_dmtimer connector_analog_tv generic_adc_battery pwm_bl bmp280_spi ov9655 v4l2_fwnode wlcore_sdio v4l2_common bq27xxx_battery_hdq bq27xxx_battery omap_hdq omap2430 bmp280_i2c videodev bmp280 bmc150_accel_i2c bmc150_magn_i2c at24 media bmc150_magn bmc150_accel_core leds_tca6507 tsc2007 bno055 industrialio_triggered_buffer kfifo_buf phy_twl4030_usb snd_soc_omap_mcbsp
> > 
> > So the first 12 bytes are changing their value, that are the prev/next pointers of the list_head (which initially point to itself) and work_struct.data
> > 
> > I checked:
> > inputbridge_work is never called.  
> 
> That is really strange.
> 
> Could you please add another printk("iio delayed work at %px\n", &input_work) to accel_open
> 
> If that changes we have multiple drivers running for one device...

will probably try more in the evening.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180729/c55ea3c8/attachment-0001.asc>


More information about the Letux-kernel mailing list