linux-stable.git/drivers/usb, branch v5.4.133 Linux kernel stable tree usb: dwc2: Don't reset the core after setting turnaround time 2021-07-14T14:53:42+00:00 Clément Lassieur clement@lassieur.org 2021-06-03T15:59:21+00:00 d7e33cc4789b0b484c09f83481473ace5efcd420 [ Upstream commit aafe93516b8567ab5864e1f4cd3eeabc54fb0e5a ] Every time the hub signals a reset while we (device) are hsotg->connected, dwc2_hsotg_core_init_disconnected() is called, which in turn calls dwc2_hs_phy_init(). GUSBCFG.USBTrdTim is cleared upon Core Soft Reset, so if hsotg->params.phy_utmi_width is 8-bit, the value of GUSBCFG.USBTrdTim (the default one: 0x5, corresponding to 16-bit) is always different from hsotg->params.phy_utmi_width, thus dwc2_core_reset() is called every time (usbcfg != usbcfg_old), which causes 2 issues: 1) The call to dwc2_core_reset() does another reset 300us after the initial Chirp K of the first reset (which should last at least Tuch = 1ms), and messes up the High-speed Detection Handshake: both hub and device drive current into the D+ and D- lines at the same time. 2) GUSBCFG.USBTrdTim is cleared by the second reset, so its value is always the default one (0x5). Setting GUSBCFG.USBTrdTim after the potential call to dwc2_core_reset() fixes both issues. It is now set even when select_phy is false because the cost of the Core Soft Reset is removed. Fixes: 1e868545f2bb ("usb: dwc2: gadget: Move gadget phy init into core phy init") Signed-off-by: Clément Lassieur <clement@lassieur.org> Link: https://lore.kernel.org/r/20210603155921.940651-1-clement@lassieur.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit aafe93516b8567ab5864e1f4cd3eeabc54fb0e5a ]

Every time the hub signals a reset while we (device) are hsotg->connected,
dwc2_hsotg_core_init_disconnected() is called, which in turn calls
dwc2_hs_phy_init().

GUSBCFG.USBTrdTim is cleared upon Core Soft Reset, so if
hsotg->params.phy_utmi_width is 8-bit, the value of GUSBCFG.USBTrdTim (the
default one: 0x5, corresponding to 16-bit) is always different from
hsotg->params.phy_utmi_width, thus dwc2_core_reset() is called every
time (usbcfg != usbcfg_old), which causes 2 issues:

1) The call to dwc2_core_reset() does another reset 300us after the initial
Chirp K of the first reset (which should last at least Tuch = 1ms), and
messes up the High-speed Detection Handshake: both hub and device drive
current into the D+ and D- lines at the same time.

2) GUSBCFG.USBTrdTim is cleared by the second reset, so its value is always
the default one (0x5).

Setting GUSBCFG.USBTrdTim after the potential call to dwc2_core_reset()
fixes both issues.  It is now set even when select_phy is false because the
cost of the Core Soft Reset is removed.

