[Linux-kernel-mentees] [REQUEST] for assistance with fixing WARNING in pvr2_i2c_core_done

Greg KH gregkh at linuxfoundation.org
Fri Jul 24 07:00:34 UTC 2020


On Fri, Jul 24, 2020 at 09:12:27AM +0530, B K Karthik wrote:
> hi,
> 
> I've been looking at https://syzkaller.appspot.com/bug?extid=e74a998ca8f1df9cc332 for quite some time now.
> I think I will be able to fix it with a little assistance.
> 
> I was able to reproduce it, and as er suggestions I tried to unregister the device in the release handler instead of the disconnect handler.
> I tried a few things, but they triggered a general protection fault in kernfs_find_ns()
> 
> Hillf Danton <hdanton at sina.com> said the following. 
> 
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > general protection fault in kernfs_find_ns
> >
> > pvrusb2: Invalid write control endpoint
> > pvrusb2: Invalid write control endpoint
> > pvrusb2: Invalid write control endpoint
> > pvrusb2: Invalid write control endpoint
> > general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] SMP KASAN
> > KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
> > CPU: 0 PID: 78 Comm: pvrusb2-context Not tainted 5.7.0-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > RIP: 0010:kernfs_find_ns+0x31/0x370 fs/kernfs/dir.c:829
> > Code: 49 89 d6 41 55 41 54 55 48 89 fd 53 48 83 ec 08 e8 f4 61 af ff 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 03 00 00 48 8d bd 98 00 00 00 48 8b 5d 70 48
> > RSP: 0018:ffff8881d419f938 EFLAGS: 00010202
> > RAX: dffffc0000000000 RBX: ffffffff863789c0 RCX: ffffffff85a79ba7
> > RDX: 000000000000000e RSI: ffffffff81901d1c RDI: 0000000000000070
> > RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff873ed1e7
> > R10: fffffbfff0e7da3c R11: 0000000000000001 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff863790e0
> > FS:  0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f3a7e248000 CR3: 00000001d2224000 CR4: 00000000001406f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >  kernfs_find_and_get_ns+0x2f/0x60 fs/kernfs/dir.c:906
> >  kernfs_find_and_get include/linux/kernfs.h:548 [inline]
> >  sysfs_unmerge_group+0x5d/0x160 fs/sysfs/group.c:366
> >  dpm_sysfs_remove+0x62/0xb0 drivers/base/power/sysfs.c:790
> 
> [3]
> 
> >  device_del+0x18b/0xd20 drivers/base/core.c:2834
> >  device_unregister+0x22/0xc0 drivers/base/core.c:2889
> >  i2c_unregister_device include/linux/err.h:41 [inline]
> 
> [2]
> 
> >  i2c_client_dev_release+0x39/0x50 drivers/i2c/i2c-core-base.c:465
> >  device_release+0x71/0x200 drivers/base/core.c:1559
> 
> [1] kobject_del() goes before the release cb in kobject_cleanup() and
> kobj is removed from sysfs, see [3] above.
> 
> >  kobject_cleanup lib/kobject.c:693 [inline]
> >  kobject_release lib/kobject.c:722 [inline]
> >  kref_put include/linux/kref.h:65 [inline]
> >  kobject_put+0x245/0x540 lib/kobject.c:739
> >  put_device drivers/base/core.c:2779 [inline]
> >  device_unregister+0x34/0xc0 drivers/base/core.c:2890
> >  i2c_unregister_device+0x38/0x40 include/linux/err.h:41
> 
> Once is enough, see [2] above.
> 
> can you give me a suggestion as to how I am supposed to go about fixing this bug?

That is for you to determine, not for us to tell you how :)

Something is getting the reference counts of these pointers "out of
sync" and it is being freed at the wrong point in time.  The way the I2C
subsytem uses the driver model is a bit different from other subsystems
for various reasons, so it's not always easy to determine what is going
on here.

I would first try to figure out what the normal set of operations should
be (i.e. what should happen before what), and see why that is not
happening here.

good luck!

greg k-h


More information about the Linux-kernel-mentees mailing list