- 21 Oct, 2019 27 commits
-
-
Yu Wang authored
BugLink: https://bugs.launchpad.net/bugs/1848589 [ Upstream commit 79c92ca4 ] 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. Cc: stable@vger.kernel.org Signed-off-by:
Yu Wang <yyuwang@codeaurora.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Arkadiusz Miskiewicz authored
BugLink: https://bugs.launchpad.net/bugs/1848589 [ Upstream commit 68506e9a ] When disassociation happens only numeric reason is printed in ieee80211_rx_mgmt_disassoc(). Add text variant, too. Signed-off-by:
Arkadiusz Miśkiewicz <arekm@maven.pl> Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1848589 This reverts commit ac12d565 in favor of its upstream stable version. Signed-off-by:
-
Shih-Yuan Lee (FourDollars) authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 7b485d17 upstream. The same fixup to enable laptop imic is needed for ASUS M9V with AD1986A codec like another HP machine. Signed-off-by:
Shih-Yuan Lee (FourDollars) <fourdollars@debian.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190920134052.GA8035@localhostSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 2757970f upstream. The node obtained from of_find_node_by_path() has to be unreferenced after the use, but we forgot it for the root node. Fixes: f0fba2ad ("ASoC: multi-component - ASoC Multi-Component Support") Cc: Timur Tabi <timur@kernel.org> Cc: Nicolin Chen <nicoleotsuka@gmail.com> Cc: Xiubo Li <Xiubo.Lee@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Signed-off-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Mao Wenan authored
BugLink: https://bugs.launchpad.net/bugs/1848589 After the commit c4e97b06cfdc ("net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock()."), it introduced null-ptr-deref in rds_tcp_kill_sock as below: BUG: KASAN: null-ptr-deref on address 0000000000000020 Read of size 8 by task kworker/u16:10/910 CPU: 3 PID: 910 Comm: kworker/u16:10 Not tainted 4.4.178+ #3 Hardware name: linux,dummy-virt (DT) Workqueue: netns cleanup_net Call trace: [<ffffff90080abb50>] dump_backtrace+0x0/0x618 [<ffffff90080ac1a0>] show_stack+0x38/0x60 [<ffffff9008c42b78>] dump_stack+0x1a8/0x230 [<ffffff90085d469c>] kasan_report_error+0xc8c/0xfc0 [<ffffff90085d54a4>] kasan_report+0x94/0xd8 [<ffffff90085d1b28>] __asan_load8+0x88/0x150 [<ffffff9009c9cc2c>] rds_tcp_dev_event+0x734/0xb48 [<ffffff90081eacb0>] raw_notifier_call_chain+0x150/0x1e8 [<ffffff900973fec0>] call_netdevice_notifiers_info+0x90/0x110 [<ffffff9009764874>] netdev_run_todo+0x2f4/0xb08 [<ffffff9009796d34>] rtnl_unlock+0x2c/0x48 [<ffffff9009756484>] default_device_exit_batch+0x444/0x528 [<ffffff9009720498>] ops_exit_list+0x1c0/0x240 [<ffffff9009724a80>] cleanup_net+0x738/0xbf8 [<ffffff90081ca6cc>] process_one_work+0x96c/0x13e0 [<ffffff90081cf370>] worker_thread+0x7e0/0x1910 [<ffffff90081e7174>] kthread+0x304/0x390 [<ffffff9008094280>] ret_from_fork+0x10/0x50 If the first loop add the tc->t_sock = NULL to the tmp_list, 1). list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) then the second loop is to find connections to destroy, tc->t_sock might equal NULL, and tc->t_sock->sk happens null-ptr-deref. 2). list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) Fixes: c4e97b06cfdc ("net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().") Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
Gustavo A. R. Silva authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 5fc194ea upstream. Add missing break statement in order to prevent the code from falling through to case CRYPTO_ALG_TYPE_AHASH. Fixes: aeb4c132 ("crypto: talitos - Convert to new AEAD interface") Cc: stable@vger.kernel.org Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Tokunori Ikegami authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 37c673ad upstream. As reported by the OpenWRT team, write requests sometimes fail on some platforms. Currently to check the state chip_ready() is used correctly as described by the flash memory S29GL256P11TFI01 datasheet. Also chip_good() is used to check if the write is succeeded and it was implemented by the commit fb4a90bf ("[MTD] CFI-0002 - Improve error checking"). But actually the write failure is caused on some platforms and also it can be fixed by using chip_good() to check the state and retry instead. Also it seems that it is caused after repeated about 1,000 times to retry the write one word with the reset command. By using chip_good() to check the state to be done it can be reduced the retry with reset. It is depended on the actual flash chip behavior so the root cause is unknown. Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Reported-by:
Fabio Bettoni <fbettoni@gmail.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
Tokunori Ikegami <ikegami.t@gmail.com> [vigneshr@ti.com: Fix a checkpatch warning] Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 416dacb8 upstream. The syzbot fuzzer has reported a pair of problems in the hidraw_ioctl() function: slab-out-of-bounds read and use-after-free read. An example of the first: BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525 Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833 CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 strlen+0x79/0x90 lib/string.c:525 strlen include/linux/string.h:281 [inline] hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696 ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718 do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459829 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829 RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4 R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff The two problems have the same cause: hidraw_ioctl() fails to test whether the device has been removed. This patch adds the missing test. Reported-and-tested-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 5f924277 upstream. The syzbot fuzzer found a general protection fault in the HID subsystem: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069 Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00 RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000 RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25 R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004 R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048 FS: 00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline] usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707 usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234 hid_hw_power include/linux/hid.h:1038 [inline] hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282 chrdev_open+0x219/0x5c0 fs/char_dev.c:413 do_dentry_open+0x497/0x1040 fs/open.c:778 do_last fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 fs/namei.c:3533 do_filp_open+0x1a1/0x280 fs/namei.c:3563 do_sys_open+0x3c0/0x580 fs/open.c:1070 do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turns out the fault was caused by a bug in the HID Logitech driver, which violates the requirement that every pathway calling hid_hw_start() must also call hid_hw_stop(). This patch fixes the bug by making sure the requirement is met. Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com Signed-off-by:
-
Benjamin Tissoires authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 061232f0 upstream. Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove buffers allocated on the stack. [jkosina@suse.cz: fix up second usage of hid_hw_raw_request(), spotted by 0day build bot] Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 98375b86 upstream. The syzbot fuzzer provoked a general protection fault in the hid-prodikeys driver: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc5+ #28 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:pcmidi_submit_output_report drivers/hid/hid-prodikeys.c:300 [inline] RIP: 0010:pcmidi_set_operational drivers/hid/hid-prodikeys.c:558 [inline] RIP: 0010:pcmidi_snd_initialise drivers/hid/hid-prodikeys.c:686 [inline] RIP: 0010:pk_probe+0xb51/0xfd0 drivers/hid/hid-prodikeys.c:836 Code: 0f 85 50 04 00 00 48 8b 04 24 4c 89 7d 10 48 8b 58 08 e8 b2 53 e4 fc 48 8b 54 24 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 13 04 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b The problem is caused by the fact that pcmidi_get_output_report() will return an error if the HID device doesn't provide the right sort of output report, but pcmidi_set_operational() doesn't bother to check the return code and assumes the function call always succeeds. This patch adds the missing check and aborts the probe operation if necessary. Reported-and-tested-by: syzbot+1088533649dafa1c9004@syzkaller.appspotmail.com Signed-off-by:
-
Marcel Holtmann authored
BugLink: https://bugs.launchpad.net/bugs/1848589 [ Upstream commit 68d19d7d ] This reverts commit c49a8682. There are devices which require low connection intervals for usable operation including keyboards and mice. Forcing a static connection interval for these types of devices has an impact in latency and causes a regression. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1847969 Due to a race condition, some times the headers directory already exists when running the install-arch-headers rule. Make sure we do not fail in that case. Signed-off-by:
Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com> Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1847969 Add a fit_signed option and a script so we can build FIT images that will be eventually signed. Signed-off-by:
-
Shile Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1840043 Read /sys/fs/bcache/<uuid>/cacheN/priority_stats can take very long time with huge cache after long run. Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com> Tested-by:
Heitor Alves de Siqueira <halves@canonical.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> (backported from commit d55a4ae9) Signed-off-by:
-
Heitor Alves de Siqueira authored
BugLink: https://bugs.launchpad.net/bugs/1848236Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1847189 The Ubuntu Xenial backport of upstream commit 19b558db ("posix-timers: Protect posix clock array access against speculation") incorrectly dropped the NULL check on the .clock_getres function pointer. Readd the NULL check while still protecting against side-channel speculation attacks when indexing into the posix_clocks array to perform that NULL check. The NULL check protects against a denial of service (system crash) or possible arbitrary code execution that can be triggered by clock_gettime(10, 0), as pointed out by Vitaly Nikolenko. Fixes: eb4a3a43 ("posix-timers: Protect posix clock array access against speculation") Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1847118 When looking for a bit by number we make use of the cached result from the preceding lookup to speed up operation. Firstly we check if the requested pfn is within the cached zone and if not lookup the new zone. We then check if the offset for that pfn falls within the existing cached node. This happens regardless of whether the node is within the zone we are now scanning. With certain memory layouts it is possible for this to false trigger creating a temporary alias for the pfn to a different bit. This leads the hibernation code to free memory which it was never allocated with the expected fallout. Ensure the zone we are scanning matches the cached zone before considering the cached node. Deep thanks go to Andrea for many, many, many hours of hacking and testing that went into cornering this bug. Reported-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (backported from commit 39800d8fc4083cfe5c8f69333336bf03f9571070 linux-next) Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_NFC socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
Ori Nimron <orinimron123@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> CVE-2019-17056 (cherry picked from commit 3a359798) Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_ISDN socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_APPLETALK socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_IEEE802154 socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_AX25 socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Hui Peng authored
The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath6kl_usb` object according to endpoint descriptors read from the device side, as shown below in `ath6kl_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and `ath6kl_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref (CVE-2019-15098). Signed-off-by:Hui Peng <benquike@gmail.com> Reported-by:
Mathias Payer <mathias.payer@nebelwelt.net> Reviewed-by:
Kalle Valo <kvalo@codeaurora.org> CVE-2019-15098 (cherry picked from commit 39d170b3) Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1844155 arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value for compat tasks. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Reported-by:
Steve McIntyre <steve.mcintyre@arm.com> Tested-by:
Steve McIntyre <93sam@debian.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 24951465) Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Juerg Haefliger <juergh@canonical.com>
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1844155 The sigaltstack(2) system call fails with -ENOMEM if the new alternative signal stack is found to be smaller than SIGMINSTKSZ. On architectures such as arm64, where the native value for SIGMINSTKSZ is larger than the compat value, this can result in an unexpected error being reported to a compat task. See, for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904385 This patch fixes the problem by extending do_sigaltstack to take the minimum signal stack size as an additional parameter, allowing the native and compat system call entry code to pass in their respective values. COMPAT_SIGMINSTKSZ is just defined as SIGMINSTKSZ if it has not been defined by the architecture. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Reported-by:
-
- 01 Oct, 2019 13 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
Kleber Sacilotto de Souza authored
BugLink: https://bugs.launchpad.net/bugs/1846069 Properties: no-test-build Signed-off-by:
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by: -
Khalid Elmously authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
Jason Yan authored
CVE-2017-18232 In commit 87c8331f ("[SCSI] libsas: prevent domain rediscovery competing with ata error handling") introduced disco mutex to prevent rediscovery competing with ata error handling and put the whole revalidation in the mutex. But the rphy add/remove needs to wait for the error handling which also grabs the disco mutex. This may leads to dead lock.So the probe and destruct event were introduce to do the rphy add/remove asynchronously and out of the lock. The asynchronously processed workers makes the whole discovery process not atomic, the other events may interrupt the process. For example, if a loss of signal event inserted before the probe event, the sas_deform_port() is called and the port will be deleted. And sas_port_delete() may run before the destruct event, but the port-x:x is the top parent of end device or expander. This leads to a kernel WARNING such as: [ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22' [ 82.042983] ------------[ cut here ]------------ [ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237 sysfs_remove_group+0x94/0xa0 [ 82.043059] Call trace: [ 82.043082] [<ffff0000082e7624>] sysfs_remove_group+0x94/0xa0 [ 82.043085] [<ffff00000864e320>] dpm_sysfs_remove+0x60/0x70 [ 82.043086] [<ffff00000863ee10>] device_del+0x138/0x308 [ 82.043089] [<ffff00000869a2d0>] sas_phy_delete+0x38/0x60 [ 82.043091] [<ffff00000869a86c>] do_sas_phy_delete+0x6c/0x80 [ 82.043093] [<ffff00000863dc20>] device_for_each_child+0x58/0xa0 [ 82.043095] [<ffff000008696f80>] sas_remove_children+0x40/0x50 [ 82.043100] [<ffff00000869d1bc>] sas_destruct_devices+0x64/0xa0 [ 82.043102] [<ffff0000080e93bc>] process_one_work+0x1fc/0x4b0 [ 82.043104] [<ffff0000080e96c0>] worker_thread+0x50/0x490 [ 82.043105] [<ffff0000080f0364>] kthread+0xfc/0x128 [ 82.043107] [<ffff0000080836c0>] ret_from_fork+0x10/0x50 Make probe and destruct a direct call in the disco and revalidate function, but put them outside the lock. The whole discovery or revalidate won't be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT event are deleted as a result of the direct call. Introduce a new list to destruct the sas_port and put the port delete after the destruct. This makes sure the right order of destroying the sysfs kobject and fix the warning above. In sas_ex_revalidate_domain() have a loop to find all broadcasted device, and sometimes we have a chance to find the same expander twice. Because the sas_port will be deleted at the end of the whole revalidate process, sas_port with the same name cannot be added before this. Otherwise the sysfs will complain of creating duplicate filename. Since the LLDD will send broadcast for every device change, we can only process one expander's revalidation. [mkp: kbuild test robot warning] Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (backported from commit 0558f33c) [ Connor Kuehl: The hunk that removed variants from 'enum discover_event' required manual placement. I did take the liberty of removing the hardcoded enum values from this enum as is done in upstream commit 0d78f969 "scsi: libsas: remove the numbering for each event enum" but only for this enum to reduce confusion over renumbering. It seemed overkill to take in the entire patch alongside this backport. ] Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Sanjay Konduri authored
CVE-2018-21008 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 <sanjay.konduri@redpinesignals.com> Signed-off-by:
Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1845405Signed-off-by:
-
Cong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 6efb971b ] When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL pointer which leads to a crash in sfb_destroy(). Similar for sch_dsmark. Instead of fixing each separately, Linus suggested to just accept NULL pointer in qdisc_put(), which would make callers easier. (For sch_dsmark, the bug probably exists long before commit 6529eaba.) Fixes: 6529eaba ("net: sched: introduce tcf block infractructure") Reported-by: syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Vineet Gupta authored
BugLink: https://bugs.launchpad.net/bugs/1845405 This is a custom patch (no mainline equivalent) for stable backport only to address 0-Day kernel test infra ARC 4.x.y builds errors. The reason for this custom patch as that it is a single patch, touches only ARC, vs. atleast two 7c2c11b2, dc8635b7 which touch atleast 3 other arches (one long removed) and could potentially have a fallout. Reported-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Sean Young authored
BugLink: https://bugs.launchpad.net/bugs/1845405 commit 0c4df39e upstream. Ensure we do not access the buffer beyond the end if no 0xff byte is encountered. Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com Signed-off-by:
Sean Young <sean@mess.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Jann Horn authored
BugLink: https://bugs.launchpad.net/bugs/1845405 commit 52f6f9d7 upstream. As sparse points out, these two copy_from_user() should actually be copy_to_user(). Fixes: 229b53c9 ("take floppy compat ioctls to sodding floppy.c") Cc: stable@vger.kernel.org Acked-by:
Alexander Popov <alex.popov@linux.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Hillf Danton authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit d41a3eff ] If a request_key authentication token key gets revoked, there's a window in which request_key_auth_describe() can see it with a NULL payload - but it makes no check for this and something like the following oops may occur: BUG: Kernel NULL pointer dereference at 0x00000038 Faulting instruction address: 0xc0000000004ddf30 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [...] request_key_auth_describe+0x90/0xd0 LR [...] request_key_auth_describe+0x54/0xd0 Call Trace: [...] request_key_auth_describe+0x54/0xd0 (unreliable) [...] proc_keys_show+0x308/0x4c0 [...] seq_read+0x3d0/0x540 [...] proc_reg_read+0x90/0x110 [...] __vfs_read+0x3c/0x70 [...] vfs_read+0xb4/0x1b0 [...] ksys_read+0x7c/0x130 [...] system_call+0x5c/0x70 Fix this by checking for a NULL pointer when describing such a key. Also make the read routine check for a NULL pointer to be on the safe side. [DH: Modified to not take already-held rcu lock and modified to also check in the read routine] Fixes: 04c567d9 ("[PATCH] Keys: Fix race between two instantiators of a key") Reported-by:
Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by:
Hillf Danton <hdanton@sina.com> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
-