Fixes: 1e868545f2bb ("usb: dwc2: gadget: Move gadget phy init into core phy init")
Signed-off-by: Clément Lassieur <clement@lassieur.org>
Link: https://lore.kernel.org/r/20210603155921.940651-1-clement@lassieur.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: gadget: f_fs: Fix setting of device and driver data cross-references 2021-07-14T14:53:42+00:00 Andrew Gabbasov andrew_gabbasov@mentor.com 2021-06-03T17:15:07+00:00 a95bbfe690312f05fae3e3d484148d66797cce52 [ Upstream commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 ] FunctionFS device structure 'struct ffs_dev' and driver data structure 'struct ffs_data' are bound to each other with cross-reference pointers 'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one is supposed to be valid through the whole life of 'struct ffs_data' (and while 'struct ffs_dev' exists non-freed), the second one is cleared in 'ffs_closed()' (called from 'ffs_data_reset()' or the last 'ffs_data_put()'). This can be called several times, alternating in different order with 'ffs_free_inst()', that, if possible, clears the other cross-reference. As a result, different cases of these calls order may leave stale cross-reference pointers, used when the pointed structure is already freed. Even if it occasionally doesn't cause kernel crash, this error is reported by KASAN-enabled kernel configuration. For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst"). The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()'] now causes KASAN reported error [1], when 'ffs_data_reset()' clears 'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev', but can't clear 'ffs_data->private_data', which is then accessed in 'ffs_closed()' called from 'ffs_data_put()'. This happens since 'ffs_dev->ffs_data' reference is cleared too early. Moreover, one more use case, when 'ffs_free_inst()' is called immediately after mounting FunctionFS device (that is before the descriptors are written and 'ffs_ready()' is called), and then 'ffs_data_reset()' or 'ffs_data_put()' is called from accessing "ep0" file or unmounting the device. This causes KASAN error report like [2], since 'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly clear 'ffs_data->private_data', that is later accessed to freed structure. Fix these (and may be other) cases of stale pointers access by moving setting and clearing of the mentioned cross-references to the single places, setting both of them when 'struct ffs_data' is created and bound to 'struct ffs_dev', and clearing both of them when one of the structures is destroyed. It seems convenient to make this pointer initialization and structures binding in 'ffs_acquire_dev()' and make pointers clearing in 'ffs_release_dev()'. This required some changes in these functions parameters and return types. Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()' is called without unmounting the device, and "release_dev" callback is not called at all, or (2) "release_dev" callback is called before "ffs_closed" callback on unmounting, which seems to be not correctly nested with "acquire_dev" and "ffs_ready" callbacks. Make this cleanup togther with other mentioned 'ffs_release_dev()' changes. [1] ================================================================== root@rcar-gen3:~# mkdir /dev/cfs root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 64.340664] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# cd /dev/ffs root@rcar-gen3:/dev/ffs# /home/root/ffs-test ffs-test: info: ep0: writing descriptors (in v2 format) [ 83.181442] read descriptors [ 83.186085] read strings ffs-test: info: ep0: writing strings ffs-test: dbg: ep1: starting ffs-test: dbg: ep2: starting ffs-test: info: ep1: starts ffs-test: info: ep2: starts ffs-test: info: ep0: starts ^C root@rcar-gen3:/dev/ffs# cd /home/root/ root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 98.935061] unloading root@rcar-gen3:~# umount /dev/ffs [ 102.734301] ================================================================== [ 102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997 [ 102.756709] [ 102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8 [ 102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 102.772179] Call trace: [ 102.774779] dump_backtrace+0x0/0x330 [ 102.778653] show_stack+0x20/0x2c [ 102.782152] dump_stack+0x11c/0x1ac [ 102.785833] print_address_description.constprop.0+0x30/0x274 [ 102.791862] kasan_report+0x14c/0x1c8 [ 102.795719] __asan_report_store1_noabort+0x34/0x58 [ 102.800840] ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.805801] ffs_fs_kill_sb+0x50/0x84 [usb_f_fs] [ 102.810663] deactivate_locked_super+0xa0/0xf0 [ 102.815339] deactivate_super+0x98/0xac [ 102.819378] cleanup_mnt+0xd0/0x1b0 [ 102.823057] __cleanup_mnt+0x1c/0x28 [ 102.826823] task_work_run+0x104/0x180 [ 102.830774] do_notify_resume+0x458/0x14e0 [ 102.835083] work_pending+0xc/0x5f8 [ 102.838762] [ 102.840357] Allocated by task 2988: [ 102.844032] kasan_save_stack+0x28/0x58 [ 102.848071] kasan_set_track+0x28/0x3c [ 102.852016] ____kasan_kmalloc+0x84/0x9c [ 102.856142] __kasan_kmalloc+0x10/0x1c [ 102.860088] __kmalloc+0x214/0x2f8 [ 102.863678] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 102.868990] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 102.873942] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 102.880629] usb_get_function_instance+0x64/0x68 [libcomposite] [ 102.886858] function_make+0x128/0x1ec [libcomposite] [ 102.892185] configfs_mkdir+0x330/0x590 [configfs] [ 102.897245] vfs_mkdir+0x12c/0x1bc [ 102.900835] do_mkdirat+0x180/0x1d0 [ 102.904513] __arm64_sys_mkdirat+0x80/0x94 [ 102.908822] invoke_syscall+0xf8/0x25c [ 102.912772] el0_svc_common.constprop.0+0x150/0x1a0 [ 102.917891] do_el0_svc+0xa0/0xd4 [ 102.921386] el0_svc+0x24/0x34 [ 102.924613] el0_sync_handler+0xcc/0x154 [ 102.928743] el0_sync+0x198/0x1c0 [ 102.932238] [ 102.933832] Freed by task 2996: [ 102.937144] kasan_save_stack+0x28/0x58 [ 102.941181] kasan_set_track+0x28/0x3c [ 102.945128] kasan_set_free_info+0x28/0x4c [ 102.949435] ____kasan_slab_free+0x104/0x118 [ 102.953921] __kasan_slab_free+0x18/0x24 [ 102.958047] slab_free_freelist_hook+0x148/0x1f0 [ 102.962897] kfree+0x318/0x440 [ 102.966123] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 102.971075] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 102.977302] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 102.982344] config_item_put+0x140/0x1a4 [configfs] [ 102.987486] configfs_rmdir+0x3fc/0x518 [configfs] [ 102.992535] vfs_rmdir+0x114/0x234 [ 102.996122] do_rmdir+0x274/0x2b0 [ 102.999617] __arm64_sys_unlinkat+0x94/0xc8 [ 103.004015] invoke_syscall+0xf8/0x25c [ 103.007961] el0_svc_common.constprop.0+0x150/0x1a0 [ 103.013080] do_el0_svc+0xa0/0xd4 [ 103.016575] el0_svc+0x24/0x34 [ 103.019801] el0_sync_handler+0xcc/0x154 [ 103.023930] el0_sync+0x198/0x1c0 [ 103.027426] [ 103.029020] The buggy address belongs to the object at ffff0004d46ff500 [ 103.029020] which belongs to the cache kmalloc-128 of size 128 [ 103.042079] The buggy address is located 73 bytes inside of [ 103.042079] 128-byte region [ffff0004d46ff500, ffff0004d46ff580) [ 103.054236] The buggy address belongs to the page: [ 103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe [ 103.070437] head:0000000021aa849b order:1 compound_mapcount:0 [ 103.076456] flags: 0x8000000000010200(slab|head|zone=2) [ 103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300 [ 103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000 [ 103.098150] page dumped because: kasan: bad access detected [ 103.103985] [ 103.105578] Memory state around the buggy address: [ 103.110602] ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.118161] ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.133284] ^ [ 103.139120] ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.146679] ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.154238] ================================================================== [ 103.161792] Disabling lock debugging due to kernel taint [ 103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e [ 103.175406] Mem abort info: [ 103.178457] ESR = 0x96000004 [ 103.181609] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.187020] SET = 0, FnV = 0 [ 103.190185] EA = 0, S1PTW = 0 [ 103.193417] Data abort info: [ 103.196385] ISV = 0, ISS = 0x00000004 [ 103.200315] CM = 0, WnR = 0 [ 103.203366] [0037801d6000018e] address between user and kernel address ranges [ 103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4 [ 103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G B 5.13.0-rc4+ #8 [ 103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 103.290385] sp : ffff800014777a80 [ 103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000 [ 103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4 [ 103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0 [ 103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000 [ 103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658 [ 103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648 [ 103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000 [ 103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001 [ 103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70 [ 103.365766] Call trace: [ 103.368235] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.373076] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 103.377829] ffs_data_closed+0x1ec/0x244 [usb_f_fs] [ 103.382755] ffs_fs_kill_sb+0x70/0x84 [usb_f_fs] [ 103.387420] deactivate_locked_super+0xa0/0xf0 [ 103.391905] deactivate_super+0x98/0xac [ 103.395776] cleanup_mnt+0xd0/0x1b0 [ 103.399299] __cleanup_mnt+0x1c/0x28 [ 103.402906] task_work_run+0x104/0x180 [ 103.406691] do_notify_resume+0x458/0x14e0 [ 103.410823] work_pending+0xc/0x5f8 [ 103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 103.420490] ---[ end trace 57b43a50e8244f57 ]--- Segmentation fault root@rcar-gen3:~# ================================================================== [2] ================================================================== root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 54.766480] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 63.197597] unloading root@rcar-gen3:~# cat /dev/ffs/ep0 cat: read error:[ 67.213506] ================================================================== [ 67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994 [ 67.236446] [ 67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8 [ 67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.251624] Call trace: [ 67.254212] dump_backtrace+0x0/0x330 [ 67.258081] show_stack+0x20/0x2c [ 67.261579] dump_stack+0x11c/0x1ac [ 67.265260] print_address_description.constprop.0+0x30/0x274 [ 67.271286] kasan_report+0x14c/0x1c8 [ 67.275143] __asan_report_store1_noabort+0x34/0x58 [ 67.280265] ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.285220] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.290172] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.295305] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.300256] __fput+0x304/0x580 [ 67.303576] ____fput+0x18/0x24 [ 67.306893] task_work_run+0x104/0x180 [ 67.310846] do_notify_resume+0x458/0x14e0 [ 67.315154] work_pending+0xc/0x5f8 [ 67.318834] [ 67.320429] Allocated by task 2988: [ 67.324105] kasan_save_stack+0x28/0x58 [ 67.328144] kasan_set_track+0x28/0x3c [ 67.332090] ____kasan_kmalloc+0x84/0x9c [ 67.336217] __kasan_kmalloc+0x10/0x1c [ 67.340163] __kmalloc+0x214/0x2f8 [ 67.343754] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 67.349066] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 67.354017] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 67.360705] usb_get_function_instance+0x64/0x68 [libcomposite] [ 67.366934] function_make+0x128/0x1ec [libcomposite] [ 67.372260] configfs_mkdir+0x330/0x590 [configfs] [ 67.377320] vfs_mkdir+0x12c/0x1bc [ 67.380911] do_mkdirat+0x180/0x1d0 [ 67.384589] __arm64_sys_mkdirat+0x80/0x94 [ 67.388899] invoke_syscall+0xf8/0x25c [ 67.392850] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.397969] do_el0_svc+0xa0/0xd4 [ 67.401464] el0_svc+0x24/0x34 [ 67.404691] el0_sync_handler+0xcc/0x154 [ 67.408819] el0_sync+0x198/0x1c0 [ 67.412315] [ 67.413909] Freed by task 2993: [ 67.417220] kasan_save_stack+0x28/0x58 [ 67.421257] kasan_set_track+0x28/0x3c [ 67.425204] kasan_set_free_info+0x28/0x4c [ 67.429513] ____kasan_slab_free+0x104/0x118 [ 67.434001] __kasan_slab_free+0x18/0x24 [ 67.438128] slab_free_freelist_hook+0x148/0x1f0 [ 67.442978] kfree+0x318/0x440 [ 67.446205] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 67.451156] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 67.457385] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 67.462428] config_item_put+0x140/0x1a4 [configfs] [ 67.467570] configfs_rmdir+0x3fc/0x518 [configfs] [ 67.472626] vfs_rmdir+0x114/0x234 [ 67.476215] do_rmdir+0x274/0x2b0 [ 67.479710] __arm64_sys_unlinkat+0x94/0xc8 [ 67.484108] invoke_syscall+0xf8/0x25c [ 67.488055] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.493175] do_el0_svc+0xa0/0xd4 [ 67.496671] el0_svc+0x24/0x34 [ 67.499896] el0_sync_handler+0xcc/0x154 [ 67.504024] el0_sync+0x198/0x1c0 [ 67.507520] [ 67.509114] The buggy address belongs to the object at ffff0004c26e9700 [ 67.509114] which belongs to the cache kmalloc-128 of size 128 [ 67.522171] The buggy address is located 74 bytes inside of [ 67.522171] 128-byte region [ffff0004c26e9700, ffff0004c26e9780) [ 67.534328] The buggy address belongs to the page: [ 67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8 [ 67.549175] head:000000003177a217 order:1 compound_mapcount:0 [ 67.555195] flags: 0x8000000000010200(slab|head|zone=2) [ 67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300 [ 67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 67.576890] page dumped because: kasan: bad access detected [ 67.582725] [ 67.584318] Memory state around the buggy address: [ 67.589343] ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.596903] ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.612022] ^ [ 67.617860] ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.625421] ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.632981] ================================================================== [ 67.640535] Disabling lock debugging due to kernel taint File descriptor[ 67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d in bad state [ 67.655456] Mem abort info: [ 67.659619] ESR = 0x96000004 [ 67.662801] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.668225] SET = 0, FnV = 0 [ 67.671375] EA = 0, S1PTW = 0 [ 67.674613] Data abort info: [ 67.677587] ISV = 0, ISS = 0x00000004 [ 67.681522] CM = 0, WnR = 0 [ 67.684588] [fabb801d4000018d] address between user and kernel address ranges [ 67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4 [ 67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G B 5.13.0-rc4+ #8 [ 67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 67.771365] sp : ffff800014767ad0 [ 67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0 [ 67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d [ 67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0 [ 67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000 [ 67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa [ 67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014 [ 67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000 [ 67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001 [ 67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d [ 67.846748] Call trace: [ 67.849218] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.854058] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.858810] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.863736] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.868488] __fput+0x304/0x580 [ 67.871665] ____fput+0x18/0x24 [ 67.874837] task_work_run+0x104/0x180 [ 67.878622] do_notify_resume+0x458/0x14e0 [ 67.882754] work_pending+0xc/0x5f8 [ 67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 67.892422] ---[ end trace 6d7cedf53d7abbea ]--- Segmentation fault root@rcar-gen3:~# ================================================================== Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code") Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference") Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst") Reported-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 ]

