commit aa8ea1016ef1b1e5f1c2f4dc55149b48dd524178 Author: Ben Hutchings Date: Mon Sep 23 21:12:19 2019 +0100 Linux 3.16.74 commit ffdd4aac4f2d7959b3df70ac327b2c73dd592a26 Author: Ian Abbott Date: Fri Jul 12 15:02:37 2019 +0100 staging: comedi: dt282x: fix a null pointer deref on interrupt commit b8336be66dec06bef518030a0df9847122053ec5 upstream. The interrupt handler `dt282x_interrupt()` causes a null pointer dereference for those supported boards that have no analog output support. For these boards, `dev->write_subdev` will be `NULL` and therefore the `s_ao` subdevice pointer variable will be `NULL`. In that case, the following call near the end of the interrupt handler results in a null pointer dereference: cfc_handle_events(dev, s_ao); [ Upstream equivalent: comedi_handle_events(dev, s_ao); -- IA ] Fix it by only calling the above function if `s_ao` is valid. (There are other uses of `s_ao` by the interrupt handler that may or may not be reached depending on values of hardware registers. Trust that they are reliable for now.) Fixes: f21c74fa4cfe ("staging: comedi: dt282x: use cfc_handle_events()") Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 2be081b4ec9c3630a678b7abf8216e78dbba459d Author: Ben Hutchings Date: Thu Sep 19 19:16:06 2019 +0100 media: poseidon: Depend on PM_RUNTIME This is a stable-only patch as the driver has been removed upstream. Commit c2b71462d294 "USB: core: Fix bug caused by duplicate interface PM usage counter" switched USB to using only the standard runtime PM mechanism. In my backport I changed poseidon to read the runtime PM counter, but that means it now needs to depend on PM_RUNTIME. Reported-by: Thomas Bork Signed-off-by: Ben Hutchings commit 0bd118896b6a82a42845a6148d2f0f4a3694d178 Author: Matt Delco Date: Mon Sep 16 14:16:54 2019 -0700 KVM: coalesced_mmio: add bounds checking commit b60fe990c6b07ef6d4df67bc0530c7c90a62623a upstream. The first/last indexes are typically shared with a user app. The app can change the 'last' index that the kernel uses to store the next result. This change sanity checks the index before using it for writing to a potentially arbitrary address. This fixes CVE-2019-14821. Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)") Signed-off-by: Matt Delco Signed-off-by: Jim Mattson Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com [Use READ_ONCE. - Paolo] Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: - Use ACCESS_ONCE() instead of READ_ONCE() - kvm_coalesced_mmio_zone::pio field is not supported] Signed-off-by: Ben Hutchings commit 65e2043814c7d6096521199ae8e18d5b40254a3e Author: Dan Carpenter Date: Thu Apr 4 11:56:51 2019 +0300 ath6kl: add some bounds checking commit 5d6751eaff672ea77642e74e92e6c0ac7f9709ab upstream. The "ev->traffic_class" and "reply->ac" variables come from the network and they're used as an offset into the wmi->stream_exist_for_ac[] array. Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[] array only has WMM_NUM_AC (4) elements. We need to add a couple bounds checks to prevent array overflows. I also modified one existing check from "if (traffic_class > 3) {" to "if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent. Fixes: bdcd81707973 (" Add ath6kl cleaned up driver") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit a79897227b81d588130813e83084b836733cb146 Author: Kefeng Wang Date: Sat Feb 23 12:33:27 2019 +0800 Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto() commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream. task A: task B: hci_uart_set_proto flush_to_ldisc - p->open(hu) -> h5_open //alloc h5 - receive_buf - set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf - hci_uart_register_dev - tty_ldisc_receive_buf - hci_uart_tty_receive - test_bit HCI_UART_PROTO_READY - h5_recv - clear_bit HCI_UART_PROTO_READY while() { - p->open(hu) -> h5_close //free h5 - h5_rx_3wire_hdr - h5_reset() //use-after-free } It could use ioctl to set hci uart proto, but there is a use-after-free issue when hci_uart_register_dev() fail in hci_uart_set_proto(), see stack above, fix this by setting HCI_UART_PROTO_READY bit only when hci_uart_register_dev() return success. Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com Signed-off-by: Kefeng Wang Reviewed-by: Jeremy Cline Signed-off-by: Marcel Holtmann [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 16adebe264399fc1e8a78296426442b050ea0f54 Author: Loic Poulain Date: Mon Apr 4 10:48:13 2016 +0200 Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data commit 84cb3df02aea4b00405521e67c4c67c2d525c364 upstream. HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we receive data from tty layer during this procedure, proto pointer may not be assigned yet, leading to null pointer dereference in rx method hci_uart_tty_receive. This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in order to avoid any proto operation before proto opening and assignment. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit 03e6d05e78d421221bca0f7480c59e1c202c54e9 Author: Jason Yan Date: Tue May 14 10:42:39 2019 +0800 scsi: libsas: delete sas port if expander discover failed commit 3b0541791453fbe7f42867e310e0c9eb6295364d upstream. The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be deleted when the expander failed to discover. This will cause resource leak and a further issue of kernel BUG like below: [159785.843156] port-2:17:29: trying to add phy phy-2:17:29 fails: it's already part of another port [159785.852144] ------------[ cut here ]------------ [159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086! [159785.863000] Internal error: Oops - BUG: 0 [#1] SMP [159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G W OE 4.19.25-vhulk1901.1.0.h111.aarch64 #1 [159785.878458] Hardware name: Huawei Technologies Co., Ltd. Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019 [159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain [159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO) [159785.900094] pc : sas_port_add_phy+0x188/0x1b8 [159785.904524] lr : sas_port_add_phy+0x188/0x1b8 [159785.908952] sp : ffff0001120e3b80 [159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000 [159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560 [159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000 [159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708 [159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400 [159785.939264] x19: ffff802adea2d800 x18: 0000000000000010 [159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0 [159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165 [159785.955417] x13: 726c612073277469 x12: ffff00006887b830 [159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020 [159785.966186] x9 : 0000000000002453 x8 : 726f702072656874 [159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290 [159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000 [159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00 [159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000 [159785.993108] Process kworker/u96:2 (pid: 16993, stack limit = 0x0000000072dae094) [159786.000576] Call trace: [159786.003097] sas_port_add_phy+0x188/0x1b8 [159786.007179] sas_ex_get_linkrate.isra.5+0x134/0x140 [159786.012130] sas_ex_discover_expander+0x128/0x408 [159786.016906] sas_ex_discover_dev+0x218/0x4c8 [159786.021249] sas_ex_discover_devices+0x9c/0x1a8 [159786.025852] sas_discover_root_expander+0x134/0x160 [159786.030802] sas_discover_domain+0x1b8/0x1e8 [159786.035148] process_one_work+0x1b4/0x3f8 [159786.039230] worker_thread+0x54/0x470 [159786.042967] kthread+0x134/0x138 [159786.046269] ret_from_fork+0x10/0x18 [159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000) [159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE) hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE) [159786.067202] ---[ end trace 03622b9e2d99e196 ]--- [159786.071893] Kernel panic - not syncing: Fatal exception [159786.077190] SMP: stopping secondary CPUs [159786.081192] Kernel Offset: disabled [159786.084753] CPU features: 0x2,a2a00a38 Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Reported-by: Jian Luo Signed-off-by: Jason Yan CC: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 8a8b481d1908d18213a55260498c5b0af6f12892 Author: Arnd Bergmann Date: Wed Mar 6 11:52:36 2019 +0100 appletalk: Fix compile regression commit 27da0d2ef998e222a876c0cec72aa7829a626266 upstream. A bugfix just broke compilation of appletalk when CONFIG_SYSCTL is disabled: In file included from net/appletalk/ddp.c:65: net/appletalk/ddp.c: In function 'atalk_init': include/linux/atalk.h:164:34: error: expected expression before 'do' #define atalk_register_sysctl() do { } while(0) ^~ net/appletalk/ddp.c:1934:7: note: in expansion of macro 'atalk_register_sysctl' rc = atalk_register_sysctl(); This is easier to avoid by using conventional inline functions as stubs rather than macros. The header already has inline functions for other purposes, so I'm changing over all the macros for consistency. Fixes: 6377f787aeb9 ("appletalk: Fix use-after-free in atalk_proc_exit") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2714dac820ef997b8d225eba6788b69cf8398464 Author: YueHaibing Date: Fri Mar 1 10:57:57 2019 +0800 appletalk: Fix use-after-free in atalk_proc_exit commit 6377f787aeb945cae7abbb6474798de129e1f3ac upstream. KASAN report this: BUG: KASAN: use-after-free in pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71 Read of size 8 at addr ffff8881f41fe5b0 by task syz-executor.0/2806 CPU: 0 PID: 2806 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 print_address_description+0x65/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71 remove_proc_entry+0xe8/0x420 fs/proc/generic.c:667 atalk_proc_exit+0x18/0x820 [appletalk] atalk_exit+0xf/0x5a [appletalk] __do_sys_delete_module kernel/module.c:1018 [inline] __se_sys_delete_module kernel/module.c:961 [inline] __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb2de6b9c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200001c0 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb2de6ba6bc R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff Allocated by task 2806: set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496 slab_post_alloc_hook mm/slab.h:444 [inline] slab_alloc_node mm/slub.c:2739 [inline] slab_alloc mm/slub.c:2747 [inline] kmem_cache_alloc+0xcf/0x250 mm/slub.c:2752 kmem_cache_zalloc include/linux/slab.h:730 [inline] __proc_create+0x30f/0xa20 fs/proc/generic.c:408 proc_mkdir_data+0x47/0x190 fs/proc/generic.c:469 0xffffffffc10c01bb 0xffffffffc10c0166 do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2806: set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook mm/slub.c:1436 [inline] slab_free mm/slub.c:2986 [inline] kmem_cache_free+0xa6/0x2a0 mm/slub.c:3002 pde_put+0x6e/0x80 fs/proc/generic.c:647 remove_proc_entry+0x1d3/0x420 fs/proc/generic.c:684 0xffffffffc10c031c 0xffffffffc10c0166 do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8881f41fe500 which belongs to the cache proc_dir_entry of size 256 The buggy address is located 176 bytes inside of 256-byte region [ffff8881f41fe500, ffff8881f41fe600) The buggy address belongs to the page: page:ffffea0007d07f80 count:1 mapcount:0 mapping:ffff8881f6e69a00 index:0x0 flags: 0x2fffc0000000200(slab) raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6e69a00 raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881f41fe480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8881f41fe500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881f41fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881f41fe600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8881f41fe680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb It should check the return value of atalk_proc_init fails, otherwise atalk_exit will trgger use-after-free in pde_subdir_find while unload the module.This patch fix error cleanup path of atalk_init Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit f1508f326a3b8f29beef9ca399bec516ecfd0b2a Author: Takashi Iwai Date: Tue Jul 2 20:07:21 2019 +0200 ALSA: line6: Fix write on zero-sized buffer commit 3450121997ce872eb7f1248417225827ea249710 upstream. LINE6 drivers allocate the buffers based on the value returned from usb_maxpacket() calls. The manipulated device may return zero for this, and this results in the kmalloc() with zero size (and it may succeed) while the other part of the driver code writes the packet data with the fixed size -- which eventually overwrites. This patch adds a simple sanity check for the invalid buffer size for avoiding that problem. Reported-by: syzbot+219f00fb49874dcaea17@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: - Driver doesn't support asymmetrical packet sizes, so only check snd_line6_pcm::max_packet_size - Adjust filename] Signed-off-by: Ben Hutchings commit 450e350ba7c383dc74b181e4eeb50526df68433e Author: Alan Stern Date: Mon May 20 10:44:21 2019 -0400 p54usb: Fix race between disconnect and firmware loading commit 6e41e2257f1094acc37618bf6c856115374c6922 upstream. The syzbot fuzzer found a bug in the p54 USB wireless driver. The issue involves a race between disconnect and the firmware-loader callback routine, and it has several aspects. One big problem is that when the firmware can't be loaded, the callback routine tries to unbind the driver from the USB _device_ (by calling device_release_driver) instead of from the USB _interface_ to which it is actually bound (by calling usb_driver_release_interface). The race involves access to the private data structure. The driver's disconnect handler waits for a completion that is signalled by the firmware-loader callback routine. As soon as the completion is signalled, you have to assume that the private data structure may have been deallocated by the disconnect handler -- even if the firmware was loaded without errors. However, the callback routine does access the private data several times after that point. Another problem is that, in order to ensure that the USB device structure hasn't been freed when the callback routine runs, the driver takes a reference to it. This isn't good enough any more, because now that the callback routine calls usb_driver_release_interface, it has to ensure that the interface structure hasn't been freed. Finally, the driver takes an unnecessary reference to the USB device structure in the probe function and drops the reference in the disconnect handler. This extra reference doesn't accomplish anything, because the USB core already guarantees that a device structure won't be deallocated while a driver is still bound to any of its interfaces. To fix these problems, this patch makes the following changes: Call usb_driver_release_interface() rather than device_release_driver(). Don't signal the completion until after the important information has been copied out of the private data structure, and don't refer to the private data at all thereafter. Lock udev (the interface's parent) before unbinding the driver instead of locking udev->parent. During the firmware loading process, take a reference to the USB interface instead of the USB device. Don't take an unnecessary reference to the device during probe (and then don't drop it during disconnect). Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 135b5e3371cdba62761dee1cf6c0e20e48a41ac3 Author: Oliver Neukum Date: Thu May 9 14:41:50 2019 +0200 USB: sisusbvga: fix oops in error path of sisusb_probe commit 9a5729f68d3a82786aea110b1bfe610be318f80a upstream. The pointer used to log a failure of usb_register_dev() must be set before the error is logged. v2: fix that minor is not available before registration Signed-off-by: oliver Neukum Reported-by: syzbot+a0cbdbd6d169020c8959@syzkaller.appspotmail.com Fixes: 7b5cd5fefbe02 ("USB: SisUSB2VGA: Convert printk to dev_* macros") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b38d52375b92e1a1ddca9a79cf08bf8d536e8cbb Author: Mauro Carvalho Chehab Date: Fri May 24 10:59:43 2019 -0400 media: smsusb: better handle optional alignment commit a47686636d84eaec5c9c6e84bd5f96bed34d526d upstream. Most Siano devices require an alignment for the response. Changeset f3be52b0056a ("media: usb: siano: Fix general protection fault in smsusb") changed the logic with gets such aligment, but it now produces a sparce warning: drivers/media/usb/siano/smsusb.c: In function 'smsusb_init_device': drivers/media/usb/siano/smsusb.c:447:37: warning: 'in_maxp' may be used uninitialized in this function [-Wmaybe-uninitialized] 447 | dev->response_alignment = in_maxp - sizeof(struct sms_msg_hdr); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ The sparse message itself is bogus, but a broken (or fake) USB eeprom could produce a negative value for response_alignment. So, change the code in order to check if the result is not negative. Fixes: 31e0456de5be ("media: usb: siano: Fix general protection fault in smsusb") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4a2387d33dcd9f456a690673b473747df3851520 Author: Alan Stern Date: Tue May 21 11:38:07 2019 -0400 media: usb: siano: Fix false-positive "uninitialized variable" warning commit 45457c01171fd1488a7000d1751c06ed8560ee38 upstream. GCC complains about an apparently uninitialized variable recently added to smsusb_init_device(). It's a false positive, but to silence the warning this patch adds a trivial initialization. Signed-off-by: Alan Stern Reported-by: kbuild test robot Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit a472ce0bb6f46a523ea9f8ba62f16538a480f1a5 Author: Alan Stern Date: Tue May 7 12:39:47 2019 -0400 media: usb: siano: Fix general protection fault in smsusb commit 31e0456de5be379b10fea0fa94a681057114a96e upstream. The syzkaller USB fuzzer found a general-protection-fault bug in the smsusb part of the Siano DVB driver. The fault occurs during probe because the driver assumes without checking that the device has both IN and OUT endpoints and the IN endpoint is ep1. By slightly rearranging the driver's initialization code, we can make the appropriate checks early on and thus avoid the problem. If the expected endpoints aren't present, the new code safely returns -ENODEV from the probe routine. Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+53f029db71c19a47325a@syzkaller.appspotmail.com Reviewed-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 136f9120ecef4d43b5d87000542f16e87c93e2b1 Author: Oliver Neukum Date: Thu May 9 04:57:09 2019 -0400 media: cpia2_usb: first wake up, then free in disconnect commit eff73de2b1600ad8230692f00bc0ab49b166512a upstream. Kasan reported a use after free in cpia2_usb_disconnect() It first freed everything and then woke up those waiting. The reverse order is correct. Fixes: 6c493f8b28c67 ("[media] cpia2: major overhaul to get it in a working state again") Signed-off-by: Oliver Neukum Reported-by: syzbot+0c90fc937c84f97d0aa6@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 365d2bc245d2b1b2628f80463bdf284544d69c36 Author: Oliver Neukum Date: Thu May 9 11:30:58 2019 +0200 USB: rio500: refuse more than one device at a time commit 3864d33943b4a76c6e64616280e98d2410b1190f upstream. This driver is using a global variable. It cannot handle more than one device at a time. The issue has been existing since the dawn of the driver. Signed-off-by: Oliver Neukum Reported-by: syzbot+35f04d136fc975a70da4@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit cc1b36d4dd926df07d970cb78346a3bda082fe65 Author: Luke Nowakowski-Krijger Date: Fri Jun 21 21:04:38 2019 -0400 media: radio-raremono: change devm_k*alloc to k*alloc commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream. Change devm_k*alloc to k*alloc to manually allocate memory The manual allocation and freeing of memory is necessary because when the USB radio is disconnected, the memory associated with devm_k*alloc is freed. Meaning if we still have unresolved references to the radio device, then we get use-after-free errors. This patch fixes this by manually allocating memory, and freeing it in the v4l2.release callback that gets called when the last radio device exits. Reported-and-tested-by: syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com Signed-off-by: Luke Nowakowski-Krijger Signed-off-by: Hans Verkuil [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings] [hverkuil-cisco@xs4all.nl: prefix subject with driver name] Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit d6e2b6dd35b6f83fd0166745d8ca65f191a3a468 Author: Hui Peng Date: Thu Aug 15 00:31:34 2019 -0400 ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream. `check_input_term` recursively calls itself with input from device side (e.g., uac_input_terminal_descriptor.bCSourceID) as argument (id). In `check_input_term`, if `check_input_term` is called with the same `id` argument as the caller, it triggers endless recursive call, resulting kernel space stack overflow. This patch fixes the bug by adding a bitmap to `struct mixer_build` to keep track of the checked ids and stop the execution if some id has been checked (similar to how parse_audio_unit handles unitid argument). Reported-by: Hui Peng Reported-by: Mathias Payer Signed-off-by: Hui Peng Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit b5807684982f4dd978a2a5496514ecc3132bce91 Author: Hui Peng Date: Tue Aug 13 22:34:04 2019 -0400 ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream. The `uac_mixer_unit_descriptor` shown as below is read from the device side. In `parse_audio_mixer_unit`, `baSourceID` field is accessed from index 0 to `bNrInPins` - 1, the current implementation assumes that descriptor is always valid (the length of descriptor is no shorter than 5 + `bNrInPins`). If a descriptor read from the device side is invalid, it may trigger out-of-bound memory access. ``` struct uac_mixer_unit_descriptor { __u8 bLength; __u8 bDescriptorType; __u8 bDescriptorSubtype; __u8 bUnitID; __u8 bNrInPins; __u8 baSourceID[]; } ``` This patch fixes the bug by add a sanity check on the length of the descriptor. Reported-by: Hui Peng Reported-by: Mathias Payer Signed-off-by: Hui Peng Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8041c3ee83638f34d4c6b52f432601ad12ea4850 Author: yongduan Date: Wed Sep 11 17:44:24 2019 +0800 vhost: make sure log_num < in_num commit 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 upstream. The code assumes log_num < in_num everywhere, and that is true as long as in_num is incremented by descriptor iov count, and log_num by 1. However this breaks if there's a zero sized descriptor. As a result, if a malicious guest creates a vring desc with desc.len = 0, it may cause the host kernel to crash by overflowing the log array. This bug can be triggered during the VM migration. There's no need to log when desc.len = 0, so just don't increment log_num in this case. Fixes: 3a4d5c94e959 ("vhost_net: a kernel-level virtio server") Reviewed-by: Lidong Chen Signed-off-by: ruippan Signed-off-by: yongduan Acked-by: Michael S. Tsirkin Reviewed-by: Tyler Hicks Signed-off-by: Michael S. Tsirkin [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fb8186b15518423646f0e2105c34b3e620623b4e Author: Wen Huang Date: Wed Aug 28 10:07:51 2019 +0800 mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings commit 7caac62ed598a196d6ddf8d9c121e12e082cac3a upstream. mwifiex_update_vs_ie(),mwifiex_set_uap_rates() and mwifiex_set_wmm_params() call memcpy() without checking the destination size.Since the source is given from user-space, this may trigger a heap buffer overflow. Fix them by putting the length check before performing memcpy(). This fix addresses CVE-2019-14814,CVE-2019-14815,CVE-2019-14816. Signed-off-by: Wen Huang Acked-by: Ganapathi Bhat Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filenames] Signed-off-by: Ben Hutchings commit e58e542e6eab2734dda4e5006d9ec3226fddd4c1 Author: Karthik D A Date: Wed Sep 28 18:18:24 2016 +0530 mwifiex: vendor_ie length check for parse WMM IEs commit 113630b581d6d423998d2113a8e892ed6e6af6f9 upstream. While copying the vendor_ie obtained from the cfg80211_find_vendor_ie() to the struct mwifiex_types_wmm_info, length/size was inappropriate. This patch corrects the required length needed to the mwifiex_types_wmm_info Signed-off-by: Karthik D A Signed-off-by: Amitkumar Karwar Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 8c2981482a9a1b8910dd0b4365b53db1a056ae66 Author: Yu Wang Date: Fri May 10 17:04:52 2019 +0800 mac80211: handle deauthentication/disassociation from TDLS peer commit 79c92ca42b5a3e0ea172ea2ce8df8e125af237da upstream. When receiving a deauthentication/disassociation frame from a TDLS peer, a station should not disconnect the current AP, but only disable the current TDLS link if it's enabled. Without this change, a TDLS issue can be reproduced by following the steps as below: 1. STA-1 and STA-2 are connected to AP, bidirection traffic is running between STA-1 and STA-2. 2. Set up TDLS link between STA-1 and STA-2, stay for a while, then teardown TDLS link. 3. Repeat step #2 and monitor the connection between STA and AP. During the test, one STA may send a deauthentication/disassociation frame to another, after TDLS teardown, with reason code 6/7, which means: Class 2/3 frame received from nonassociated STA. On receive this frame, the receiver STA will disconnect the current AP and then reconnect. It's not a expected behavior, purpose of this frame should be disabling the TDLS link, not the link with AP. Signed-off-by: Yu Wang Signed-off-by: Johannes Berg [bwh: Backported to 3.16: - Initialise reason_code earlier in ieee80211_rx_mgmt_deauth() - Adjust context] Signed-off-by: Ben Hutchings commit 62909f7d0b1360ddb147bae8f546228dd93588e1 Author: Johannes Berg Date: Wed Feb 13 15:13:30 2019 +0100 mac80211: drop robust management frames from unknown TA commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream. When receiving a robust management frame, drop it if we don't have rx->sta since then we don't have a security association and thus couldn't possibly validate the frame. Signed-off-by: Johannes Berg [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 4ddb257573f61238bca2e3482e2f9cd94627f936 Author: Arik Nemtsov Date: Wed Jun 11 17:18:25 2014 +0300 mac80211: add API to request TDLS operation from userspace commit c887f0d3a03283cb6fe2c32aae62229bebd3fa32 upstream. Write a mac80211 to the cfg80211 API for requesting a userspace TDLS operation. Define TDLS specific reason codes that can be used here. Signed-off-by: Arik Nemtsov Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit fd56118648c89adbd7a64bc8e3e26ac4871d1c1a Author: Sanjay Konduri Date: Tue May 15 14:34:30 2018 +0530 rsi: add fix for crash during assertions commit abd39c6ded9db53aa44c2540092bdd5fb6590fa8 upstream. Observed crash in some scenarios when assertion has occurred, this is because hw structure is freed and is tried to get accessed in some functions where null check is already present. So, avoided the crash by making the hw to NULL after freeing. Signed-off-by: Sanjay Konduri Signed-off-by: Sushant Kumar Mishra Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit bf3878994377a97143f5f6b6e60a18f9b76e0476 Author: Dave Chinner Date: Thu May 10 21:50:23 2018 -0700 xfs: clear sb->s_fs_info on mount failure commit c9fbd7bbc23dbdd73364be4d045e5d3612cf6e82 upstream. We recently had an oops reported on a 4.14 kernel in xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage and so the m_perag_tree lookup walked into lala land. Essentially, the machine was under memory pressure when the mount was being run, xfs_fs_fill_super() failed after allocating the xfs_mount and attaching it to sb->s_fs_info. It then cleaned up and freed the xfs_mount, but the sb->s_fs_info field still pointed to the freed memory. Hence when the superblock shrinker then ran it fell off the bad pointer. With the superblock shrinker problem fixed at teh VFS level, this stale s_fs_info pointer is still a problem - we use it unconditionally in ->put_super when the superblock is being torn down, and hence we can still trip over it after a ->fill_super call failure. Hence we need to clear s_fs_info if xfs-fs_fill_super() fails, and we need to check if it's valid in the places it can potentially be dereferenced after a ->fill_super failure. Signed-Off-By: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fe2292f42aa20799497099a88771b4bbf6afdc4e Author: Alexander Kochetkov Date: Tue Feb 9 18:20:38 2016 +0300 net: arc_emac: fix koops caused by sk_buff free commit c278c253f3d992c6994d08aa0efb2b6806ca396f upstream. There is a race between arc_emac_tx() and arc_emac_tx_clean(). sk_buff got freed by arc_emac_tx_clean() while arc_emac_tx() submitting sk_buff. In order to free sk_buff arc_emac_tx_clean() checks: if ((info & FOR_EMAC) || !txbd->data) break; ... dev_kfree_skb_irq(skb); If condition false, arc_emac_tx_clean() free sk_buff. In order to submit txbd, arc_emac_tx() do: priv->tx_buff[*txbd_curr].skb = skb; ... priv->txbd[*txbd_curr].data = cpu_to_le32(addr); ... ... <== arc_emac_tx_clean() check condition here ... <== (info & FOR_EMAC) is false ... <== !txbd->data is false ... *info = cpu_to_le32(FOR_EMAC | FIRST_OR_LAST_MASK | len); In order to reproduce the situation, run device: # iperf -s run on host: # iperf -t 600 -c [ 28.396284] ------------[ cut here ]------------ [ 28.400912] kernel BUG at .../net/core/skbuff.c:1355! [ 28.414019] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 28.419150] Modules linked in: [ 28.422219] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B 4.4.0+ #120 [ 28.429516] Hardware name: Rockchip (Device Tree) [ 28.434216] task: c0665070 ti: c0660000 task.ti: c0660000 [ 28.439622] PC is at skb_put+0x10/0x54 [ 28.443381] LR is at arc_emac_poll+0x260/0x474 [ 28.447821] pc : [] lr : [] psr: a0070113 [ 28.447821] sp : c0661e58 ip : eea68502 fp : ef377000 [ 28.459280] r10: 0000012c r9 : f08b2000 r8 : eeb57100 [ 28.464498] r7 : 00000000 r6 : ef376594 r5 : 00000077 r4 : ef376000 [ 28.471015] r3 : 0030488b r2 : ef13e880 r1 : 000005ee r0 : eeb57100 [ 28.477534] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 28.484658] Control: 10c5387d Table: 8eaf004a DAC: 00000051 [ 28.490396] Process swapper/0 (pid: 0, stack limit = 0xc0660210) [ 28.496393] Stack: (0xc0661e58 to 0xc0662000) [ 28.500745] 1e40: 00000002 00000000 [ 28.508913] 1e60: 00000000 ef376520 00000028 f08b23b8 00000000 ef376520 ef7b6900 c028fc64 [ 28.517082] 1e80: 2f158000 c0661ea8 c0661eb0 0000012c c065e900 c03bdeac ffff95e9 c0662100 [ 28.525250] 1ea0: c0663924 00000028 c0661ea8 c0661ea8 c0661eb0 c0661eb0 0000001e c0660000 [ 28.533417] 1ec0: 40000003 00000008 c0695a00 0000000a c066208c 00000100 c0661ee0 c0027410 [ 28.541584] 1ee0: ef0fb700 2f158000 00200000 ffff95e8 00000004 c0662100 c0662080 00000003 [ 28.549751] 1f00: 00000000 00000000 00000000 c065b45c 0000001e ef005000 c0647a30 00000000 [ 28.557919] 1f20: 00000000 c0027798 00000000 c005cf40 f0802100 c0662ffc c0661f60 f0803100 [ 28.566088] 1f40: c0661fb8 c00093bc c000ffb4 60070013 ffffffff c0661f94 c0661fb8 c00137d4 [ 28.574267] 1f60: 00000001 00000000 00000000 c001ffa0 00000000 c0660000 00000000 c065a364 [ 28.582441] 1f80: c0661fb8 c0647a30 00000000 00000000 00000000 c0661fb0 c000ffb0 c000ffb4 [ 28.590608] 1fa0: 60070013 ffffffff 00000051 00000000 00000000 c005496c c0662400 c061bc40 [ 28.598776] 1fc0: ffffffff ffffffff 00000000 c061b680 00000000 c0647a30 00000000 c0695294 [ 28.606943] 1fe0: c0662488 c0647a2c c066619c 6000406a 413fc090 6000807c 00000000 00000000 [ 28.615127] [] (skb_put) from [] (0xef376520) [ 28.621218] Code: e5902054 e590c090 e3520000 0a000000 (e7f001f2) [ 28.627307] ---[ end trace 4824734e2243fdb6 ]--- [ 34.377068] Internal error: Oops: 17 [#1] SMP ARM [ 34.382854] Modules linked in: [ 34.385947] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.4.0+ #120 [ 34.392219] Hardware name: Rockchip (Device Tree) [ 34.396937] task: ef02d040 ti: ef05c000 task.ti: ef05c000 [ 34.402376] PC is at __dev_kfree_skb_irq+0x4/0x80 [ 34.407121] LR is at arc_emac_poll+0x130/0x474 [ 34.411583] pc : [] lr : [] psr: 60030013 [ 34.411583] sp : ef05de68 ip : 0008e83c fp : ef377000 [ 34.423062] r10: c001bec4 r9 : 00000000 r8 : f08b24c8 [ 34.428296] r7 : f08b2400 r6 : 00000075 r5 : 00000019 r4 : ef376000 [ 34.434827] r3 : 00060000 r2 : 00000042 r1 : 00000001 r0 : 00000000 [ 34.441365] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 34.448507] Control: 10c5387d Table: 8f25c04a DAC: 00000051 [ 34.454262] Process ksoftirqd/0 (pid: 3, stack limit = 0xef05c210) [ 34.460449] Stack: (0xef05de68 to 0xef05e000) [ 34.464827] de60: ef376000 c028fd94 00000000 c0669480 c0669480 ef376520 [ 34.473022] de80: 00000028 00000001 00002ae4 ef376520 ef7b6900 c028fc64 2f158000 ef05dec0 [ 34.481215] dea0: ef05dec8 0000012c c065e900 c03bdeac ffff983f c0662100 c0663924 00000028 [ 34.489409] dec0: ef05dec0 ef05dec0 ef05dec8 ef05dec8 ef7b6000 ef05c000 40000003 00000008 [ 34.497600] dee0: c0695a00 0000000a c066208c 00000100 ef05def8 c0027410 ef7b6000 40000000 [ 34.505795] df00: 04208040 ffff983e 00000004 c0662100 c0662080 00000003 ef05c000 ef027340 [ 34.513985] df20: ef05c000 c0666c2c 00000000 00000001 00000002 00000000 00000000 c0027568 [ 34.522176] df40: ef027340 c003ef48 ef027300 00000000 ef027340 c003edd4 00000000 00000000 [ 34.530367] df60: 00000000 c003c37c ffffff7f 00000001 00000000 ef027340 00000000 00030003 [ 34.538559] df80: ef05df80 ef05df80 00000000 00000000 ef05df90 ef05df90 ef05dfac ef027300 [ 34.546750] dfa0: c003c2a4 00000000 00000000 c000f578 00000000 00000000 00000000 00000000 [ 34.554939] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 34.563129] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff dfff7fff [ 34.571360] [] (__dev_kfree_skb_irq) from [] (arc_emac_poll+0x130/0x474) [ 34.579840] [] (arc_emac_poll) from [] (net_rx_action+0xdc/0x28c) [ 34.587712] [] (net_rx_action) from [] (__do_softirq+0xcc/0x1f8) [ 34.595482] [] (__do_softirq) from [] (run_ksoftirqd+0x2c/0x50) [ 34.603168] [] (run_ksoftirqd) from [] (smpboot_thread_fn+0x174/0x18c) [ 34.611466] [] (smpboot_thread_fn) from [] (kthread+0xd8/0xec) [ 34.619075] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 34.626317] Code: e8bd8010 e3a00000 e12fff1e e92d4010 (e59030a4) [ 34.632572] ---[ end trace cca5a3d86a82249a ]--- Signed-off-by: Alexander Kochetkov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit b0699c8e33f2fdf5396da2d41cf2f7ffe9a140a9 Author: Bob Peterson Date: Thu Jun 9 14:24:07 2016 -0500 GFS2: don't set rgrp gl_object until it's inserted into rgrp tree commit 36e4ad0316c017d5b271378ed9a1c9a4b77fab5f upstream. Before this patch, function read_rindex_entry would set a rgrp glock's gl_object pointer to itself before inserting the rgrp into the rgrp rbtree. The problem is: if another process was also reading the rgrp in, and had already inserted its newly created rgrp, then the second call to read_rindex_entry would overwrite that value, then return a bad return code to the caller. Later, other functions would reference the now-freed rgrp memory by way of gl_object. In some cases, that could result in gfs2_rgrp_brelse being called twice for the same rgrp: once for the failed attempt and once for the "real" rgrp release. Eventually the kernel would panic. There are also a number of other things that could go wrong when a kernel module is accessing freed storage. For example, this could result in rgrp corruption because the fake rgrp would point to a fake bitmap in memory too, causing gfs2_inplace_reserve to search some random memory for free blocks, and find some, since we were never setting rgd->rd_bits to NULL before freeing it. This patch fixes the problem by not setting gl_object until we have successfully inserted the rgrp into the rbtree. Also, it sets rd_bits to NULL as it frees them, which will ensure any accidental access to the wrong rgrp will result in a kernel panic rather than file system corruption, which is preferred. Signed-off-by: Bob Peterson [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit a7e905eaaf4a08b7ff65f43607f8a64a5175c643 Author: Bob Peterson Date: Wed Oct 28 09:05:31 2015 -0500 GFS2: Fix rgrp end rounding problem for bsize < page size commit 31dddd9eb9ebae9a2a9b502750e9e481d752180a upstream. This patch fixes a bug introduced by commit 7005c3e. That patch tries to map a vm range for resource groups, but the calculation breaks down when the block size is less than the page size. Signed-off-by: Bob Peterson Signed-off-by: Ben Hutchings commit dbdd553c5135c77ecb9757304b393bd7277433af Author: Andy Lutomirski Date: Tue May 14 13:24:40 2019 -0700 x86/speculation/mds: Improve CPU buffer clear documentation commit 9d8d0294e78a164d407133dea05caf4b84247d6a upstream. On x86_64, all returns to usermode go through prepare_exit_to_usermode(), with the sole exception of do_nmi(). This even includes machine checks -- this was added several years ago to support MCE recovery. Update the documentation. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Frederic Weisbecker Cc: Greg Kroah-Hartman Cc: Jon Masters Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 04dcbdb80578 ("x86/speculation/mds: Clear CPU buffers on exit to user") Link: http://lkml.kernel.org/r/999fa9e126ba6a48e9d214d2f18dbde5c62ac55c.1557865329.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 9dac3ede79734dd28714f0f514eb20a64d328b93 Author: Andy Lutomirski Date: Tue May 14 13:24:39 2019 -0700 x86/speculation/mds: Revert CPU buffer clear on double fault exit commit 88640e1dcd089879530a49a8d212d1814678dfe7 upstream. The double fault ESPFIX path doesn't return to user mode at all -- it returns back to the kernel by simulating a #GP fault. prepare_exit_to_usermode() will run on the way out of general_protection before running user code. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Frederic Weisbecker Cc: Greg Kroah-Hartman Cc: Jon Masters Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 04dcbdb80578 ("x86/speculation/mds: Clear CPU buffers on exit to user") Link: http://lkml.kernel.org/r/ac97612445c0a44ee10374f6ea79c222fe22a5c4.1557865329.git.luto@kernel.org Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 77b37833667ba383f95e1a585f07608cb5647fa9 Author: Dan Carpenter Date: Tue May 14 15:47:00 2019 -0700 drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl commit c8ea3663f7a8e6996d44500ee818c9330ac4fd88 upstream. strndup_user() returns error pointers on error, and then in the error handling we pass the error pointers to kfree(). It will cause an Oops. Link: http://lkml.kernel.org/r/20181218082003.GD32567@kadam Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver") Signed-off-by: Dan Carpenter Reviewed-by: Andrew Morton Cc: Timur Tabi Cc: Mihai Caraman Cc: Kumar Gala Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e18877b70896061ddffaef22545169bbd3512650 Author: Shuning Zhang Date: Mon May 13 17:15:56 2019 -0700 ocfs2: fix ocfs2 read inode data panic in ocfs2_iget commit e091eab028f9253eac5c04f9141bbc9d170acab3 upstream. In some cases, ocfs2_iget() reads the data of inode, which has been deleted for some reason. That will make the system panic. So We should judge whether this inode has been deleted, and tell the caller that the inode is a bad inode. For example, the ocfs2 is used as the backed of nfs, and the client is nfsv3. This issue can be reproduced by the following steps. on the nfs server side, ..../patha/pathb Step 1: The process A was scheduled before calling the function fh_verify. Step 2: The process B is removing the 'pathb', and just completed the call to function dput. Then the dentry of 'pathb' has been deleted from the dcache, and all ancestors have been deleted also. The relationship of dentry and inode was deleted through the function hlist_del_init. The following is the call stack. dentry_iput->hlist_del_init(&dentry->d_u.d_alias) At this time, the inode is still in the dcache. Step 3: The process A call the function ocfs2_get_dentry, which get the inode from dcache. Then the refcount of inode is 1. The following is the call stack. nfsd3_proc_getacl->fh_verify->exportfs_decode_fh->fh_to_dentry(ocfs2_get_dentry) Step 4: Dirty pages are flushed by bdi threads. So the inode of 'patha' is evicted, and this directory was deleted. But the inode of 'pathb' can't be evicted, because the refcount of the inode was 1. Step 5: The process A keep running, and call the function reconnect_path(in exportfs_decode_fh), which call function ocfs2_get_parent of ocfs2. Get the block number of parent directory(patha) by the name of ... Then read the data from disk by the block number. But this inode has been deleted, so the system panic. Process A Process B 1. in nfsd3_proc_getacl | 2. | dput 3. fh_to_dentry(ocfs2_get_dentry) | 4. bdi flush dirty cache | 5. ocfs2_iget | [283465.542049] OCFS2: ERROR (device sdp): ocfs2_validate_inode_block: Invalid dinode #580640: OCFS2_VALID_FL not set [283465.545490] Kernel panic - not syncing: OCFS2: (device sdp): panic forced after error [283465.546889] CPU: 5 PID: 12416 Comm: nfsd Tainted: G W 4.1.12-124.18.6.el6uek.bug28762940v3.x86_64 #2 [283465.548382] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015 [283465.549657] 0000000000000000 ffff8800a56fb7b8 ffffffff816e839c ffffffffa0514758 [283465.550392] 000000000008dc20 ffff8800a56fb838 ffffffff816e62d3 0000000000000008 [283465.551056] ffff880000000010 ffff8800a56fb848 ffff8800a56fb7e8 ffff88005df9f000 [283465.551710] Call Trace: [283465.552516] [] dump_stack+0x63/0x81 [283465.553291] [] panic+0xcb/0x21b [283465.554037] [] ocfs2_handle_error+0xf0/0xf0 [ocfs2] [283465.554882] [] __ocfs2_error+0x67/0x70 [ocfs2] [283465.555768] [] ocfs2_validate_inode_block+0x229/0x230 [ocfs2] [283465.556683] [] ocfs2_read_blocks+0x46c/0x7b0 [ocfs2] [283465.557408] [] ? ocfs2_inode_cache_io_unlock+0x20/0x20 [ocfs2] [283465.557973] [] ocfs2_read_inode_block_full+0x3b/0x60 [ocfs2] [283465.558525] [] ocfs2_iget+0x4aa/0x880 [ocfs2] [283465.559082] [] ocfs2_get_parent+0x9e/0x220 [ocfs2] [283465.559622] [] reconnect_path+0xb5/0x300 [283465.560156] [] exportfs_decode_fh+0xf6/0x2b0 [283465.560708] [] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd] [283465.561262] [] ? prepare_creds+0x26/0x110 [283465.561932] [] fh_verify+0x350/0x660 [nfsd] [283465.562862] [] ? nfsd_cache_lookup+0x44/0x630 [nfsd] [283465.563697] [] nfsd3_proc_getattr+0x69/0xf0 [nfsd] [283465.564510] [] nfsd_dispatch+0xe0/0x290 [nfsd] [283465.565358] [] ? svc_tcp_adjust_wspace+0x12/0x30 [sunrpc] [283465.566272] [] svc_process_common+0x412/0x6a0 [sunrpc] [283465.567155] [] svc_process+0x123/0x210 [sunrpc] [283465.568020] [] nfsd+0xff/0x170 [nfsd] [283465.568962] [] ? nfsd_destroy+0x80/0x80 [nfsd] [283465.570112] [] kthread+0xcb/0xf0 [283465.571099] [] ? kthread_create_on_node+0x180/0x180 [283465.572114] [] ret_from_fork+0x58/0x90 [283465.573156] [] ? kthread_create_on_node+0x180/0x180 Link: http://lkml.kernel.org/r/1554185919-3010-1-git-send-email-sunny.s.zhang@oracle.com Signed-off-by: Shuning Zhang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: piaojun Cc: "Gang He" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6417b14d06aacec51e33d2a75726f7dc06783099 Author: Brian Masney Date: Wed Apr 24 05:25:03 2019 -0400 backlight: lm3630a: Return 0 on success in update_status functions commit d3f48ec0954c6aac736ab21c34a35d7554409112 upstream. lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() both return the brightness value if the brightness was successfully updated. Writing to these attributes via sysfs would cause a 'Bad address' error to be returned. These functions should return 0 on success, so let's change it to correct that error. Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision") Signed-off-by: Brian Masney Acked-by: Pavel Machek Acked-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit 5aa0b508145ff5a8a339aaad14ce9632b262c7e4 Author: Steve Twiss Date: Fri Apr 26 14:33:35 2019 +0100 mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L commit 6b4814a9451add06d457e198be418bf6a3e6a990 upstream. Mismatch between what is found in the Datasheets for DA9063 and DA9063L provided by Dialog Semiconductor, and the register names provided in the MFD registers file. The changes are for the OTP (one-time-programming) control registers. The two naming errors are OPT instead of OTP, and COUNT instead of CONT (i.e. control). Signed-off-by: Steve Twiss Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit d8e6415bc177e37b9b02133e5e33ff2d5a5df447 Author: Jarod Wilson Date: Fri May 10 17:57:09 2019 -0400 bonding: fix arp_validate toggling in active-backup mode commit a9b8a2b39ce65df45687cf9ef648885c2a99fe75 upstream. There's currently a problem with toggling arp_validate on and off with an active-backup bond. At the moment, you can start up a bond, like so: modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1 ip link set bond0 down echo "ens4f0" > /sys/class/net/bond0/bonding/slaves echo "ens4f1" > /sys/class/net/bond0/bonding/slaves ip link set bond0 up ip addr add 192.168.1.2/24 dev bond0 Pings to 192.168.1.1 work just fine. Now turn on arp_validate: echo 1 > /sys/class/net/bond0/bonding/arp_validate Pings to 192.168.1.1 continue to work just fine. Now when you go to turn arp_validate off again, the link falls flat on it's face: echo 0 > /sys/class/net/bond0/bonding/arp_validate dmesg ... [133191.911987] bond0: Setting arp_validate to none (0) [133194.257793] bond0: bond_should_notify_peers: slave ens4f0 [133194.258031] bond0: link status definitely down for interface ens4f0, disabling it [133194.259000] bond0: making interface ens4f1 the new active one [133197.330130] bond0: link status definitely down for interface ens4f1, disabling it [133197.331191] bond0: now running without any active interface! The problem lies in bond_options.c, where passing in arp_validate=0 results in bond->recv_probe getting set to NULL. This flies directly in the face of commit 3fe68df97c7f, which says we need to set recv_probe = bond_arp_recv, even if we're not using arp_validate. Said commit fixed this in bond_option_arp_interval_set, but missed that we can get to that same state in bond_option_arp_validate_set as well. One solution would be to universally set recv_probe = bond_arp_recv here as well, but I don't think bond_option_arp_validate_set has any business touching recv_probe at all, and that should be left to the arp_interval code, so we can just make things much tidier here. Fixes: 3fe68df97c7f ("bonding: always set recv_probe to bond_arp_rcv in arp monitor") CC: Jay Vosburgh CC: Veaceslav Falico CC: Andy Gospodarek CC: "David S. Miller" CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 23653cbd4f6f885a89a90a68c4b7cd59b3c4d75a Author: Dan Carpenter Date: Mon May 6 15:50:18 2019 +0300 kdb: do a sanity check on the cpu in kdb_per_cpu() commit b586627e10f57ee3aa8f0cfab0d6f7dc4ae63760 upstream. The "whichcpu" comes from argv[3]. The cpu_online() macro looks up the cpu in a bitmap of online cpus, but if the value is too high then it could read beyond the end of the bitmap and possibly Oops. Fixes: 5d5314d6795f ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Dan Carpenter Reviewed-by: Douglas Anderson Signed-off-by: Daniel Thompson Signed-off-by: Ben Hutchings commit 36f680c1be1b46d2470fbf577ba229f4d81a154e Author: Lukas Czerner Date: Fri May 10 21:45:33 2019 -0400 ext4: fix data corruption caused by overlapping unaligned and aligned IO commit 57a0da28ced8707cb9f79f071a016b9d005caf5a upstream. Unaligned AIO must be serialized because the zeroing of partial blocks of unaligned AIO can result in data corruption in case it's overlapping another in flight IO. Currently we wait for all unwritten extents before we submit unaligned AIO which protects data in case of unaligned AIO is following overlapping IO. However if a unaligned AIO is followed by overlapping aligned AIO we can still end up corrupting data. To fix this, we must make sure that the unaligned AIO is the only IO in flight by waiting for unwritten extents conversion not just before the IO submission, but right after it as well. This problem can be reproduced by xfstest generic/538 Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: - Test aio_mutex instead of unaligned_aio - Adjust context] Signed-off-by: Ben Hutchings commit afa9b5186c1bf4b8a828af1899231642a1cf5a39 Author: Christian König Date: Mon May 6 19:57:52 2019 +0200 drm/radeon: prefer lower reference dividers commit 2e26ccb119bde03584be53406bbd22e711b0d6e6 upstream. Instead of the closest reference divider prefer the lowest, this fixes flickering issues on HP Compaq nx9420. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514 Suggested-by: Paul Dufresne Signed-off-by: Christian König Acked-by: Alex Deucher Signed-off-by: Alex Deucher [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 17b39cc4fe6923997827598fa8fad46206ef77d5 Author: ZhangXiaoxu Date: Mon May 6 11:57:03 2019 +0800 NFS4: Fix v4.0 client state corruption when mount commit f02f3755dbd14fb935d24b14650fff9ba92243b8 upstream. stat command with soft mount never return after server is stopped. When alloc a new client, the state of the client will be set to NFS4CLNT_LEASE_EXPIRED. When the server is stopped, the state manager will work, and accord the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it will drain the slot table and lead other task to wait queue, until the client recovered. Then the stat command is hung. When discover server trunking, the client will renew the lease, but check the client state, it lead the client state corruption. So, we need to call state manager to recover it when detect server ip trunking. Signed-off-by: ZhangXiaoxu Signed-off-by: Anna Schumaker Signed-off-by: Ben Hutchings commit 531716553f74c312b21b2c71a5a90b63c7b897ee Author: Miroslav Lichvar Date: Wed Apr 17 10:48:33 2019 +0200 ntp: Allow TAI-UTC offset to be set to zero commit fdc6bae940ee9eb869e493990540098b8c0fd6ab upstream. The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock. It is typically set by NTP/PTP implementations and it is automatically updated by the kernel on leap seconds. The initial value is zero (which applications may interpret as unknown), but this value cannot be set by adjtimex. This limitation seems to go back to the original "nanokernel" implementation by David Mills. Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in order to allow setting it back to the initial value. Fixes: 153b5d054ac2 ("ntp: support for TAI") Suggested-by: Ondrej Mosnacek Signed-off-by: Miroslav Lichvar Signed-off-by: Thomas Gleixner Cc: John Stultz Cc: Richard Cochran Cc: Prarit Bhargava Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com Signed-off-by: Ben Hutchings commit c140ca37d8f979b0ddb721b3fc7d6e16ae1305a8 Author: Florian Westphal Date: Sun May 5 18:47:33 2019 +0200 netfilter: ebtables: CONFIG_COMPAT: reject trailing data after last rule commit 680f6af5337c98d116e4f127cea7845339dba8da upstream. If userspace provides a rule blob with trailing data after last target, we trigger a splat, then convert ruleset to 64bit format (with trailing data), then pass that to do_replace_finish() which then returns -EINVAL. Erroring out right away avoids the splat plus unneeded translation and error unwind. Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support") Reported-by: Tetsuo Handa Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Ben Hutchings commit e9895779b816d9d2fcd46fc6e572df2033fd06c7 Author: Gustavo A. R. Silva Date: Wed Apr 24 13:09:34 2019 -0500 platform/x86: sony-laptop: Fix unintentional fall-through commit 1cbd7a64959d33e7a2a1fa2bf36a62b350a9fcbd upstream. It seems that the default case should return AE_CTRL_TERMINATE, instead of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK; otherwise the line of code at the end of the function is unreachable and makes no sense: return AE_CTRL_TERMINATE; This fix is based on the following thread of discussion: https://lore.kernel.org/patchwork/patch/959782/ Fixes: 33a04454527e ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Andy Shevchenko Signed-off-by: Ben Hutchings commit fc068421cdd6e112582ccd255b492be64d1b2f21 Author: Dan Carpenter Date: Wed Apr 24 12:44:18 2019 +0300 platform/x86: alienware-wmi: printing the wrong error code commit 6d1f8b3d75419a8659ac916a1e9543bb3513a882 upstream. The "out_data" variable is uninitialized at the point. Originally, this used to print "status" instead and that seems like the correct thing to print. Fixes: bc2ef884320b ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status") Signed-off-by: Dan Carpenter Reviewed-by: Mario Limonciello Signed-off-by: Andy Shevchenko Signed-off-by: Ben Hutchings commit 993b03c917d72759a638b266ceb5652a1ee84dc7 Author: Dan Carpenter Date: Wed Apr 24 05:46:27 2019 -0400 media: davinci/vpbe: array underflow in vpbe_enum_outputs() commit b72845ee5577b227131b1fef23f9d9a296621d7b upstream. In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but the problem is that "temp_index" can be negative. This patch changes the types to unsigned to address this array underflow bug. Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver") Signed-off-by: Dan Carpenter Acked-by: "Lad, Prabhakar" Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 00bd59675f5f81338c9edde2d71645aa286d1f84 Author: Dan Carpenter Date: Thu Apr 11 05:01:57 2019 -0400 media: omap_vout: potential buffer overflow in vidioc_dqbuf() commit dd6e2a981bfe83aa4a493143fd8cf1edcda6c091 upstream. The "b->index" is a u32 the comes from the user in the ioctl. It hasn't been checked. We aren't supposed to use it but we're instead supposed to use the value that gets written to it when we call videobuf_dqbuf(). The videobuf_dqbuf() first memsets it to zero and then re-initializes it inside the videobuf_status() function. It's this final value which we want. Hans Verkuil pointed out that we need to check the return from videobuf_dqbuf(). I ended up doing a little cleanup related to that as well. Fixes: 72915e851da9 ("[media] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 0c0c20a940b19138e42b57a68c2b1aafbb9846de Author: Stephen Suryaputra Date: Mon Jun 24 20:14:06 2019 -0400 ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop commit 38c73529de13e1e10914de7030b659a2f8b01c3b upstream. In commit 19e4e768064a8 ("ipv4: Fix raw socket lookup for local traffic"), the dif argument to __raw_v4_lookup() is coming from the returned value of inet_iif() but the change was done only for the first lookup. Subsequent lookups in the while loop still use skb->dev->ifIndex. Fixes: 19e4e768064a8 ("ipv4: Fix raw socket lookup for local traffic") Signed-off-by: Stephen Suryaputra Reviewed-by: David Ahern Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 42e9b805a5a334c8673dd204415977abea57d71a Author: David Ahern Date: Tue May 7 20:44:59 2019 -0700 ipv4: Fix raw socket lookup for local traffic commit 19e4e768064a87b073a4b4c138b55db70e0cfb9f upstream. inet_iif should be used for the raw socket lookup. inet_iif considers rt_iif which handles the case of local traffic. As it stands, ping to a local address with the '-I ' option fails ever since ping was changed to use SO_BINDTODEVICE instead of cmsg + IP_PKTINFO. IPv6 works fine. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: David Ahern Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit cc8b1a5dd2df701c7d619d12b90c6f341743340c Author: Elazar Leibovich Date: Mon Dec 31 13:58:37 2018 +0200 tracing: Fix partial reading of trace event's id file commit cbe08bcbbe787315c425dde284dcb715cfbf3f39 upstream. When reading only part of the id file, the ppos isn't tracked correctly. This is taken care by simple_read_from_buffer. Reading a single byte, and then the next byte would result EOF. While this seems like not a big deal, this breaks abstractions that reads information from files unbuffered. See for example https://github.com/golang/go/issues/29399 This code was mentioned as problematic in commit cd458ba9d5a5 ("tracing: Do not (ab)use trace_seq in event_id_read()") An example C code that show this bug is: #include #include #include #include #include #include int main(int argc, char **argv) { if (argc < 2) return 1; int fd = open(argv[1], O_RDONLY); char c; read(fd, &c, 1); printf("First %c\n", c); read(fd, &c, 1); printf("Second %c\n", c); } Then run with, e.g. sudo ./a.out /sys/kernel/debug/tracing/events/tcp/tcp_set_state/id You'll notice you're getting the first character twice, instead of the first two characters in the id file. Link: http://lkml.kernel.org/r/20181231115837.4932-1-elazar@lightbitslabs.com Cc: Orit Wasserman Cc: Oleg Nesterov Cc: Ingo Molnar Fixes: 23725aeeab10b ("ftrace: provide an id file for each event") Signed-off-by: Elazar Leibovich Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings commit 67d35f29cd9729fc5641b74fe848e6f7cb599359 Author: Christoph Probst Date: Tue May 7 17:16:40 2019 +0200 cifs: fix strcat buffer overflow and reduce raciness in smb21_set_oplock_level() commit 6a54b2e002c9d00b398d35724c79f9fe0d9b38fb upstream. Change strcat to strncpy in the "None" case to fix a buffer overflow when cinode->oplock is reset to 0 by another thread accessing the same cinode. It is never valid to append "None" to any other message. Consolidate multiple writes to cinode->oplock to reduce raciness. Signed-off-by: Christoph Probst Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit 4c2fa9dab83f3bf8f584a6b51c151d04d0c02f66 Author: Jeff Layton Date: Tue May 7 09:20:54 2019 -0400 ceph: flush dirty inodes before proceeding with remount commit 00abf69dd24f4444d185982379c5cc3bb7b6d1fc upstream. xfstest generic/452 was triggering a "Busy inodes after umount" warning. ceph was allowing the mount to go read-only without first flushing out dirty inodes in the cache. Ensure we sync out the filesystem before allowing a remount to proceed. Link: http://tracker.ceph.com/issues/39571 Signed-off-by: Jeff Layton Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Ben Hutchings commit 21df0879fe7b4ea3eab3e149edb85fef83862dcb Author: Jon Hunter Date: Wed May 1 15:29:38 2019 +0100 ASoC: max98090: Fix restore of DAPM Muxes commit ecb2795c08bc825ebd604997e5be440b060c5b18 upstream. The max98090 driver defines 3 DAPM muxes; one for the right line output (LINMOD Mux), one for the left headphone mixer source (MIXHPLSEL Mux) and one for the right headphone mixer source (MIXHPRSEL Mux). The same bit is used for the mux as well as the DAPM enable, and although the mux can be correctly configured, after playback has completed, the mux will be reset during the disable phase. This is preventing the state of these muxes from being saved and restored correctly on system reboot. Fix this by marking these muxes as SND_SOC_NOPM. Note this has been verified this on the Tegra124 Nyan Big which features the MAX98090 codec. Signed-off-by: Jon Hunter Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit c322ba7cd39bd986476e35edc8adc05512d9e6f1 Author: Hui Wang Date: Mon May 6 22:09:31 2019 +0800 ALSA: hda/hdmi - Read the pin sense from register when repolling commit 8c2e6728c2bf95765b724e07d0278ae97cd1ee0d upstream. The driver will check the monitor presence when resuming from suspend, starting poll or interrupt triggers. In these 3 situations, the jack_dirty will be set to 1 first, then the hda_jack.c reads the pin_sense from register, after reading the register, the jack_dirty will be set to 0. But hdmi_repoll_work() is enabled in these 3 situations, It will read the pin_sense a couple of times subsequently, since the jack_dirty is 0 now, It does not read the register anymore, instead it uses the shadow pin_sense which is read at the first time. It is meaningless to check the shadow pin_sense a couple of times, we need to read the register to check the real plugging state, so we set the jack_dirty to 1 in the hdmi_repoll_work(). Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 5f58860a71e06124f8b1426cf606952f35eb719a Author: Christophe Leroy Date: Fri May 3 13:33:23 2019 +0000 net: ucc_geth - fix Oops when changing number of buffers in the ring commit ee0df19305d9fabd9479b785918966f6e25b733b upstream. When changing the number of buffers in the RX ring while the interface is running, the following Oops is encountered due to the new number of buffers being taken into account immediately while their allocation is done when opening the device only. [ 69.882706] Unable to handle kernel paging request for data at address 0xf0000100 [ 69.890172] Faulting instruction address: 0xc033e164 [ 69.895122] Oops: Kernel access of bad area, sig: 11 [#1] [ 69.900494] BE PREEMPT CMPCPRO [ 69.907120] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.115-00006-g179ade8ce3-dirty #269 [ 69.915956] task: c0684310 task.stack: c06da000 [ 69.920470] NIP: c033e164 LR: c02e44d0 CTR: c02e41fc [ 69.925504] REGS: dfff1e20 TRAP: 0300 Not tainted (4.14.115-00006-g179ade8ce3-dirty) [ 69.934161] MSR: 00009032 CR: 22004428 XER: 20000000 [ 69.940869] DAR: f0000100 DSISR: 20000000 [ 69.940869] GPR00: c0352d70 dfff1ed0 c0684310 f00000a4 00000040 dfff1f68 00000000 0000001f [ 69.940869] GPR08: df53f410 1cc00040 00000021 c0781640 42004424 100c82b6 f00000a4 df53f5b0 [ 69.940869] GPR16: df53f6c0 c05daf84 00000040 00000000 00000040 c0782be4 00000000 00000001 [ 69.940869] GPR24: 00000000 df53f400 000001b0 df53f410 df53f000 0000003f df708220 1cc00044 [ 69.978348] NIP [c033e164] skb_put+0x0/0x5c [ 69.982528] LR [c02e44d0] ucc_geth_poll+0x2d4/0x3f8 [ 69.987384] Call Trace: [ 69.989830] [dfff1ed0] [c02e4554] ucc_geth_poll+0x358/0x3f8 (unreliable) [ 69.996522] [dfff1f20] [c0352d70] net_rx_action+0x248/0x30c [ 70.002099] [dfff1f80] [c04e93e4] __do_softirq+0xfc/0x310 [ 70.007492] [dfff1fe0] [c0021124] irq_exit+0xd0/0xd4 [ 70.012458] [dfff1ff0] [c000e7e0] call_do_irq+0x24/0x3c [ 70.017683] [c06dbe80] [c0006bac] do_IRQ+0x64/0xc4 [ 70.022474] [c06dbea0] [c001097c] ret_from_except+0x0/0x14 [ 70.027964] --- interrupt: 501 at rcu_idle_exit+0x84/0x90 [ 70.027964] LR = rcu_idle_exit+0x74/0x90 [ 70.037585] [c06dbf60] [20000000] 0x20000000 (unreliable) [ 70.042984] [c06dbf80] [c004bb0c] do_idle+0xb4/0x11c [ 70.047945] [c06dbfa0] [c004bd14] cpu_startup_entry+0x18/0x1c [ 70.053682] [c06dbfb0] [c05fb034] start_kernel+0x370/0x384 [ 70.059153] [c06dbff0] [00003438] 0x3438 [ 70.063062] Instruction dump: [ 70.066023] 38a00000 38800000 90010014 4bfff015 80010014 7c0803a6 3123ffff 7c691910 [ 70.073767] 38210010 4e800020 38600000 4e800020 <80e3005c> 80c30098 3107ffff 7d083910 [ 70.081690] ---[ end trace be7ccd9c1e1a9f12 ]--- This patch forbids the modification of the number of buffers in the ring while the interface is running. Fixes: ac421852b3a0 ("ucc_geth: add ethtool support") Signed-off-by: Christophe Leroy Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 60a934906822afb4573249fa1ac353a9483c73fb Author: Lu Baolu Date: Thu May 2 09:34:25 2019 +0800 iommu/vt-d: Set intel_iommu_gfx_mapped correctly commit cf1ec4539a50bdfe688caad4615ca47646884316 upstream. The intel_iommu_gfx_mapped flag is exported by the Intel IOMMU driver to indicate whether an IOMMU is used for the graphic device. In a virtualized IOMMU environment (e.g. QEMU), an include-all IOMMU is used for graphic device. This flag is found to be clear even the IOMMU is used. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Reported-by: Zhenyu Wang Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.") Suggested-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Ben Hutchings commit e407b0a0cc7517c503d26b5a702a4a0318222fd7 Author: Laurentiu Tudor Date: Mon Apr 15 14:52:11 2019 +0300 powerpc/booke64: set RI in default MSR commit 5266e58d6cd90ac85c187d673093ad9cb649e16d upstream. Set RI in the default kernel's MSR so that the architected way of detecting unrecoverable machine check interrupts has a chance to work. This is inline with the MSR setup of the rest of booke powerpc architectures configured here. Signed-off-by: Laurentiu Tudor Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 60a7e25213a60503cc58885b3eb12fcaa7aa8f89 Author: S.j. Wang Date: Sun Apr 28 02:24:27 2019 +0000 ASoC: fsl_esai: Fix missing break in switch statement commit 903c220b1ece12f17c868e43f2243b8f81ff2d4c upstream. case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of each other, so replace fall-through with break. Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Signed-off-by: Mark Brown [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8939c50855f40af4963daf1550b30923052ba599 Author: Phong Tran Date: Tue Apr 30 21:56:24 2019 +0700 of: fix clang -Wunsequenced for be32_to_cpu() commit 440868661f36071886ed360d91de83bd67c73b4f upstream. Now, make the loop explicit to avoid clang warning. ./include/linux/of.h:238:37: warning: multiple unsequenced modifications to 'cell' [-Wunsequenced] r = (r << 32) | be32_to_cpu(*(cell++)); ^~ ./include/linux/byteorder/generic.h:95:21: note: expanded from macro 'be32_to_cpu' ^ ./include/uapi/linux/byteorder/little_endian.h:40:59: note: expanded from macro '__be32_to_cpu' ^ ./include/uapi/linux/swab.h:118:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ ./include/uapi/linux/swab.h:18:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ ^ Signed-off-by: Phong Tran Reported-by: Nick Desaulniers Link: https://github.com/ClangBuiltLinux/linux/issues/460 Suggested-by: David Laight Reviewed-by: Nick Desaulniers [robh: fix up whitespace] Signed-off-by: Rob Herring Signed-off-by: Ben Hutchings commit df48f1bc39827e750a9490b3c4abd6fdbfed8bb6 Author: Johan Hovold Date: Thu Apr 25 18:05:36 2019 +0200 USB: serial: fix unthrottle races commit 3f5edd58d040bfa4b74fb89bc02f0bc6b9cd06ab upstream. Fix two long-standing bugs which could potentially lead to memory corruption or leave the port throttled until it is reopened (on weakly ordered systems), respectively, when read-URB completion races with unthrottle(). First, the URB must not be marked as free before processing is complete to prevent it from being submitted by unthrottle() on another CPU. CPU 1 CPU 2 ================ ================ complete() unthrottle() process_urb(); smp_mb__before_atomic(); set_bit(i, free); if (test_and_clear_bit(i, free)) submit_urb(); Second, the URB must be marked as free before checking the throttled flag to prevent unthrottle() on another CPU from failing to observe that the URB needs to be submitted if complete() sees that the throttled flag is set. CPU 1 CPU 2 ================ ================ complete() unthrottle() set_bit(i, free); throttled = 0; smp_mb__after_atomic(); smp_mb(); if (throttled) if (test_and_clear_bit(i, free)) return; submit_urb(); Note that test_and_clear_bit() only implies barriers when the test is successful. To handle the case where the URB is still in use an explicit barrier needs to be added to unthrottle() for the second race condition. Fixes: d83b405383c9 ("USB: serial: add support for multiple read urbs") Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 650ef8048e3fdedab690e771ec456b417bb7cf3b Author: Oliver Neukum Date: Thu Jul 14 15:01:40 2016 +0200 USB: serial: use variable for status commit 3161da970d38cd6ed2ba8cadec93874d1d06e11e upstream. This patch turns status in a variable read once from the URB. The long term plan is to deliver status to the callback. In addition it makes the code a bit more elegant. Signed-off-by: Oliver Neukum Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit d7a710e3e60080dba8a8669c0fe6a30f61c43023 Author: Johan Hovold Date: Thu Apr 25 18:05:39 2019 +0200 USB: cdc-acm: fix unthrottle races commit 764478f41130f1b8d8057575b89e69980a0f600d upstream. Fix two long-standing bugs which could potentially lead to memory corruption or leave the port throttled until it is reopened (on weakly ordered systems), respectively, when read-URB completion races with unthrottle(). First, the URB must not be marked as free before processing is complete to prevent it from being submitted by unthrottle() on another CPU. CPU 1 CPU 2 ================ ================ complete() unthrottle() process_urb(); smp_mb__before_atomic(); set_bit(i, free); if (test_and_clear_bit(i, free)) submit_urb(); Second, the URB must be marked as free before checking the throttled flag to prevent unthrottle() on another CPU from failing to observe that the URB needs to be submitted if complete() sees that the throttled flag is set. CPU 1 CPU 2 ================ ================ complete() unthrottle() set_bit(i, free); throttled = 0; smp_mb__after_atomic(); smp_mb(); if (throttled) if (test_and_clear_bit(i, free)) return; submit_urb(); Note that test_and_clear_bit() only implies barriers when the test is successful. To handle the case where the URB is still in use an explicit barrier needs to be added to unthrottle() for the second race condition. Also note that the first race was fixed by 36e59e0d70d6 ("cdc-acm: fix race between callback and unthrottle") back in 2015, but the bug was reintroduced a year later. Fixes: 1aba579f3cf5 ("cdc-acm: handle read pipe errors") Fixes: 088c64f81284 ("USB: cdc-acm: re-write read processing") Signed-off-by: Johan Hovold Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8808cf46b68a08cb07e067e8da3e97242c3148ea Author: Romain Izard Date: Fri Mar 22 16:53:02 2019 +0100 usb: cdc-acm: fix race during wakeup blocking TX traffic commit 93e1c8a638308980309e009cc40b5a57ef87caf1 upstream. When the kernel is compiled with preemption enabled, the URB completion handler can run in parallel with the work responsible for waking up the tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the call to tty_port_tty_wakeup() to signal that there is room for additional input, it will be cleared at the end of this call. As a result, TX traffic on the upper layer will be blocked. This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast modem connected with PPP running over a USB CDC-ACM port. Use test_and_clear_bit() instead, which ensures that each wakeup requested by the URB completion code will trigger a call to tty_port_tty_wakeup(). Fixes: 1aba579f3cf5 cdc-acm: handle read pipe errors Signed-off-by: Romain Izard Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 00452300a6ef012b1d7ce97c9c04d665237a3e0e Author: Ladislav Michl Date: Fri Nov 18 19:11:26 2016 +0100 cdc-acm: handle read pipe errors commit 1aba579f3cf51fd0fe0b4d46cc13823fd1200acb upstream. Read urbs are submitted back only on success, causing read pipe running out of urbs after few errors. No more characters can be read from tty device then until it is reopened and no errors are reported. Fix that by always submitting urbs back and clearing stall on -EPIPE. Signed-off-by: Ladislav Michl Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 41266b6b31d2fa89ad385f2bc17c9eec48defa05 Author: Ladislav Michl Date: Fri Nov 18 19:09:19 2016 +0100 cdc-acm: store in and out pipes in acm structure commit 74bccc9b71dc41d37e73fcdbcbec85310a670751 upstream. Clearing stall needs pipe descriptor, store it in acm structure. Signed-off-by: Ladislav Michl Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ade92345934517e7229ef343b53819d67c84f025 Author: Oliver Neukum Date: Fri Mar 20 09:24:24 2015 +0100 cdc-acm: fix race between callback and unthrottle commit 36e59e0d70d6150e7a2155c54612ea875e88ce8d upstream. Abn URB may be may marked free only after the buffer has been processed or there is a small window during which it could be submitted on another CPU and overwrite an unprocessed buffer Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 22131d100411351f5dd1b3457ef12d7f2539188d Author: Wenwen Wang Date: Sat Apr 27 01:06:46 2019 -0500 ALSA: usb-audio: Fix a memory leak bug commit cb5173594d50c72b7bfa14113dfc5084b4d2f726 upstream. In parse_audio_selector_unit(), the string array 'namelist' is allocated through kmalloc_array(), and each string pointer in this array, i.e., 'namelist[]', is allocated through kmalloc() in the following for loop. Then, a control instance 'kctl' is created by invoking snd_ctl_new1(). If an error occurs during the creation process, the string array 'namelist', including all string pointers in the array 'namelist[]', should be freed, before the error code ENOMEM is returned. However, the current code does not free 'namelist[]', resulting in memory leaks. To fix the above issue, free all string pointers 'namelist[]' in a loop. Signed-off-by: Wenwen Wang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 5cd237f44b6f3d8897daa92810839c6e50c3b19d Author: Takashi Iwai Date: Fri Aug 30 12:03:38 2019 +0200 ALSA: hda/realtek - Fix overridden device-specific initialization commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream. The recent change to shuffle the codec initialization procedure for Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") caused the silent output on some machines. This change was supposed to be safe, but it isn't actually; some devices have quirk setups to override the EAPD via COEF or BTL in the additional verb table, which is applied at the beginning of snd_hda_gen_init(). And this EAPD setup is again overridden in alc_auto_init_amp(). For recovering from the regression, tell snd_hda_gen_init() not to apply the verbs there by a new flag, then apply the verbs in alc_init(). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727 Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c4ab0304c2cb1bbbc5fcf4a759c6b21abe9a3794 Author: Kailang Yang Date: Fri Apr 26 16:35:41 2019 +0800 ALSA: hda/realtek - EAPD turn on later commit 607ca3bd220f4022e6f5356026b19dafc363863a upstream. Let EAPD turn on after set pin output. [ NOTE: This change is supposed to reduce the possible click noises at (runtime) PM resume. The functionality should be same (i.e. the verbs are executed correctly) no matter which order is, so this should be safe to apply for all codecs -- tiwai ] Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit efc2607bcfc633a9b066f87d93a7471ed9d5d8a7 Author: Johan Hovold Date: Sun Apr 21 14:21:46 2019 +0200 USB: serial: fix initial-termios handling commit 579bebe5dd522580019e7b10b07daaf500f9fb1e upstream. The USB-serial driver init_termios callback is used to override the default initial terminal settings provided by USB-serial core. After a bug was fixed in the original implementation introduced by commit fe1ae7fdd2ee ("tty: USB serial termios bits"), the init_termios callback was no longer called just once on first use as intended but rather on every (first) open. This specifically meant that the terminal settings saved on (final) close were ignored when reopening a port for drivers overriding the initial settings. Also update the outdated function header referring to the creation of termios objects. Fixes: 7e29bb4b779f ("usb-serial: fix termios initialization logic") Signed-off-by: Johan Hovold [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 2f802f4805d858a7087d6493694d9a0ce9a256f4 Author: Kirill Tkhai Date: Thu Apr 25 13:06:18 2019 -0400 ext4: actually request zeroing of inode table after grow commit 310a997fd74de778b9a4848a64be9cda9f18764a upstream. It is never possible, that number of block groups decreases, since only online grow is supported. But after a growing occured, we have to zero inode tables for just created new block groups. Fixes: 19c5246d2516 ("ext4: add new online resize interface") Signed-off-by: Kirill Tkhai Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Ben Hutchings commit 3c3e63e351405fff843102db8222b397068e5281 Author: Pan Bian Date: Wed Apr 17 17:41:23 2019 +0800 p54: drop device reference count if fails to enable device commit 8149069db81853570a665f5e5648c0e526dc0e43 upstream. The function p54p_probe takes an extra reference count of the PCI device. However, the extra reference count is not dropped when it fails to enable the PCI device. This patch fixes the bug. Signed-off-by: Pan Bian Acked-by: Christian Lamparter Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit c4e8f65dc299b14f79a545748817be5ed48f0e0b Author: Petr Štetiar Date: Thu Apr 11 20:13:30 2019 +0200 mwl8k: Fix rate_idx underflow commit 6b583201fa219b7b1b6aebd8966c8fd9357ef9f4 upstream. It was reported on OpenWrt bug tracking system[1], that several users are affected by the endless reboot of their routers if they configure 5GHz interface with channel 44 or 48. The reboot loop is caused by the following excessive number of WARN_ON messages: WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516 ieee80211_rx_napi+0x1fc/0xa54 [mac80211] as the messages are being correctly emitted by the following guard: case RX_ENC_LEGACY: if (WARN_ON(status->rate_idx >= sband->n_bitrates)) as the rate_idx is in this case erroneously set to 251 (0xfb). This fix simply converts previously used magic number to proper constant and guards against substraction which is leading to the currently observed underflow. 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218 Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive") Tested-by: Eubert Bao Reported-by: Eubert Bao Signed-off-by: Petr Štetiar Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 4a881abca144abc45f04b580fbadec879e4042f4 Author: YueHaibing Date: Mon Apr 8 11:45:29 2019 +0800 at76c50x-usb: Don't register led_trigger if usb_register_driver failed commit 09ac2694b0475f96be895848687ebcbba97eeecf upstream. Syzkaller report this: [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338 [ 1213.469530] #PF error: [normal kernel read fault] [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0 [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8 [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0 [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246 [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6 [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0 [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004 [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900 [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0 [ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000 [ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0 [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1213.473514] PKRU: 55555554 [ 1213.473514] Call Trace: [ 1213.473514] led_trigger_register+0x112/0x3f0 [ 1213.473514] led_trigger_register_simple+0x7a/0x110 [ 1213.473514] ? 0xffffffffc1c10000 [ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb] [ 1213.473514] do_one_initcall+0xbc/0x47d [ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0 [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40 [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40 [ 1213.473514] do_init_module+0x1b5/0x547 [ 1213.473514] load_module+0x6405/0x8c10 [ 1213.473514] ? module_frob_arch_sections+0x20/0x20 [ 1213.473514] ? kernel_read_file+0x1e6/0x5d0 [ 1213.473514] ? find_held_lock+0x32/0x1c0 [ 1213.473514] ? cap_capable+0x1ae/0x210 [ 1213.473514] ? __do_sys_finit_module+0x162/0x190 [ 1213.473514] __do_sys_finit_module+0x162/0x190 [ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0 [ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690 [ 1213.473514] ? wait_for_completion+0x370/0x370 [ 1213.473514] ? vfs_write+0x204/0x4a0 [ 1213.473514] ? do_syscall_64+0x18/0x450 [ 1213.473514] do_syscall_64+0x9f/0x450 [ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1213.473514] RIP: 0033:0x462e99 [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003 [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000 [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004 If usb_register failed, no need to call led_trigger_register_simple. Reported-by: Hulk Robot Fixes: 1264b951463a ("at76c50x-usb: add driver") Signed-off-by: YueHaibing Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 6cd1331860245668995c9adf15d2a0eb10f0bc2d Author: Dmitry Osipenko Date: Fri Apr 12 00:48:34 2019 +0300 clk: tegra: Fix PLLM programming on Tegra124+ when PMC overrides divider commit 40db569d6769ffa3864fd1b89616b1a7323568a8 upstream. There are wrongly set parenthesis in the code that are resulting in a wrong configuration being programmed for PLLM. The original fix was made by Danny Huang in the downstream kernel. The patch was tested on Nyan Big Tegra124 chromebook, PLLM rate changing works correctly now and system doesn't lock up after changing the PLLM rate due to EMC scaling. Tested-by: Steev Klimaszewski Signed-off-by: Dmitry Osipenko Acked-By: Peter De Schrijver Signed-off-by: Stephen Boyd Signed-off-by: Ben Hutchings commit e683e0c25ce62690fb5445ac1156c68b785d186e Author: Matias Karhumaa Date: Tue Jul 2 16:35:09 2019 +0200 Bluetooth: Fix faulty expression for minimum encryption key size check commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream. Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is also allowed as stated in the comment. This bug caused connection problems with devices having maximum encryption key size of 7 octets (56-bit). Fixes: 693cd8ce3f88 ("Bluetooth: Fix regression with minimum encryption key size alignment") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997 Signed-off-by: Matias Karhumaa Signed-off-by: Marcel Holtmann Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 251ff7c5d9ef901c652b89162a3a4c5b2546aaca Author: Marcel Holtmann Date: Sat Jun 22 15:47:01 2019 +0200 Bluetooth: Fix regression with minimum encryption key size alignment commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream. When trying to align the minimum encryption key size requirement for Bluetooth connections, it turns out doing this in a central location in the HCI connection handling code is not possible. Original Bluetooth version up to 2.0 used a security model where the L2CAP service would enforce authentication and encryption. Starting with Bluetooth 2.1 and Secure Simple Pairing that model has changed into that the connection initiator is responsible for providing an encrypted ACL link before any L2CAP communication can happen. Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and before devices are causing a regression. The encryption key size check needs to be moved out of the HCI connection handling into the L2CAP channel setup. To achieve this, the current check inside hci_conn_security() has been moved into l2cap_check_enc_key_size() helper function and then called from four decisions point inside L2CAP to cover all combinations of Secure Simple Pairing enabled devices and device using legacy pairing and legacy service security model. Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643 Signed-off-by: Marcel Holtmann Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: - Encryption flag is in hci_conn::link_mode not hci_conn::flags - Adjust context, indentation] Signed-off-by: Ben Hutchings commit 1f52c0fb870d0a3e00f790d5a8085bcb234ad0fe Author: Marcel Holtmann Date: Wed Apr 24 22:19:17 2019 +0200 Bluetooth: Align minimum encryption key size for LE and BR/EDR connections commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream. The minimum encryption key size for LE connections is 56 bits and to align LE with BR/EDR, enforce 56 bits of minimum encryption key size for BR/EDR connections as well. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: Ben Hutchings commit 889822ef3977e12dccffcf092c1dcd0467c6f378 Author: Lyude Paul Date: Tue Feb 12 17:02:30 2019 -0500 PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream. On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002 This causes a timeout trying to bring up the GR ctx: nouveau 0000:01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<000000007faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-lyude@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs [bwh: Backported to 3.16: - Use dev_{err,info}() instead of pci_{err,info}() - Adjust context] Signed-off-by: Ben Hutchings commit 356dd4bdc8058950cfb8b687b90864427a39b055 Author: Jiri Slaby Date: Wed Apr 17 10:58:53 2019 +0200 TTY: serial_core, add ->install commit 4cdd17ba1dff20ffc99fdbd2e6f0201fc7fe67df upstream. We need to compute the uart state only on the first open. This is usually what is done in the ->install hook. serial_core used to do this in ->open on every open. So move it to ->install. As a side effect, it ensures the state is set properly in the window after tty_init_dev is called, but before uart_open. This fixes a bunch of races between tty_open and flush_to_ldisc we were dealing with recently. One of such bugs was attempted to fix in commit fedb5760648a (serial: fix race between flush_to_ldisc and tty_open), but it only took care of a couple of functions (uart_start and uart_unthrottle). I was able to reproduce the crash on a SLE system, but in uart_write_room which is also called from flush_to_ldisc via process_echoes. I was *unable* to reproduce the bug locally. It is due to having this patch in my queue since 2012! general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 5 Comm: kworker/u4:0 Tainted: G L 4.12.14-396-default #1 SLE15-SP1 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound flush_to_ldisc task: ffff8800427d8040 task.stack: ffff8800427f0000 RIP: 0010:uart_write_room+0xc4/0x590 RSP: 0018:ffff8800427f7088 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000002f RSI: 00000000000000ee RDI: ffff88003888bd90 RBP: ffffffffb9545850 R08: 0000000000000001 R09: 0000000000000400 R10: ffff8800427d825c R11: 000000000000006e R12: 1ffff100084fee12 R13: ffffc900004c5000 R14: ffff88003888bb28 R15: 0000000000000178 FS: 0000000000000000(0000) GS:ffff880043300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561da0794148 CR3: 000000000ebf4000 CR4: 00000000000006e0 Call Trace: tty_write_room+0x6d/0xc0 __process_echoes+0x55/0x870 n_tty_receive_buf_common+0x105e/0x26d0 tty_ldisc_receive_buf+0xb7/0x1c0 tty_port_default_receive_buf+0x107/0x180 flush_to_ldisc+0x35d/0x5c0 ... 0 in rbx means tty->driver_data is NULL in uart_write_room. 0x178 is tried to be dereferenced (0x178 >> 3 is 0x2f in rdx) at uart_write_room+0xc4. 0x178 is exactly (struct uart_state *)NULL->refcount used in uart_port_lock from uart_write_room. So revert the upstream commit here as my local patch should fix the whole family. Signed-off-by: Jiri Slaby Cc: Li RongQing Cc: Wang Li Cc: Zhang Yu Cc: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: The previous fix didn't apply, so we don't need to revert it here.] Signed-off-by: Ben Hutchings commit 3cddd3866be7e3c5f05ea0b8eda435b75320160d Author: Coly Li Date: Thu Apr 25 00:48:33 2019 +0800 bcache: never set KEY_PTRS of journal key to 0 in journal_reclaim() commit 1bee2addc0c8470c8aaa65ef0599eeae96dd88bc upstream. In journal_reclaim() ja->cur_idx of each cache will be update to reclaim available journal buckets. Variable 'int n' is used to count how many cache is successfully reclaimed, then n is set to c->journal.key by SET_KEY_PTRS(). Later in journal_write_unlocked(), a for_each_cache() loop will write the jset data onto each cache. The problem is, if all jouranl buckets on each cache is full, the following code in journal_reclaim(), 529 for_each_cache(ca, c, iter) { 530 struct journal_device *ja = &ca->journal; 531 unsigned int next = (ja->cur_idx + 1) % ca->sb.njournal_buckets; 532 533 /* No space available on this device */ 534 if (next == ja->discard_idx) 535 continue; 536 537 ja->cur_idx = next; 538 k->ptr[n++] = MAKE_PTR(0, 539 bucket_to_sector(c, ca->sb.d[ja->cur_idx]), 540 ca->sb.nr_this_dev); 541 } 542 543 bkey_init(k); 544 SET_KEY_PTRS(k, n); If there is no available bucket to reclaim, the if() condition at line 534 will always true, and n remains 0. Then at line 544, SET_KEY_PTRS() will set KEY_PTRS field of c->journal.key to 0. Setting KEY_PTRS field of c->journal.key to 0 is wrong. Because in journal_write_unlocked() the journal data is written in following loop, 649 for (i = 0; i < KEY_PTRS(k); i++) { 650-671 submit journal data to cache device 672 } If KEY_PTRS field is set to 0 in jouranl_reclaim(), the journal data won't be written to cache device here. If system crahed or rebooted before bkeys of the lost journal entries written into btree nodes, data corruption will be reported during bcache reload after rebooting the system. Indeed there is only one cache in a cache set, there is no need to set KEY_PTRS field in journal_reclaim() at all. But in order to keep the for_each_cache() logic consistent for now, this patch fixes the above problem by not setting 0 KEY_PTRS of journal key, if there is no bucket available to reclaim. Signed-off-by: Coly Li Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 149f2c1b7ef45fd98fbc49d5de7d0e5d6df6c2c8 Author: Liang Chen Date: Thu Apr 25 00:48:31 2019 +0800 bcache: fix a race between cache register and cacheset unregister commit a4b732a248d12cbdb46999daf0bf288c011335eb upstream. There is a race between cache device register and cache set unregister. For an already registered cache device, register_bcache will call bch_is_open to iterate through all cachesets and check every cache there. The race occurs if cache_set_free executes at the same time and clears the caches right before ca is dereferenced in bch_is_open_cache. To close the race, let's make sure the clean up work is protected by the bch_register_lock as well. This issue can be reproduced as follows, while true; do echo /dev/XXX> /sys/fs/bcache/register ; done& while true; do echo 1> /sys/block/XXX/bcache/set/unregister ; done & and results in the following oops, [ +0.000053] BUG: unable to handle kernel NULL pointer dereference at 0000000000000998 [ +0.000457] #PF error: [normal kernel read fault] [ +0.000464] PGD 800000003ca9d067 P4D 800000003ca9d067 PUD 3ca9c067 PMD 0 [ +0.000388] Oops: 0000 [#1] SMP PTI [ +0.000269] CPU: 1 PID: 3266 Comm: bash Not tainted 5.0.0+ #6 [ +0.000346] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014 [ +0.000472] RIP: 0010:register_bcache+0x1829/0x1990 [bcache] [ +0.000344] Code: b0 48 83 e8 50 48 81 fa e0 e1 10 c0 0f 84 a9 00 00 00 48 89 c6 48 89 ca 0f b7 ba 54 04 00 00 4c 8b 82 60 0c 00 00 85 ff 74 2f <49> 3b a8 98 09 00 00 74 4e 44 8d 47 ff 31 ff 49 c1 e0 03 eb 0d [ +0.000839] RSP: 0018:ffff92ee804cbd88 EFLAGS: 00010202 [ +0.000328] RAX: ffffffffc010e190 RBX: ffff918b5c6b5000 RCX: ffff918b7d8e0000 [ +0.000399] RDX: ffff918b7d8e0000 RSI: ffffffffc010e190 RDI: 0000000000000001 [ +0.000398] RBP: ffff918b7d318340 R08: 0000000000000000 R09: ffffffffb9bd2d7a [ +0.000385] R10: ffff918b7eb253c0 R11: ffffb95980f51200 R12: ffffffffc010e1a0 [ +0.000411] R13: fffffffffffffff2 R14: 000000000000000b R15: ffff918b7e232620 [ +0.000384] FS: 00007f955bec2740(0000) GS:ffff918b7eb00000(0000) knlGS:0000000000000000 [ +0.000420] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000801] CR2: 0000000000000998 CR3: 000000003cad6000 CR4: 00000000001406e0 [ +0.000837] Call Trace: [ +0.000682] ? _cond_resched+0x10/0x20 [ +0.000691] ? __kmalloc+0x131/0x1b0 [ +0.000710] kernfs_fop_write+0xfa/0x170 [ +0.000733] __vfs_write+0x2e/0x190 [ +0.000688] ? inode_security+0x10/0x30 [ +0.000698] ? selinux_file_permission+0xd2/0x120 [ +0.000752] ? security_file_permission+0x2b/0x100 [ +0.000753] vfs_write+0xa8/0x1a0 [ +0.000676] ksys_write+0x4d/0xb0 [ +0.000699] do_syscall_64+0x3a/0xf0 [ +0.000692] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Liang Chen Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 2a9e7fc4981125c865462fca25910807ebdbd99a Author: Slava Pestov Date: Thu Jun 19 15:05:59 2014 -0700 bcache: fix memory corruption in init error path commit c9a78332b42cbdcdd386a95192a716b67d1711a4 upstream. If register_cache_set() failed, we would touch ca->set after it had already been freed. Also, fix an assertion to catch this. Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit cea43f43751b1e6e9d034c629079d1836f3ca82d Author: Miklos Szeredi Date: Mon May 27 11:42:07 2019 +0200 fuse: fallocate: fix return with locked inode commit 35d6fcbb7c3e296a52136347346a698a35af3fda upstream. Do the proper cleanup in case the size check fails. Tested with xfstests:generic/228 Reported-by: kbuild test robot Reported-by: Dan Carpenter Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate") Cc: Liu Bo Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit e09925b72cc58decfc28f8cf183a24198fba4864 Author: Liu Bo Date: Thu Apr 18 04:04:41 2019 +0800 fuse: honor RLIMIT_FSIZE in fuse_file_fallocate commit 0cbade024ba501313da3b7e5dd2a188a6bc491b5 upstream. fstests generic/228 reported this failure that fuse fallocate does not honor what 'ulimit -f' has set. This adds the necessary inode_newsize_ok() check. Signed-off-by: Liu Bo Fixes: 05ba1f082300 ("fuse: add FALLOCATE operation") Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit fe629761087718c69d593887c80964f70df4d0dd Author: Miklos Szeredi Date: Wed Apr 24 17:05:06 2019 +0200 fuse: fix writepages on 32bit commit 9de5be06d0a89ca97b5ab902694d42dfd2bb77d2 upstream. Writepage requests were cropped to i_size & 0xffffffff, which meant that mmaped writes to any file larger than 4G might be silently discarded. Fix by storing the file size in a properly sized variable (loff_t instead of size_t). Reported-by: Antonio SJ Musumeci Fixes: 6eaf4782eb09 ("fuse: writepages: crop secondary requests") Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit 9b6f9e20a1221b5c970bf8e7b1646a07bd02f9ae Author: Takashi Iwai Date: Wed Apr 24 13:00:03 2019 +0200 ALSA: usb-audio: Handle the error from snd_usb_mixer_apply_create_quirk() commit 328e9f6973be2ee67862cb17bf6c0c5c5918cd72 upstream. The error from snd_usb_mixer_apply_create_quirk() is ignored in the current usb-audio driver code, which will continue the probing even after the error. Let's take it more serious. Fixes: 7b1eda223deb ("ALSA: usb-mixer: factor out quirks") Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 3d8da4b0b39a343829aa3b6e4887a82f1821de23 Author: Peter Zijlstra Date: Wed Apr 24 09:19:24 2019 +0200 x86/uaccess: Dont leak the AC flag into __put_user() argument evaluation commit 6ae865615fc43d014da2fd1f1bba7e81ee622d1b upstream. The __put_user() macro evaluates it's @ptr argument inside the __uaccess_begin() / __uaccess_end() region. While this would normally not be expected to be an issue, an UBSAN bug (it ignored -fwrapv, fixed in GCC 8+) would transform the @ptr evaluation for: drivers/gpu/drm/i915/i915_gem_execbuffer.c: if (unlikely(__put_user(offset, &urelocs[r-stack].presumed_offset))) { into a signed-overflow-UB check and trigger the objtool AC validation. Finish this commit: 2a418cf3f5f1 ("x86/uaccess: Don't leak the AC flag into __put_user() value evaluation") and explicitly evaluate all 3 arguments early. Reported-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Acked-by: Randy Dunlap # build-tested Acked-by: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: luto@kernel.org Fixes: 2a418cf3f5f1 ("x86/uaccess: Don't leak the AC flag into __put_user() value evaluation") Link: http://lkml.kernel.org/r/20190424072208.695962771@infradead.org Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c241753cac92a58f69c62110620f773e11c9f64b Author: Sebastian Andrzej Siewior Date: Wed Apr 24 10:52:53 2019 +0200 smpboot: Place the __percpu annotation correctly commit d4645d30b50d1691c26ff0f8fa4e718b08f8d3bb upstream. The test robot reported a wrong assignment of a per-CPU variable which it detected by using sparse and sent a report. The assignment itself is correct. The annotation for sparse was wrong and hence the report. The first pointer is a "normal" pointer and points to the per-CPU memory area. That means that the __percpu annotation has to be moved. Move the __percpu annotation to pointer which points to the per-CPU area. This change affects only the sparse tool (and is ignored by the compiler). Reported-by: kbuild test robot Signed-off-by: Sebastian Andrzej Siewior Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: f97f8f06a49fe ("smpboot: Provide infrastructure for percpu hotplug threads") Link: http://lkml.kernel.org/r/20190424085253.12178-1-bigeasy@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 00fb8842916ae985a8b9f297b977eddede9df778 Author: James Prestwood Date: Mon Jan 7 13:32:48 2019 -0800 PCI: Mark Atheros AR9462 to avoid bus reset commit 6afb7e26978da5e86e57e540fdce65c8b04f398a upstream. When using PCI passthrough with this device, the host machine locks up completely when starting the VM, requiring a hard reboot. Add a quirk to avoid bus resets on this device. Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset") Link: https://lore.kernel.org/linux-pci/20190107213248.3034-1-james.prestwood@linux.intel.com Signed-off-by: James Prestwood Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit 2ffeae7e76adceb25093fb45ec511c9e153cd4b8 Author: Dan Carpenter Date: Mon Apr 8 05:52:38 2019 -0400 media: pvrusb2: Prevent a buffer overflow commit c1ced46c7b49ad7bc064e68d966e0ad303f917fb upstream. The ctrl_check_input() function is called from pvr2_ctrl_range_check(). It's supposed to validate user supplied input and return true or false depending on whether the input is valid or not. The problem is that negative shifts or shifts greater than 31 are undefined in C. In practice with GCC they result in shift wrapping so this function returns true for some inputs which are not valid and this could result in a buffer overflow: drivers/media/usb/pvrusb2/pvrusb2-ctrl.c:205 pvr2_ctrl_get_valname() warn: uncapped user index 'names[val]' The cptr->hdw->input_allowed_mask mask is configured in pvr2_hdw_create() and the highest valid bit is BIT(4). Fixes: 7fb20fa38caa ("V4L/DVB (7299): pvrusb2: Improve logic which handles input choice availability") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 1903a2f50150df2878aeeb501aaaf1d8caeadeab Author: Janusz Krzysztofik Date: Sun Mar 24 20:21:12 2019 -0400 media: ov6650: Fix sensor possibly not detected on probe commit 933c1320847f5ed6b61a7d10f0a948aa98ccd7b0 upstream. After removal of clock_start() from before soc_camera_init_i2c() in soc_camera_probe() by commit 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") introduced in v3.11, the ov6650 driver could no longer probe the sensor successfully because its clock was no longer turned on in advance. The issue was initially worked around by adding that missing clock_start() equivalent to OMAP1 camera interface driver - the only user of this sensor - but a propoer fix should be rather implemented in the sensor driver code itself. Fix the issue by inserting a delay between the clock is turned on and the sensor I2C registers are read for the first time. Tested on Amstrad Delta with now out of tree but still locally maintained omap1_camera host driver. Fixes: 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 2954ef4859feb37fd568a36e09cf93032299f4a1 Author: Julia Lawall Date: Sat Feb 23 14:20:34 2019 +0100 powerpc/83xx: Add missing of_node_put() after of_device_is_available() commit 4df2cb633b5b22ba152511f1a55e718efca6c0d9 upstream. Add an of_node_put() when a tested device node is not available. Fixes: c026c98739c7e ("powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers") Signed-off-by: Julia Lawall Reviewed-by: Mukesh Ojha Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit a43eca8aa889570f24bf48f87a719000726d6858 Author: Kees Cook Date: Mon Apr 8 10:13:44 2019 -0700 selftests/ipc: Fix msgque compiler warnings commit a147faa96f832f76e772b1e448e94ea84c774081 upstream. This fixes the various compiler warnings when building the msgque selftest. The primary change is using sys/msg.h instead of linux/msg.h directly to gain the API declarations. Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test") Signed-off-by: Kees Cook Signed-off-by: Shuah Khan [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 49aaa35a9699bf49bcfa72dccfd8c36f904bf23c Author: Eric Biggers Date: Tue Apr 9 23:46:31 2019 -0700 crypto: arm/aes-neonbs - don't access already-freed walk.iv commit 767f015ea0b7ab9d60432ff6cd06b664fd71f50f upstream. If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. arm32 xts-aes-neonbs doesn't set an alignmask, so currently it isn't affected by this despite unconditionally accessing walk.iv. However this is more subtle than desired, and it was actually broken prior to the alignmask being removed by commit cc477bf64573 ("crypto: arm/aes - replace bit-sliced OpenSSL NEON code"). Thus, update xts-aes-neonbs to start checking the return value of skcipher_walk_virt(). Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit db8028988b418caecb05cd63d1ef43d8133b4bd4 Author: Eric Biggers Date: Tue Apr 9 23:46:30 2019 -0700 crypto: salsa20 - don't access already-freed walk.iv commit edaf28e996af69222b2cb40455dbb5459c2b875a upstream. If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. salsa20-generic doesn't set an alignmask, so currently it isn't affected by this despite unconditionally accessing walk.iv. However this is more subtle than desired, and it was actually broken prior to the alignmask being removed by commit b62b3db76f73 ("crypto: salsa20-generic - cleanup and convert to skcipher API"). Since salsa20-generic does not update the IV and does not need any IV alignment, update it to use req->iv instead of walk.iv. Fixes: 2407d60872dd ("[CRYPTO] salsa20: Salsa20 stream cipher") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e2af245193d86f0ab74f44e76add875b5f812a14 Author: Colin Ian King Date: Sat Mar 30 00:17:12 2019 +0000 platform/x86: alienware-wmi: fix kfree on potentially uninitialized pointer commit 98e2630284ab741804bd0713e932e725466f2f84 upstream. Currently the kfree of output.pointer can be potentially freeing an uninitalized pointer in the case where out_data is NULL. Fix this by reworking the case where out_data is not-null to perform the ACPI status check and also the kfree of outpoint.pointer in one block and hence ensuring the pointer is only freed when it has been used. Also replace the if (ptr != NULL) idiom with just if (ptr). Fixes: ff0e9f26288d ("platform/x86: alienware-wmi: Correct a memory leak") Signed-off-by: Colin Ian King Signed-off-by: Darren Hart (VMware) [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit e2cb920d34789a825299725a643fe31aebcea359 Author: Colin Ian King Date: Sat Apr 13 17:00:26 2019 +0100 RDMA/cxgb4: Fix null pointer dereference on alloc_skb failure commit a6d2a5a92e67d151c98886babdc86d530d27111c upstream. Currently if alloc_skb fails to allocate the skb a null skb is passed to t4_set_arp_err_handler and this ends up dereferencing the null skb. Avoid the NULL pointer dereference by checking for a NULL skb and returning early. Addresses-Coverity: ("Dereference null return") Fixes: b38a0ad8ec11 ("RDMA/cxgb4: Set arp error handler for PASS_ACCEPT_RPL messages") Signed-off-by: Colin Ian King Acked-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit e4ce563ab1ba40caada77ce88b723102d82c23b9 Author: Guenter Roeck Date: Fri Apr 5 08:53:08 2019 -0700 hwmon: (vt1211) Use request_muxed_region for Super-IO accesses commit 14b97ba5c20056102b3dd22696bf17b057e60976 upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: 2219cd81a6cd ("hwmon/vt1211: Add probing of alternate config index port") Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 803a857aab4714009703cc5e5a48603c4881a3c6 Author: Guenter Roeck Date: Fri Apr 5 08:44:41 2019 -0700 hwmon: (w83627hf) Use request_muxed_region for Super-IO accesses commit e95fd518d05bfc087da6fcdea4900a57cfb083bd upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: b72656dbc491 ("hwmon: (w83627hf) Stop using globals for I/O port numbers") Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit be8d00bf3cb38bbdd6fe103a298deb4d58bb8d76 Author: Guenter Roeck Date: Thu Apr 4 11:28:37 2019 -0700 hwmon: (smsc47m1) Use request_muxed_region for Super-IO accesses commit d6410408ad2a798c4cc685252c1baa713be0ad69 upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: 8d5d45fb1468 ("I2C: Move hwmon drivers (2/3)") Reported-by: Kefeng Wang Reported-by: John Garry Cc: John Garry Acked-by: John Garry Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit a9691f376d8800cdebc7a1bf9a492292caafd518 Author: Guenter Roeck Date: Thu Apr 4 11:22:42 2019 -0700 hwmon: (smsc47b397) Use request_muxed_region for Super-IO accesses commit 8c0826756744c0ac1df600a5e4cca1a341b13101 upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: 8d5d45fb1468 ("I2C: Move hwmon drivers (2/3)") Reported-by: Kefeng Wang Reported-by: John Garry Cc: John Garry Acked-by: John Garry Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit a5a33fa9f9ec8ac5e8e18576682d97be8241c707 Author: Guenter Roeck Date: Thu Apr 4 11:16:20 2019 -0700 hwmon: (pc87427) Use request_muxed_region for Super-IO accesses commit 755a9b0f8aaa5639ba5671ca50080852babb89ce upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: ba224e2c4f0a7 ("hwmon: New PC87427 hardware monitoring driver") Reported-by: Kefeng Wang Reported-by: John Garry Cc: John Garry Acked-by: John Garry Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 26178a34b854ae8e4e196d38de3118c9bee732b2 Author: Guenter Roeck Date: Thu Apr 4 10:52:43 2019 -0700 hwmon: (f71805f) Use request_muxed_region for Super-IO accesses commit 73e6ff71a7ea924fb7121d576a2d41e3be3fc6b5 upstream. Super-IO accesses may fail on a system with no or unmapped LPC bus. Unable to handle kernel paging request at virtual address ffffffbffee0002e pgd = ffffffc1d68d4000 [ffffffbffee0002e] *pgd=0000000000000000, *pud=0000000000000000 Internal error: Oops: 94000046 [#1] PREEMPT SMP Modules linked in: f71805f(+) hwmon CPU: 3 PID: 1659 Comm: insmod Not tainted 4.5.0+ #88 Hardware name: linux,dummy-virt (DT) task: ffffffc1f6665400 ti: ffffffc1d6418000 task.ti: ffffffc1d6418000 PC is at f71805f_find+0x6c/0x358 [f71805f] Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: e53004e20a58e ("hwmon: New f71805f driver") Reported-by: Kefeng Wang Reported-by: John Garry Cc: John Garry Acked-by: John Garry Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 3360c360345c0d13f2239d6cf926446b80a029b6 Author: YueHaibing Date: Tue Jan 29 16:03:24 2019 +0800 ARM: pxa: ssp: Fix "WARNING: invalid free of devm_ allocated data" commit 9ee8578d953023cc57e7e736ae48502c707c0210 upstream. Since commit 1c459de1e645 ("ARM: pxa: ssp: use devm_ functions") kfree, iounmap, clk_put etc are not needed anymore in remove path. Fixes: 1c459de1e645 ("ARM: pxa: ssp: use devm_ functions") Signed-off-by: YueHaibing [ commit message spelling fix ] Signed-off-by: Robert Jarzmik Signed-off-by: Ben Hutchings commit c4bea4445fa1ee3c503c1cf2e1dcfa4e19f6000c Author: Vincenzo Frascino Date: Mon Apr 1 12:30:14 2019 +0100 arm64: compat: Reduce address limit commit d263119387de9975d2acba1dfd3392f7c5979c18 upstream. Currently, compat tasks running on arm64 can allocate memory up to TASK_SIZE_32 (UL(0x100000000)). This means that mmap() allocations, if we treat them as returning an array, are not compliant with the sections 6.5.8 of the C standard (C99) which states that: "If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P". Redefine TASK_SIZE_32 to address the issue. Cc: Catalin Marinas Cc: Will Deacon Cc: Jann Horn Reported-by: Jann Horn Signed-off-by: Vincenzo Frascino [will: fixed typo in comment] Signed-off-by: Will Deacon [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit d074bff84ed8dff76be32a1d2a4a4c2e48ec291b Author: Bart Van Assche Date: Thu Apr 4 12:44:46 2019 -0700 scsi: qla2xxx: Unregister chrdev if module initialization fails commit c794d24ec9eb6658909955772e70f34bef5b5b91 upstream. If module initialization fails after the character device has been registered, unregister the character device. Additionally, avoid duplicating error path code. Cc: Himanshu Madhani Cc: Giridhar Malavali Fixes: 6a03b4cd78f3 ("[SCSI] qla2xxx: Add char device to increase driver use count") # v2.6.35. Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 09401a34c11a2f01e5c76dd1733d563cd5eeeaf7 Author: Eric Biggers Date: Sun Mar 31 13:04:13 2019 -0700 crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest() commit dec3d0b1071a0f3194e66a83d26ecf4aa8c5910e upstream. The ->digest() method of crct10dif-pclmul reads the current CRC value from the shash_desc context. But this value is uninitialized, causing crypto_shash_digest() to compute the wrong result. Fix it. Probably this wasn't noticed before because lib/crc-t10dif.c only uses crypto_shash_update(), not crypto_shash_digest(). Likewise, crypto_shash_digest() is not yet tested by the crypto self-tests because those only test the ahash API which only uses shash init/update/final. Fixes: 0b95a7f85718 ("crypto: crct10dif - Glue code to cast accelerated CRCT10DIF assembly as a crypto transform") Cc: Tim Chen Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 00c649ff2e87add15d293ca6c52180b215b8a4bd Author: Eric Biggers Date: Sun Mar 31 13:04:12 2019 -0700 crypto: crct10dif-generic - fix use via crypto_shash_digest() commit 307508d1072979f4435416f87936f87eaeb82054 upstream. The ->digest() method of crct10dif-generic reads the current CRC value from the shash_desc context. But this value is uninitialized, causing crypto_shash_digest() to compute the wrong result. Fix it. Probably this wasn't noticed before because lib/crc-t10dif.c only uses crypto_shash_update(), not crypto_shash_digest(). Likewise, crypto_shash_digest() is not yet tested by the crypto self-tests because those only test the ahash API which only uses shash init/update/final. This bug was detected by my patches that improve testmgr to fuzz algorithms against their generic implementation. Fixes: 2d31e518a428 ("crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework") Cc: Tim Chen Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 4b0b903e98c56574420b6c460aefbbf66f3ce31c Author: Jiufei Xue Date: Sat Apr 6 18:57:40 2019 -0400 jbd2: check superblock mapped prior to committing commit 742b06b5628f2cd23cb51a034cb54dc33c6162c5 upstream. We hit a BUG at fs/buffer.c:3057 if we detached the nbd device before unmounting ext4 filesystem. The typical chain of events leading to the BUG: jbd2_write_superblock submit_bh submit_bh_wbc BUG_ON(!buffer_mapped(bh)); The block device is removed and all the pages are invalidated. JBD2 was trying to write journal superblock to the block device which is no longer present. Fix this by checking the journal superblock's buffer head prior to submitting. Reported-by: Eric Ren Signed-off-by: Jiufei Xue Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 57b9ed53b9ade4b1bb4950eafd21ccb0fb46a6db Author: Stefan Mätje Date: Fri Mar 29 18:07:35 2019 +0100 PCI: Work around Pericom PCIe-to-PCI bridge Retrain Link erratum commit 4ec73791a64bab25cabf16a6067ee478692e506d upstream. Due to an erratum in some Pericom PCIe-to-PCI bridges in reverse mode (conventional PCI on primary side, PCIe on downstream side), the Retrain Link bit needs to be cleared manually to allow the link training to complete successfully. If it is not cleared manually, the link training is continuously restarted and no devices below the PCI-to-PCIe bridge can be accessed. That means drivers for devices below the bridge will be loaded but won't work and may even crash because the driver is only reading 0xffff. See the Pericom Errata Sheet PI7C9X111SLB_errata_rev1.2_102711.pdf for details. Devices known as affected so far are: PI7C9X110, PI7C9X111SL, PI7C9X130. Add a new flag, clear_retrain_link, in struct pci_dev. Quirks for affected devices set this bit. Note that pcie_retrain_link() lives in aspm.c because that's currently the only place we use it, but this erratum is not specific to ASPM, and we may retrain links for other reasons in the future. Signed-off-by: Stefan Mätje [bhelgaas: apply regardless of CONFIG_PCIEASPM] Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko [bwh: Backported to 3.16: - Use dev_info() instead of pci_info() - Adjust context] Signed-off-by: Ben Hutchings commit 9a070ca281b04d1490eac3f2d62cde20855177ac Author: Stefan Mätje Date: Fri Mar 29 18:07:34 2019 +0100 PCI: Factor out pcie_retrain_link() function commit 86fa6a344209d9414ea962b1f1ac6ade9dd7563a upstream. Factor out pcie_retrain_link() to use for Pericom Retrain Link quirk. No functional change intended. Signed-off-by: Stefan Mätje Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Ben Hutchings commit 0ad8535265db8735da0ad91920a9946816694a66 Author: YueHaibing Date: Wed Apr 3 15:47:59 2019 +0800 ehea: Fix a copy-paste err in ehea_init_port_res commit c8f191282f819ab4e9b47b22a65c6c29734cefce upstream. pr->tx_bytes should be assigned to tx_bytes other than rx_bytes. Reported-by: Hulk Robot Fixes: ce45b873028f ("ehea: Fixing statistics") Signed-off-by: YueHaibing Reviewed-by: Mukesh Ojha Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7fa23a38ba5eac0c5e33685d8fbde0a8dc00497c Author: Wolfram Sang Date: Wed Apr 3 17:19:52 2019 +0200 rtc: don't reference bogus function pointer in kdoc commit c48cadf5bf4becefcd0751b97995d2350aa9bb57 upstream. The mentioned function pointer is long gone since early 2011. Remove the reference in the comment and reword it slightly. Fixes: 51ba60c5bb3b ("RTC: Cleanup rtc_class_ops->update_irq_enable()") Signed-off-by: Wolfram Sang Signed-off-by: Alexandre Belloni Signed-off-by: Ben Hutchings commit 0166dc4aae7eb4c2faf709a989260214edc9b388 Author: Andrew Vasquez Date: Tue Apr 2 14:24:25 2019 -0700 scsi: qla2xxx: Fix incorrect region-size setting in optrom SYSFS routines commit 5cbdae10bf11f96e30b4d14de7b08c8b490e903c upstream. Commit e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code") incorrectly set 'optrom_region_size' to 'start+size', which can overflow option-rom boundaries when 'start' is non-zero. Continue setting optrom_region_size to the proper adjusted value of 'size'. Fixes: e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code") Signed-off-by: Andrew Vasquez Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit b4795ca5f5d01433dbb4be03179e4605178bc12a Author: Noralf Trønnes Date: Tue Mar 26 18:55:32 2019 +0100 drm/fb-helper: dpms_legacy(): Only set on connectors in use commit 65a102f68005891d7f39354cfd79099908df6d51 upstream. For each enabled crtc the functions sets dpms on all registered connectors. Limit this to only doing it once and on the connectors actually in use. Signed-off-by: Noralf Trønnes Fixes: 023eb571a1d0 ("drm: correctly update connector DPMS status in drm_fb_helper") Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190326175546.18126-3-noralf@tronnes.org [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 49187c9dbc34a6392b3fbbca3cb009f077d62d63 Author: Gustavo A. R. Silva Date: Fri Mar 29 10:27:26 2019 -0500 cxgb3/l2t: Fix undefined behaviour commit 76497732932f15e7323dc805e8ea8dc11bb587cf upstream. The use of zero-sized array causes undefined behaviour when it is not the last member in a structure. As it happens to be in this case. Also, the current code makes use of a language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as this one is a flexible array member, introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last. Which is beneficial to cultivate a high-quality code. Fixes: e48f129c2f20 ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference") Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1e073f27b47c6be13940c984c461d08129aeb7f2 Author: Tetsuo Handa Date: Sun Mar 17 14:02:31 2019 +0900 kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice. commit c03a0fd0b609e2f5c669c2b7f27c8e1928e9196e upstream. syzbot is hitting use-after-free bug in uinput module [1]. This is because kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0563c6c49 ("Kobject: auto-cleanup on final unref") after memory allocation fault injection made kobject_uevent(KOBJ_REMOVE) from device_del() from input_unregister_device() fail, while uinput_destroy_device() is expecting that kobject_uevent(KOBJ_REMOVE) is not called after device_del() from input_unregister_device() completed. That commit intended to catch cases where nobody even attempted to send "remove" uevents. But there is no guarantee that an event will ultimately be sent. We are at the point of no return as far as the rest of the kernel is concerned; there are no repeats or do-overs. Also, it is not clear whether some subsystem depends on that commit. If no subsystem depends on that commit, it will be better to remove the state_{add,remove}_uevent_sent logic. But we don't want to risk a regression (in a patch which will be backported) by trying to remove that logic. Therefore, as a first step, let's avoid the use-after-free bug by making sure that kobject_uevent(KOBJ_REMOVE) won't be triggered twice. [1] https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362d Reported-by: syzbot Analyzed-by: Dmitry Torokhov Fixes: 0f4dafc0563c6c49 ("Kobject: auto-cleanup on final unref") Cc: Kay Sievers Signed-off-by: Tetsuo Handa Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit ec0c0a0e5cd3be7151bf69eb2a551b71b691978a Author: Dan Carpenter Date: Tue Mar 26 01:12:07 2019 -0400 media: wl128x: prevent two potential buffer overflows commit 9c2ccc324b3a6cbc865ab8b3e1a09e93d3c8ade9 upstream. Smatch marks skb->data as untrusted so it warns that "evt_hdr->dlen" can copy up to 255 bytes and we only have room for two bytes. Even if this comes from the firmware and we trust it, the new policy generally is just to fix it as kernel hardenning. I can't test this code so I tried to be very conservative. I considered not allowing "evt_hdr->dlen == 1" because it doesn't initialize the whole variable but in the end I decided to allow it and manually initialized "asic_id" and "asic_ver" to zero. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 393297320399540d2aa364bb331c90a736e0adc1 Author: Arnd Bergmann Date: Fri Mar 22 10:34:22 2019 -0400 media: davinci-isif: avoid uninitialized variable use commit 0e633f97162c1c74c68e2eb20bbd9259dce87cd9 upstream. clang warns about a possible variable use that gcc never complained about: drivers/media/platform/davinci/isif.c:982:32: error: variable 'frame_size' is uninitialized when used here [-Werror,-Wuninitialized] dm365_vpss_set_pg_frame_size(frame_size); ^~~~~~~~~~ drivers/media/platform/davinci/isif.c:887:2: note: variable 'frame_size' is declared here struct vpss_pg_frame_size frame_size; ^ 1 error generated. There is no initialization for this variable at all, and there has never been one in the mainline kernel, so we really should not put that stack data into an mmio register. On the other hand, I suspect that gcc checks the condition more closely and notices that the global isif_cfg.bayer.config_params.test_pat_gen flag is initialized to zero and never written to from any code path, so anything depending on it can be eliminated. To shut up the clang warning, just remove the dead code manually, it has probably never been used because any attempt to do so would have resulted in undefined behavior. Fixes: 63e3ab142fa3 ("V4L/DVB: V4L - vpfe capture - source for ISIF driver on DM365") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Acked-by: Lad, Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 8a6dad8719092ba7d8838dde2fb8f41c7c8a4432 Author: Sergei Trofimovich Date: Sun Mar 10 21:24:15 2019 +0000 tty/vt: fix write/write race in ioctl(KDSKBSENT) handler commit 46ca3f735f345c9d87383dd3a09fa5d43870770e upstream. The bug manifests as an attempt to access deallocated memory: BUG: unable to handle kernel paging request at ffff9c8735448000 #PF error: [PROT] [WRITE] PGD 288a05067 P4D 288a05067 PUD 288a07067 PMD 7f60c2063 PTE 80000007f5448161 Oops: 0003 [#1] PREEMPT SMP CPU: 6 PID: 388 Comm: loadkeys Tainted: G C 5.0.0-rc6-00153-g5ded5871030e #91 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M-D3H, BIOS F12 11/14/2013 RIP: 0010:__memmove+0x81/0x1a0 Code: 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4 48 83 c2 20 e9 a2 00 00 00 66 90 48 89 d1 4c 8b 5c 16 f8 4c 8d 54 17 f8 48 c1 e9 03 48 a5 4d 89 1a e9 0c 01 00 00 0f 1f 40 00 48 89 d1 4c 8b 1e 49 RSP: 0018:ffffa1b9002d7d08 EFLAGS: 00010203 RAX: ffff9c873541af43 RBX: ffff9c873541af43 RCX: 00000c6f105cd6bf RDX: 0000637882e986b6 RSI: ffff9c8735447ffb RDI: ffff9c8735447ffb RBP: ffff9c8739cd3800 R08: ffff9c873b802f00 R09: 00000000fffff73b R10: ffffffffb82b35f1 R11: 00505b1b004d5b1b R12: 0000000000000000 R13: ffff9c873541af3d R14: 000000000000000b R15: 000000000000000c FS: 00007f450c390580(0000) GS:ffff9c873f180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9c8735448000 CR3: 00000007e213c002 CR4: 00000000000606e0 Call Trace: vt_do_kdgkb_ioctl+0x34d/0x440 vt_ioctl+0xba3/0x1190 ? __bpf_prog_run32+0x39/0x60 ? mem_cgroup_commit_charge+0x7b/0x4e0 tty_ioctl+0x23f/0x920 ? preempt_count_sub+0x98/0xe0 ? __seccomp_filter+0x67/0x600 do_vfs_ioctl+0xa2/0x6a0 ? syscall_trace_enter+0x192/0x2d0 ksys_ioctl+0x3a/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x54/0xe0 entry_SYSCALL_64_after_hwframe+0x49/0xbe The bug manifests on systemd systems with multiple vtcon devices: # cat /sys/devices/virtual/vtconsole/vtcon0/name (S) dummy device # cat /sys/devices/virtual/vtconsole/vtcon1/name (M) frame buffer device There systemd runs 'loadkeys' tool in tapallel for each vtcon instance. This causes two parallel ioctl(KDSKBSENT) calls to race into adding the same entry into 'func_table' array at: drivers/tty/vt/keyboard.c:vt_do_kdgkb_ioctl() The function has no locking around writes to 'func_table'. The simplest reproducer is to have initrams with the following init on a 8-CPU machine x86_64: #!/bin/sh loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & wait The change adds lock on write path only. Reads are still racy. CC: Greg Kroah-Hartman CC: Jiri Slaby Link: https://lkml.org/lkml/2019/2/17/256 Signed-off-by: Sergei Trofimovich Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c59828dd94fa2269edad8594d8335331c984db12 Author: Tony Lindgren Date: Thu Mar 21 11:00:21 2019 -0700 ARM: OMAP2+: Fix potentially uninitialized return value for _setup_reset() commit 7f0d078667a494466991aa7133f49594f32ff6a2 upstream. Commit 747834ab8347 ("ARM: OMAP2+: hwmod: revise hardreset behavior") made the call to _enable() conditional based on no oh->rst_lines_cnt. This caused the return value to be potentially uninitialized. Curiously we see no compiler warnings for this, probably as this gets inlined. We call _setup_reset() from _setup() and only _setup_postsetup() if the return value is zero. Currently the return value can be uninitialized for cases where oh->rst_lines_cnt is set and HWMOD_INIT_NO_RESET is not set. Fixes: 747834ab8347 ("ARM: OMAP2+: hwmod: revise hardreset behavior") Cc: Paul Walmsley Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Ben Hutchings commit 628e3360335edae69ef52484439bc7a1e985415d Author: Arnd Bergmann Date: Fri Mar 22 15:25:03 2019 +0100 scsi: qla4xxx: avoid freeing unallocated dma memory commit 608f729c31d4caf52216ea00d20092a80959256d upstream. Clang -Wuninitialized notices that on is_qla40XX we never allocate any DMA memory in get_fw_boot_info() but attempt to free it anyway: drivers/scsi/qla4xxx/ql4_os.c:5915:7: error: variable 'buf_dma' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (!(val & 0x07)) { ^~~~~~~~~~~~~ drivers/scsi/qla4xxx/ql4_os.c:5985:47: note: uninitialized use occurs here dma_free_coherent(&ha->pdev->dev, size, buf, buf_dma); ^~~~~~~ drivers/scsi/qla4xxx/ql4_os.c:5915:3: note: remove the 'if' if its condition is always true if (!(val & 0x07)) { ^~~~~~~~~~~~~~~~~~~ drivers/scsi/qla4xxx/ql4_os.c:5885:20: note: initialize the variable 'buf_dma' to silence this warning dma_addr_t buf_dma; ^ = 0 Skip the call to dma_free_coherent() here. Fixes: 2a991c215978 ("[SCSI] qla4xxx: Boot from SAN support for open-iscsi") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 7e00d631e596eed256e314e2d0a6cdce1ac7c2b9 Author: Christoph Vogtländer Date: Tue Mar 12 14:38:46 2019 +0530 pwm: tiehrpwm: Update shadow register for disabling PWMs commit b00ef53053191d3025c15e8041699f8c9d132daf upstream. It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register. This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired. Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs") Signed-off-by: Christoph Vogtländer [vigneshr@ti.com: Improve commit message] Signed-off-by: Vignesh Raghavendra Signed-off-by: Thierry Reding Signed-off-by: Ben Hutchings commit 811f5bba33330cb071bba3532ff6f81718b20af7 Author: Phong Hoang Date: Tue Mar 19 19:40:08 2019 +0900 pwm: Fix deadlock warning when removing PWM device commit 347ab9480313737c0f1aaa08e8f2e1a791235535 upstream. This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9 ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by: Phong Hoang [shimoda: revise the commit log and code] Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal") Signed-off-by: Yoshihiro Shimoda Tested-by: Hoan Nguyen An Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Ben Hutchings commit 17783b4d77badd1e031ad5a6385576a1fad6de00 Author: Dan Carpenter Date: Wed Mar 6 02:27:43 2019 -0500 media: wl128x: Fix an error code in fm_download_firmware() commit ef4bb63dc1f7213c08e13f6943c69cd27f69e4a3 upstream. We forgot to set "ret" on this error path. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 435d3ac023e76ae4b198b54b9d3ef8206aea30a2 Author: Stuart Menefy Date: Tue Feb 19 13:03:37 2019 +0000 ARM: dts: exynos: Fix interrupt for shared EINTs on Exynos5260 commit b7ed69d67ff0788d8463e599dd5dd1b45c701a7e upstream. Fix the interrupt information for the GPIO lines with a shared EINT interrupt. Fixes: 16d7ff2642e7 ("ARM: dts: add dts files for exynos5260 SoC") Signed-off-by: Stuart Menefy Signed-off-by: Krzysztof Kozlowski [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8988db8f0383e9a29d65fae52b8d3ef64790fa26 Author: Dan Carpenter Date: Fri Feb 22 01:37:02 2019 -0500 media: cx18: update *pos correctly in cx18_read_pos() commit 7afb0df554292dca7568446f619965fb8153085d upstream. We should be updating *pos. The current code is a no-op. Fixes: 1c1e45d17b66 ("V4L/DVB (7786): cx18: new driver for the Conexant CX23418 MPEG encoder chip") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit e2f44eded64e65aaa1d4faa09476bf24a56a64fb Author: Dan Carpenter Date: Fri Feb 22 01:36:41 2019 -0500 media: ivtv: update *pos correctly in ivtv_read_pos() commit f8e579f3ca0973daef263f513da5edff520a6c0d upstream. We had intended to update *pos, but the current code is a no-op. Fixes: 1a0adaf37c30 ("V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit fabacefdb00e3841163da749636d9b210dd362ae Author: Geert Uytterhoeven Date: Tue Mar 12 19:45:13 2019 +0100 spi: rspi: Fix sequencer reset during initialization commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 upstream. While the sequencer is reset after each SPI message since commit 880c6d114fd79a69 ("spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"), it was never reset for the first message, thus relying on reset state or bootloader settings. Fix this by initializing it explicitly during configuration. Fixes: 0b2182ddac4b8837 ("spi: add support for Renesas RSPI") Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 2987155e8f5e741c57a7125619731d9666771cd6 Author: Geert Uytterhoeven Date: Tue Mar 12 19:43:31 2019 +0100 spi: rspi: Fix register initialization while runtime-suspended commit 42bdaaece121b3bb50fd4d1203d6d0170279f9fa upstream. The Renesas RSPI/QSPI driver performs SPI controller register initialization in its spi_operations.setup() callback, without calling pm_runtime_get_sync() first, which may cause spurious failures. So far this went unnoticed, as this SPI controller is typically used with a single SPI NOR FLASH containing the boot loader: 1. If the device's module clock is still enabled (left enabled by the bootloader, and not yet disabled by the clk_disable_unused() late initcall), register initialization succeeds, 2. If the device's module clock is disabled, register writes don't seem to cause lock-ups or crashes. Data received in the first SPI message may be corrupted, though. Subsequent SPI messages seem to be OK. E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte and all later bytes. But until commit a2126b0a010905e5 ("mtd: spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not considered for FLASH identification. Fix this by moving all initialization from the .setup() to the .prepare_message() callback. The latter is always called after the device has been runtime-resumed by the SPI core. This also makes the driver follow the rule that .setup() must not change global driver state or register values, as that might break a transfer in progress. Fixes: 490c97747d5dc77d ("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm") Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown [bwh: Backported to 3.16: s/(controller|ctlr)/master/g] Signed-off-by: Ben Hutchings