FunctionFS device structure 'struct ffs_dev' and driver data structure
'struct ffs_data' are bound to each other with cross-reference pointers
'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one
is supposed to be valid through the whole life of 'struct ffs_data'
(and while 'struct ffs_dev' exists non-freed), the second one is cleared
in 'ffs_closed()' (called from 'ffs_data_reset()' or the last
'ffs_data_put()'). This can be called several times, alternating in
different order with 'ffs_free_inst()', that, if possible, clears
the other cross-reference.

As a result, different cases of these calls order may leave stale
cross-reference pointers, used when the pointed structure is already
freed. Even if it occasionally doesn't cause kernel crash, this error
is reported by KASAN-enabled kernel configuration.

For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was
fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in
ffs_free_inst").

The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()']
now causes KASAN reported error [1], when 'ffs_data_reset()' clears
'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev',
but can't clear 'ffs_data->private_data', which is then accessed
in 'ffs_closed()' called from 'ffs_data_put()'. This happens since
'ffs_dev->ffs_data' reference is cleared too early.

Moreover, one more use case, when 'ffs_free_inst()' is called immediately
after mounting FunctionFS device (that is before the descriptors are
written and 'ffs_ready()' is called), and then 'ffs_data_reset()'
or 'ffs_data_put()' is called from accessing "ep0" file or unmounting
the device. This causes KASAN error report like [2], since
'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly
clear 'ffs_data->private_data', that is later accessed to freed structure.

Fix these (and may be other) cases of stale pointers access by moving
setting and clearing of the mentioned cross-references to the single
places, setting both of them when 'struct ffs_data' is created and
bound to 'struct ffs_dev', and clearing both of them when one of the
structures is destroyed. It seems convenient to make this pointer
initialization and structures binding in 'ffs_acquire_dev()' and
make pointers clearing in 'ffs_release_dev()'. This required some
changes in these functions parameters and return types.

Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor
issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()'
is called without unmounting the device, and "release_dev" callback
is not called at all, or (2) "release_dev" callback is called before
"ffs_closed" callback on unmounting, which seems to be not correctly
nested with "acquire_dev" and "ffs_ready" callbacks.
Make this cleanup togther with other mentioned 'ffs_release_dev()' changes.

[1]
==================================================================
root@rcar-gen3:~# mkdir /dev/cfs
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[   64.340664] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# cd /dev/ffs
root@rcar-gen3:/dev/ffs# /home/root/ffs-test
ffs-test: info: ep0: writing descriptors (in v2 format)
[   83.181442] read descriptors
[   83.186085] read strings
ffs-test: info: ep0: writing strings
ffs-test: dbg:  ep1: starting
ffs-test: dbg:  ep2: starting
ffs-test: info: ep1: starts
ffs-test: info: ep2: starts
ffs-test: info: ep0: starts

^C
root@rcar-gen3:/dev/ffs# cd /home/root/
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[   98.935061] unloading
root@rcar-gen3:~# umount /dev/ffs
[  102.734301] ==================================================================
[  102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs]
[  102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997
[  102.756709]
[  102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8
[  102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[  102.772179] Call trace:
[  102.774779]  dump_backtrace+0x0/0x330
[  102.778653]  show_stack+0x20/0x2c
[  102.782152]  dump_stack+0x11c/0x1ac
[  102.785833]  print_address_description.constprop.0+0x30/0x274
[  102.791862]  kasan_report+0x14c/0x1c8
[  102.795719]  __asan_report_store1_noabort+0x34/0x58
[  102.800840]  ffs_release_dev+0x64/0xa8 [usb_f_fs]
[  102.805801]  ffs_fs_kill_sb+0x50/0x84 [usb_f_fs]
[  102.810663]  deactivate_locked_super+0xa0/0xf0
[  102.815339]  deactivate_super+0x98/0xac
[  102.819378]  cleanup_mnt+0xd0/0x1b0
[  102.823057]  __cleanup_mnt+0x1c/0x28
[  102.826823]  task_work_run+0x104/0x180
[  102.830774]  do_notify_resume+0x458/0x14e0
[  102.835083]  work_pending+0xc/0x5f8
[  102.838762]
[  102.840357] Allocated by task 2988:
[  102.844032]  kasan_save_stack+0x28/0x58
[  102.848071]  kasan_set_track+0x28/0x3c
[  102.852016]  ____kasan_kmalloc+0x84/0x9c
[  102.856142]  __kasan_kmalloc+0x10/0x1c
[  102.860088]  __kmalloc+0x214/0x2f8
[  102.863678]  kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[  102.868990]  ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[  102.873942]  try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[  102.880629]  usb_get_function_instance+0x64/0x68 [libcomposite]
[  102.886858]  function_make+0x128/0x1ec [libcomposite]
[  102.892185]  configfs_mkdir+0x330/0x590 [configfs]
[  102.897245]  vfs_mkdir+0x12c/0x1bc
[  102.900835]  do_mkdirat+0x180/0x1d0
[  102.904513]  __arm64_sys_mkdirat+0x80/0x94
[  102.908822]  invoke_syscall+0xf8/0x25c
[  102.912772]  el0_svc_common.constprop.0+0x150/0x1a0
[  102.917891]  do_el0_svc+0xa0/0xd4
[  102.921386]  el0_svc+0x24/0x34
[  102.924613]  el0_sync_handler+0xcc/0x154
[  102.928743]  el0_sync+0x198/0x1c0
[  102.932238]
[  102.933832] Freed by task 2996:
[  102.937144]  kasan_save_stack+0x28/0x58
[  102.941181]  kasan_set_track+0x28/0x3c
[  102.945128]  kasan_set_free_info+0x28/0x4c
[  102.949435]  ____kasan_slab_free+0x104/0x118
[  102.953921]  __kasan_slab_free+0x18/0x24
[  102.958047]  slab_free_freelist_hook+0x148/0x1f0
[  102.962897]  kfree+0x318/0x440
[  102.966123]  ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[  102.971075]  usb_put_function_instance+0x84/0xa4 [libcomposite]
[  102.977302]  ffs_attr_release+0x18/0x24 [usb_f_fs]
[  102.982344]  config_item_put+0x140/0x1a4 [configfs]
[  102.987486]  configfs_rmdir+0x3fc/0x518 [configfs]
[  102.992535]  vfs_rmdir+0x114/0x234
[  102.996122]  do_rmdir+0x274/0x2b0
[  102.999617]  __arm64_sys_unlinkat+0x94/0xc8
[  103.004015]  invoke_syscall+0xf8/0x25c
[  103.007961]  el0_svc_common.constprop.0+0x150/0x1a0
[  103.013080]  do_el0_svc+0xa0/0xd4
[  103.016575]  el0_svc+0x24/0x34
[  103.019801]  el0_sync_handler+0xcc/0x154
[  103.023930]  el0_sync+0x198/0x1c0
[  103.027426]
[  103.029020] The buggy address belongs to the object at ffff0004d46ff500
[  103.029020]  which belongs to the cache kmalloc-128 of size 128
[  103.042079] The buggy address is located 73 bytes inside of
[  103.042079]  128-byte region [ffff0004d46ff500, ffff0004d46ff580)
[  103.054236] The buggy address belongs to the page:
[  103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe
[  103.070437] head:0000000021aa849b order:1 compound_mapcount:0
[  103.076456] flags: 0x8000000000010200(slab|head|zone=2)
[  103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300
[  103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000
[  103.098150] page dumped because: kasan: bad access detected
[  103.103985]
[  103.105578] Memory state around the buggy address:
[  103.110602]  ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  103.118161]  ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  103.133284]                                               ^
[  103.139120]  ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  103.146679]  ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  103.154238] ==================================================================
[  103.161792] Disabling lock debugging due to kernel taint
[  103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e
[  103.175406] Mem abort info:
[  103.178457]   ESR = 0x96000004
[  103.181609]   EC = 0x25: DABT (current EL), IL = 32 bits
[  103.187020]   SET = 0, FnV = 0
[  103.190185]   EA = 0, S1PTW = 0
[  103.193417] Data abort info:
[  103.196385]   ISV = 0, ISS = 0x00000004
[  103.200315]   CM = 0, WnR = 0
[  103.203366] [0037801d6000018e] address between user and kernel address ranges
[  103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[  103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4
[  103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G    B             5.13.0-rc4+ #8
[  103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[  103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[  103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[  103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[  103.290385] sp : ffff800014777a80
[  103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000
[  103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4
[  103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0
[  103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000
[  103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[  103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658
[  103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648
[  103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000
[  103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001
[  103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70
[  103.365766] Call trace:
[  103.368235]  ffs_data_clear+0x138/0x370 [usb_f_fs]
[  103.373076]  ffs_data_reset+0x20/0x304 [usb_f_fs]
[  103.377829]  ffs_data_closed+0x1ec/0x244 [usb_f_fs]
[  103.382755]  ffs_fs_kill_sb+0x70/0x84 [usb_f_fs]
[  103.387420]  deactivate_locked_super+0xa0/0xf0
[  103.391905]  deactivate_super+0x98/0xac
[  103.395776]  cleanup_mnt+0xd0/0x1b0
[  103.399299]  __cleanup_mnt+0x1c/0x28
[  103.402906]  task_work_run+0x104/0x180
[  103.406691]  do_notify_resume+0x458/0x14e0
[  103.410823]  work_pending+0xc/0x5f8
[  103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[  103.420490] ---[ end trace 57b43a50e8244f57 ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================

[2]
==================================================================
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~#
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[   54.766480] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[   63.197597] unloading
root@rcar-gen3:~# cat /dev/ffs/ep0
cat: read error:[   67.213506] ==================================================================
[   67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs]
[   67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994
[   67.236446]
[   67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8
[   67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[   67.251624] Call trace:
[   67.254212]  dump_backtrace+0x0/0x330
[   67.258081]  show_stack+0x20/0x2c
[   67.261579]  dump_stack+0x11c/0x1ac
[   67.265260]  print_address_description.constprop.0+0x30/0x274
[   67.271286]  kasan_report+0x14c/0x1c8
[   67.275143]  __asan_report_store1_noabort+0x34/0x58
[   67.280265]  ffs_data_clear+0x70/0x370 [usb_f_fs]
[   67.285220]  ffs_data_reset+0x20/0x304 [usb_f_fs]
[   67.290172]  ffs_data_closed+0x240/0x244 [usb_f_fs]
[   67.295305]  ffs_ep0_release+0x40/0x54 [usb_f_fs]
[   67.300256]  __fput+0x304/0x580
[   67.303576]  ____fput+0x18/0x24
[   67.306893]  task_work_run+0x104/0x180
[   67.310846]  do_notify_resume+0x458/0x14e0
[   67.315154]  work_pending+0xc/0x5f8
[   67.318834]
[   67.320429] Allocated by task 2988:
[   67.324105]  kasan_save_stack+0x28/0x58
[   67.328144]  kasan_set_track+0x28/0x3c
[   67.332090]  ____kasan_kmalloc+0x84/0x9c
[   67.336217]  __kasan_kmalloc+0x10/0x1c
[   67.340163]  __kmalloc+0x214/0x2f8
[   67.343754]  kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[   67.349066]  ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[   67.354017]  try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[   67.360705]  usb_get_function_instance+0x64/0x68 [libcomposite]
[   67.366934]  function_make+0x128/0x1ec [libcomposite]
[   67.372260]  configfs_mkdir+0x330/0x590 [configfs]
[   67.377320]  vfs_mkdir+0x12c/0x1bc
[   67.380911]  do_mkdirat+0x180/0x1d0
[   67.384589]  __arm64_sys_mkdirat+0x80/0x94
[   67.388899]  invoke_syscall+0xf8/0x25c
[   67.392850]  el0_svc_common.constprop.0+0x150/0x1a0
[   67.397969]  do_el0_svc+0xa0/0xd4
[   67.401464]  el0_svc+0x24/0x34
[   67.404691]  el0_sync_handler+0xcc/0x154
[   67.408819]  el0_sync+0x198/0x1c0
[   67.412315]
[   67.413909] Freed by task 2993:
[   67.417220]  kasan_save_stack+0x28/0x58
[   67.421257]  kasan_set_track+0x28/0x3c
[   67.425204]  kasan_set_free_info+0x28/0x4c
[   67.429513]  ____kasan_slab_free+0x104/0x118
[   67.434001]  __kasan_slab_free+0x18/0x24
[   67.438128]  slab_free_freelist_hook+0x148/0x1f0
[   67.442978]  kfree+0x318/0x440
[   67.446205]  ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[   67.451156]  usb_put_function_instance+0x84/0xa4 [libcomposite]
[   67.457385]  ffs_attr_release+0x18/0x24 [usb_f_fs]
[   67.462428]  config_item_put+0x140/0x1a4 [configfs]
[   67.467570]  configfs_rmdir+0x3fc/0x518 [configfs]
[   67.472626]  vfs_rmdir+0x114/0x234
[   67.476215]  do_rmdir+0x274/0x2b0
[   67.479710]  __arm64_sys_unlinkat+0x94/0xc8
[   67.484108]  invoke_syscall+0xf8/0x25c
[   67.488055]  el0_svc_common.constprop.0+0x150/0x1a0
[   67.493175]  do_el0_svc+0xa0/0xd4
[   67.496671]  el0_svc+0x24/0x34
[   67.499896]  el0_sync_handler+0xcc/0x154
[   67.504024]  el0_sync+0x198/0x1c0
[   67.507520]
[   67.509114] The buggy address belongs to the object at ffff0004c26e9700
[   67.509114]  which belongs to the cache kmalloc-128 of size 128
[   67.522171] The buggy address is located 74 bytes inside of
[   67.522171]  128-byte region [ffff0004c26e9700, ffff0004c26e9780)
[   67.534328] The buggy address belongs to the page:
[   67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8
[   67.549175] head:000000003177a217 order:1 compound_mapcount:0
[   67.555195] flags: 0x8000000000010200(slab|head|zone=2)
[   67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300
[   67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
[   67.576890] page dumped because: kasan: bad access detected
[   67.582725]
[   67.584318] Memory state around the buggy address:
[   67.589343]  ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   67.596903]  ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   67.612022]                                               ^
[   67.617860]  ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   67.625421]  ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.632981] ==================================================================
[   67.640535] Disabling lock debugging due to kernel taint
 File descriptor[   67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d
 in bad state
[   67.655456] Mem abort info:
[   67.659619]   ESR = 0x96000004
[   67.662801]   EC = 0x25: DABT (current EL), IL = 32 bits
[   67.668225]   SET = 0, FnV = 0
[   67.671375]   EA = 0, S1PTW = 0
[   67.674613] Data abort info:
[   67.677587]   ISV = 0, ISS = 0x00000004
[   67.681522]   CM = 0, WnR = 0
[   67.684588] [fabb801d4000018d] address between user and kernel address ranges
[   67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[   67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4
[   67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G    B             5.13.0-rc4+ #8
[   67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[   67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[   67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[   67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[   67.771365] sp : ffff800014767ad0
[   67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0
[   67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d
[   67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0
[   67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000
[   67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa
[   67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014
[   67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000
[   67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001
[   67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d
[   67.846748] Call trace:
[   67.849218]  ffs_data_clear+0x138/0x370 [usb_f_fs]
[   67.854058]  ffs_data_reset+0x20/0x304 [usb_f_fs]
[   67.858810]  ffs_data_closed+0x240/0x244 [usb_f_fs]
[   67.863736]  ffs_ep0_release+0x40/0x54 [usb_f_fs]
[   67.868488]  __fput+0x304/0x580
[   67.871665]  ____fput+0x18/0x24
[   67.874837]  task_work_run+0x104/0x180
[   67.878622]  do_notify_resume+0x458/0x14e0
[   67.882754]  work_pending+0xc/0x5f8
[   67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[   67.892422] ---[ end trace 6d7cedf53d7abbea ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================

Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code")
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst")
Reported-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
xhci: solve a double free problem while doing s4 2021-07-14T14:53:01+00:00 Zhangjiantao (Kirin, nanjing) water.zhangjiantao@huawei.com 2021-06-17T15:03:54+00:00 87a365a4ddeccc619e2f963d7a1bdbcce46148ac commit b31d9d6d7abbf6483b871b6370bc31c930d53f54 upstream. when system is doing s4, the process of xhci_resume may be as below: 1、xhci_mem_cleanup 2、xhci_init->xhci_mem_init->xhci_mem_cleanup(when memory is not enough). xhci_mem_cleanup will be executed twice when system is out of memory. xhci->port_caps is freed in xhci_mem_cleanup,but it isn't set to NULL. It will be freed twice when xhci_mem_cleanup is called the second time. We got following bug when system resumes from s4: kernel BUG at mm/slub.c:309! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP CPU: 0 PID: 5929 Tainted: G S W 5.4.96-arm64-desktop #1 pc : __slab_free+0x5c/0x424 lr : kfree+0x30c/0x32c Call trace: __slab_free+0x5c/0x424 kfree+0x30c/0x32c xhci_mem_cleanup+0x394/0x3cc xhci_mem_init+0x9ac/0x1070 xhci_init+0x8c/0x1d0 xhci_resume+0x1cc/0x5fc xhci_plat_resume+0x64/0x70 platform_pm_thaw+0x28/0x60 dpm_run_callback+0x54/0x24c device_resume+0xd0/0x200 async_resume+0x24/0x60 async_run_entry_fn+0x44/0x110 process_one_work+0x1f0/0x490 worker_thread+0x5c/0x450 kthread+0x158/0x160 ret_from_fork+0x10/0x24 Original patch that caused this issue was backported to 4.4 stable, so this should be backported to 4.4 stabe as well. Fixes: cf0ee7c60c89 ("xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Jiantao Zhang <water.zhangjiantao@huawei.com> Signed-off-by: Tao Xue <xuetao09@huawei.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210617150354.1512157-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b31d9d6d7abbf6483b871b6370bc31c930d53f54 upstream.

when system is doing s4, the process of xhci_resume may be as below:
1、xhci_mem_cleanup
2、xhci_init->xhci_mem_init->xhci_mem_cleanup(when memory is not enough).
xhci_mem_cleanup will be executed twice when system is out of memory.
xhci->port_caps is freed in xhci_mem_cleanup,but it isn't set to NULL.
It will be freed twice when xhci_mem_cleanup is called the second time.

We got following bug when system resumes from s4:

kernel BUG at mm/slub.c:309!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
CPU: 0 PID: 5929 Tainted: G S   W   5.4.96-arm64-desktop #1
pc : __slab_free+0x5c/0x424
lr : kfree+0x30c/0x32c

Call trace:
 __slab_free+0x5c/0x424
 kfree+0x30c/0x32c
 xhci_mem_cleanup+0x394/0x3cc
 xhci_mem_init+0x9ac/0x1070
 xhci_init+0x8c/0x1d0
 xhci_resume+0x1cc/0x5fc
 xhci_plat_resume+0x64/0x70
 platform_pm_thaw+0x28/0x60
 dpm_run_callback+0x54/0x24c
 device_resume+0xd0/0x200
 async_resume+0x24/0x60
 async_run_entry_fn+0x44/0x110
 process_one_work+0x1f0/0x490
 worker_thread+0x5c/0x450
 kthread+0x158/0x160
 ret_from_fork+0x10/0x24

Original patch that caused this issue was backported to 4.4 stable,
so this should be backported to 4.4 stabe as well.

Fixes: cf0ee7c60c89 ("xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Jiantao Zhang <water.zhangjiantao@huawei.com>
Signed-off-by: Tao Xue <xuetao09@huawei.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210617150354.1512157-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: Add the missed altmode_id_remove() in typec_register_altmode() 2021-07-14T14:53:01+00:00 Jing Xiangfeng jingxiangfeng@huawei.com 2021-06-17T07:32:26+00:00 cc7559e6dd1df229fbbd8e82210829359a0f420e commit 03026197bb657d784220b040c6173267a0375741 upstream. typec_register_altmode() misses to call altmode_id_remove() in an error path. Add the missed function call to fix it. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable <stable@vger.kernel.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Link: https://lore.kernel.org/r/20210617073226.47599-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 03026197bb657d784220b040c6173267a0375741 upstream.

typec_register_altmode() misses to call altmode_id_remove() in an error
path. Add the missed function call to fix it.

Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
Cc: stable <stable@vger.kernel.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Link: https://lore.kernel.org/r/20210617073226.47599-1-jingxiangfeng@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: Fix debugfs creation flow 2021-07-14T14:53:01+00:00 Minas Harutyunyan Minas.Harutyunyan@synopsys.com 2021-06-17T16:55:24+00:00 d5b06a79fe89c671320b3ee89c4637846337fe1a commit 84524d1232ecca7cf8678e851b254f05cff4040a upstream. Creation EP's debugfs called earlier than debugfs folder for dwc3 device created. As result EP's debugfs are created in '/sys/kernel/debug' instead of '/sys/kernel/debug/usb/dwc3.1.auto'. Moved dwc3_debugfs_init() function call before calling dwc3_core_init_mode() to allow create dwc3 debugfs parent before creating EP's debugfs's. Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: stable <stable@vger.kernel.org> Reviewed-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/01fafb5b2d8335e98e6eadbac61fc796bdf3ec1a.1623948457.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 84524d1232ecca7cf8678e851b254f05cff4040a upstream.

Creation EP's debugfs called earlier than debugfs folder for dwc3
device created. As result EP's debugfs are created in '/sys/kernel/debug'
instead of '/sys/kernel/debug/usb/dwc3.1.auto'.

Moved dwc3_debugfs_init() function call before calling
dwc3_core_init_mode() to allow create dwc3 debugfs parent before
creating EP's debugfs's.

Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Link: https://lore.kernel.org/r/01fafb5b2d8335e98e6eadbac61fc796bdf3ec1a.1623948457.git.Minas.Harutyunyan@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: cdc-acm: blacklist Heimann USB Appset device 2021-07-14T14:53:00+00:00 Hannu Hartikainen hannu@hrtk.in 2021-06-22T14:14:54+00:00 7941f646a6cdae14514b53a892312738189204be commit 4897807753e078655a78de39ed76044d784f3e63 upstream. The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be a CDC-ACM device in its descriptors but in fact is not. If it is run with echo disabled it returns garbled data, probably due to something that happens in the TTY layer. And when run with echo enabled (the default), it will mess up the calibration data of the sensor the first time any data is sent to the device. In short, I had a bad time after connecting the sensor and trying to get it to work. I hope blacklisting it in the cdc-acm driver will save someone else a bit of trouble. Signed-off-by: Hannu Hartikainen <hannu@hrtk.in> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4897807753e078655a78de39ed76044d784f3e63 upstream.

The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be
a CDC-ACM device in its descriptors but in fact is not. If it is run
with echo disabled it returns garbled data, probably due to something
that happens in the TTY layer. And when run with echo enabled (the
default), it will mess up the calibration data of the sensor the first
time any data is sent to the device.

In short, I had a bad time after connecting the sensor and trying to get
it to work. I hope blacklisting it in the cdc-acm driver will save
someone else a bit of trouble.

Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: gadget: eem: fix echo command packet response issue 2021-07-14T14:53:00+00:00 Linyu Yuan linyyuan@codeaurora.com 2021-06-16T11:51:42+00:00 8bdef7f21cb6e53c0ce3e1cbcb05975aa0dd0fe9 commit 4249d6fbc10fd997abdf8a1ea49c0389a0edf706 upstream. when receive eem echo command, it will send a response, but queue this response to the usb request which allocate from gadget device endpoint zero, and transmit the request to IN endpoint of eem interface. on dwc3 gadget, it will trigger following warning in function __dwc3_gadget_ep_queue(), if (WARN(req->dep != dep, "request %pK belongs to '%s'\n", &req->request, req->dep->name)) return -EINVAL; fix it by allocating a usb request from IN endpoint of eem interface, and transmit the usb request to same IN endpoint of eem interface. Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210616115142.34075-1-linyyuan@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4249d6fbc10fd997abdf8a1ea49c0389a0edf706 upstream.

when receive eem echo command, it will send a response,
but queue this response to the usb request which allocate
from gadget device endpoint zero,
and transmit the request to IN endpoint of eem interface.

on dwc3 gadget, it will trigger following warning in function
__dwc3_gadget_ep_queue(),

	if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
				&req->request, req->dep->name))
		return -EINVAL;

fix it by allocating a usb request from IN endpoint of eem interface,
and transmit the usb request to same IN endpoint of eem interface.

Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210616115142.34075-1-linyyuan@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: core: fix kernel panic when do reboot 2021-06-23T12:41:31+00:00 Peter Chen peter.chen@kernel.org 2021-06-08T10:56:56+00:00 fd7c4bd582494934be15d41aebe0dbe23790605f commit 4bf584a03eec674975ee9fe36c8583d9d470dab1 upstream. When do system reboot, it calls dwc3_shutdown and the whole debugfs for dwc3 has removed first, when the gadget tries to do deinit, and remove debugfs for its endpoints, it meets NULL pointer dereference issue when call debugfs_lookup. Fix it by removing the whole dwc3 debugfs later than dwc3_drd_exit. [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 .... [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 2925.037005] pc : inode_permission+0x2c/0x198 [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8 [ 2925.045903] sp : ffff80001276ba70 [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000 [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100 [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420 [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080 [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065 [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188 [ 2925.120671] Call trace: [ 2925.123119] inode_permission+0x2c/0x198 [ 2925.127042] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit+0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] device_shutdown+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c/0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc+0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660) [ 2925.215372] ---[ end trace 124254d8e485a58b ]--- [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2925.227676] Kernel Offset: disabled [ 2925.231164] CPU features: 0x00001001,20000846 [ 2925.235521] Memory Limit: none [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: Jack Pham <jackp@codeaurora.org> Tested-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org (cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068) Link: https://lore.kernel.org/r/20210615080847.GA10432@jackp-linux.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4bf584a03eec674975ee9fe36c8583d9d470dab1 upstream.

When do system reboot, it calls dwc3_shutdown and the whole debugfs
for dwc3 has removed first, when the gadget tries to do deinit, and
remove debugfs for its endpoints, it meets NULL pointer dereference
issue when call debugfs_lookup. Fix it by removing the whole dwc3
debugfs later than dwc3_drd_exit.

[ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002
....
[ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[ 2925.037005] pc : inode_permission+0x2c/0x198
[ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8
[ 2925.045903] sp : ffff80001276ba70
[ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000
[ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100
[ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001
[ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000
[ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004
[ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030
[ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420
[ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080
[ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065
[ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188
[ 2925.120671] Call trace:
[ 2925.123119]  inode_permission+0x2c/0x198
[ 2925.127042]  lookup_one_len_common+0xb0/0xf8
[ 2925.131315]  lookup_one_len_unlocked+0x34/0xb0
[ 2925.135764]  lookup_positive_unlocked+0x14/0x50
[ 2925.140296]  debugfs_lookup+0x68/0xa0
[ 2925.143964]  dwc3_gadget_free_endpoints+0x84/0xb0
[ 2925.148675]  dwc3_gadget_exit+0x28/0x78
[ 2925.152518]  dwc3_drd_exit+0x100/0x1f8
[ 2925.156267]  dwc3_remove+0x11c/0x120
[ 2925.159851]  dwc3_shutdown+0x14/0x20
[ 2925.163432]  platform_shutdown+0x28/0x38
[ 2925.167360]  device_shutdown+0x15c/0x378
[ 2925.171291]  kernel_restart_prepare+0x3c/0x48
[ 2925.175650]  kernel_restart+0x1c/0x68
[ 2925.179316]  __do_sys_reboot+0x218/0x240
[ 2925.183247]  __arm64_sys_reboot+0x28/0x30
[ 2925.187262]  invoke_syscall+0x48/0x100
[ 2925.191017]  el0_svc_common.constprop.0+0x48/0xc8
[ 2925.195726]  do_el0_svc+0x28/0x88
[ 2925.199045]  el0_svc+0x20/0x30
[ 2925.202104]  el0_sync_handler+0xa8/0xb0
[ 2925.205942]  el0_sync+0x148/0x180
[ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660)
[ 2925.215372] ---[ end trace 124254d8e485a58b ]---
[ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2925.227676] Kernel Offset: disabled
[ 2925.231164] CPU features: 0x00001001,20000846
[ 2925.235521] Memory Limit: none
[ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically")
Cc: Jack Pham <jackp@codeaurora.org>
Tested-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Peter Chen <peter.chen@kernel.org>
Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org
(cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068)
Link: https://lore.kernel.org/r/20210615080847.GA10432@jackp-linux.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: debugfs: Add and remove endpoint dirs dynamically 2021-06-23T12:41:31+00:00 Jack Pham jackp@codeaurora.org 2021-05-29T19:29:32+00:00 d7e403eea007f47776186d4d572f234b1221e6e3 commit 8d396bb0a5b62b326f6be7594d8bd46b088296bd upstream. The DWC3 DebugFS directory and files are currently created once during probe. This includes creation of subdirectories for each of the gadget's endpoints. This works fine for peripheral-only controllers, as dwc3_core_init_mode() calls dwc3_gadget_init() just prior to calling dwc3_debugfs_init(). However, for dual-role controllers, dwc3_core_init_mode() will instead call dwc3_drd_init() which is problematic in a few ways. First, the initial state must be determined, then dwc3_set_mode() will have to schedule drd_work and by then dwc3_debugfs_init() could have already been invoked. Even if the initial mode is peripheral, dwc3_gadget_init() happens after the DebugFS files are created, and worse so if the initial state is host and the controller switches to peripheral much later. And secondly, even if the gadget endpoints' debug entries were successfully created, if the controller exits peripheral mode, its dwc3_eps are freed so the debug files would now hold stale references. So it is best if the DebugFS endpoint entries are created and removed dynamically at the same time the underlying dwc3_eps are. Do this by calling dwc3_debugfs_create_endpoint_dir() as each endpoint is created, and conversely remove the DebugFS entry when the endpoint is freed. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@vger.kernel.org> Reviewed-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8d396bb0a5b62b326f6be7594d8bd46b088296bd upstream.

The DWC3 DebugFS directory and files are currently created once
during probe.  This includes creation of subdirectories for each
of the gadget's endpoints.  This works fine for peripheral-only
controllers, as dwc3_core_init_mode() calls dwc3_gadget_init()
just prior to calling dwc3_debugfs_init().

However, for dual-role controllers, dwc3_core_init_mode() will
instead call dwc3_drd_init() which is problematic in a few ways.
First, the initial state must be determined, then dwc3_set_mode()
will have to schedule drd_work and by then dwc3_debugfs_init()
could have already been invoked.  Even if the initial mode is
peripheral, dwc3_gadget_init() happens after the DebugFS files
are created, and worse so if the initial state is host and the
controller switches to peripheral much later.  And secondly,
even if the gadget endpoints' debug entries were successfully
created, if the controller exits peripheral mode, its dwc3_eps
are freed so the debug files would now hold stale references.

So it is best if the DebugFS endpoint entries are created and
removed dynamically at the same time the underlying dwc3_eps are.
Do this by calling dwc3_debugfs_create_endpoint_dir() as each
endpoint is created, and conversely remove the DebugFS entry when
the endpoint is freed.

Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: core: hub: Disable autosuspend for Cypress CY7C65632 2021-06-23T12:41:28+00:00 Andrew Lunn andrew@lunn.ch 2021-06-14T15:55:23+00:00 0061eff7482493e899399a2abf230c145840a8ac commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream. The Cypress CY7C65632 appears to have an issue with auto suspend and detecting devices, not too dissimilar to the SMSC 5534B hub. It is easiest to reproduce by connecting multiple mass storage devices to the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts result in the devices not being detected. It is however possible to make them appear using lsusb -v. Disabling autosuspend for this hub resolves the issue. Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream.

The Cypress CY7C65632 appears to have an issue with auto suspend and
detecting devices, not too dissimilar to the SMSC 5534B hub. It is
easiest to reproduce by connecting multiple mass storage devices to
the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts
result in the devices not being detected. It is however possible to
make them appear using lsusb -v.

Disabling autosuspend for this hub resolves the issue.

Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>