- 23 Jul, 2019 40 commits
-
-
Adeodato Simó authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 52ad259e ] This silences -Wmissing-prototypes when defining p9_release_pages. Link: http://lkml.kernel.org/r/b1c4df8f21689b10d451c28fe38e860722d20e71.1542089696.git.dato@net.com.org.esSigned-off-by:
Adeodato Simó <dato@net.com.org.es> Signed-off-by:
Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Dominique Martinet authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit ef5305f1 ] strcpy to dirent->d_name could overflow the buffer, use strscpy to check the provided string length and error out if the size was too big. While we are here, make the function return an error when the pdu parsing failed, instead of returning the pdu offset as if it had been a success... Link: http://lkml.kernel.org/r/1536339057-21974-4-git-send-email-asmadeus@codewreck.org Addresses-Coverity-ID: 139133 ("Copy into fixed size buffer") Signed-off-by:
-
Dominique Martinet authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 473c7dd1 ] the client c is always dereferenced to get the rdma struct, so c has to be a valid pointer at this point. Gcc would optimize that away but let's make coverity happy... Link: http://lkml.kernel.org/r/1536339057-21974-3-git-send-email-asmadeus@codewreck.org Addresses-Coverity-ID: 102778 ("Dereference before null check") Signed-off-by:
-
Dominique Martinet authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit e02a53d9 ] iattr is passed to v9fs_vfs_setattr_dotl which does send various values from iattr over the wire, even if it tells the server to only look at iattr.ia_valid fields this could leak some stack data. Link: http://lkml.kernel.org/r/1536339057-21974-2-git-send-email-asmadeus@codewreck.org Addresses-Coverity-ID: 1195601 ("Uninitalized scalar variable") Signed-off-by:
-
Dominique Martinet authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 8b894adb ] 9p/rdma would sometimes drop the connection and display errors in recv_done when the user does ^C. The errors were caused by recv buffers that were posted at the time of disconnect, and we just do not want to disconnect when down_interruptible is... interrupted. Link: http://lkml.kernel.org/r/1535625307-18019-1-git-send-email-asmadeus@codewreck.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit b6313899 upstream. Since we make sure the destination buffer has at least strlen(orig) + 1, no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest, orig). This silences this gcc 8.2 warning on Alpine Linux: In function 'add_man_viewer', inlined from 'perf_help_config' at builtin-help.c:284:3: builtin-help.c:192:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] strncpy((*p)->name, name, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ builtin-help.c: In function 'perf_help_config': builtin-help.c:187:15: note: length computed here size_t len = strlen(name); ^~~~~~~~~~~~ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: 07800601 ("perf_counter tools: add in basic glue from Git") Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7kvo@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 4d0f16d0 upstream. The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this case we are actually setting the null byte at the right place, but since we pass the buffer size as the limit to strncpy() and not it minus one, gcc ends up warning us about that, see below. So, lets just switch to the shorter form provided by strlcpy(). This fixes this warning on an Alpine Linux Edge system with gcc 8.2: ui/tui/helpline.c: In function 'tui_helpline__push': ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals destination size [-Werror=stringop-truncation] strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0'; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: e6e90468 ("perf ui: Introduce struct ui_helpline") Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qpytj@git.kernel.orgSigned-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 588f7d39 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. Cc: stable@vger.kernel.org Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 4f488fbc upstream. In wiphy_new_nm(), if an error occurs after dev_set_name() and device_initialize() have already been called, it's necessary to call put_device() (via wiphy_free()) to avoid a memory leak. Reported-by: syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com Fixes: 1f87f7d3 ("cfg80211: add rfkill support") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Steve French authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 8d526d62 upstream. Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES as the number of simultaneous SMB3 requests grows (even though the client has sufficient credits). Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES so that we can retry writes which fail with this status code. This (for example) fixes large file copies to Windows 10 on fast networks. Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Marcel Holtmann authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 693cd8ce 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: d5bb334a ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marcel Holtmann authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit d5bb334a 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:
Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Fabio Estevam authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit b25af2ff upstream. Since commit 1e434b70 ("ARM: imx: update the cpu power up timing setting on i.mx6sx") some characters loss is noticed on i.MX6ULL UART as reported by Christoph Niedermaier. The intention of such commit was to increase the SW2ISO field for i.MX6SX only, but since cpuidle-imx6sx is also used on i.MX6UL/i.MX6ULL this caused unintended side effects on other SoCs. Fix this problem by keeping the original SW2ISO value for i.MX6UL/i.MX6ULL and only increase SW2ISO in the i.MX6SX case. Cc: stable@vger.kernel.org Fixes: 1e434b70 ("ARM: imx: update the cpu power up timing setting on i.mx6sx") Reported-by:
Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by:
Fabio Estevam <festevam@gmail.com> Tested-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Tested-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Willem de Bruijn authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit fd704bd5 upstream. CAN supports software tx timestamps as of the below commit. Purge any queued timestamp packets on socket destroy. Fixes: 51f31cab ("ip: support for TX timestamps on UDP and RAW sockets") Reported-by: syzbot+a90604060cb40f5bdd16@syzkaller.appspotmail.com Signed-off-by:
Willem de Bruijn <willemb@google.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Joakim Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 247e5356 upstream. Current we can meet timeout issue when setting a small bitrate like 10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ): | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000 A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check. | RTNETLINK answers: Connection timed out It is caused by calling of flexcan_chip_unfreeze() timeout. Originally the code is using usleep_range(10, 20) for unfreeze operation, but the patch (8badd65e can: flexcan: avoid calling usleep_range from interrupt context) changed it into udelay(10) which is only a half delay of before, there're also some other delay changes. After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue. Meanwhile, Rasmus Villemoes reported that even with a timeout of 100, flexcan_probe() fails on the MPC8309, which requires a value of at least 140 to work reliably. 250 works for everyone. Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
-
Naohiro Aota authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit c4e0540d upstream. Currently, btrfs does not consult seed devices to start readahead. As a result, if readahead zone is added to the seed devices, btrfs_reada_wait() indefinitely wait for the reada_ctl to finish. You can reproduce the hung by modifying btrfs/163 to have larger initial file size (e.g. xfs_io pwrite 4M instead of current 256K). Fixes: 7414a03f ("btrfs: initial readahead code and prototypes") Cc: stable@vger.kernel.org # 3.2+: ce7791ff: Btrfs: fix race between readahead and device replace/removal Cc: stable@vger.kernel.org # 3.2+ Reviewed-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Filipe Manana authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit ce7791ff upstream. The list of devices is protected by the device_list_mutex and the device replace code, in its finishing phase correctly takes that mutex before removing the source device from that list. However the readahead code was iterating that list without acquiring the respective mutex leading to crashes later on due to invalid memory accesses: [125671.831036] general protection fault: 0000 [#1] PREEMPT SMP [125671.832129] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis tpm ppdev evdev parport_pc psmouse sg parport processor ser [125671.834973] CPU: 10 PID: 19603 Comm: kworker/u32:19 Tainted: G W 4.6.0-rc7-btrfs-next-29+ #1 [125671.834973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [125671.834973] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs] [125671.834973] task: ffff8801ac520540 ti: ffff8801ac918000 task.ti: ffff8801ac918000 [125671.834973] RIP: 0010:[<ffffffff81270479>] [<ffffffff81270479>] __radix_tree_lookup+0x6a/0x105 [125671.834973] RSP: 0018:ffff8801ac91bc28 EFLAGS: 00010206 [125671.834973] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6a RCX: 0000000000000000 [125671.834973] RDX: 0000000000000000 RSI: 00000000000c1bff RDI: ffff88002ebd62a8 [125671.834973] RBP: ffff8801ac91bc70 R08: 0000000000000001 R09: 0000000000000000 [125671.834973] R10: ffff8801ac91bc70 R11: 0000000000000000 R12: ffff88002ebd62a8 [125671.834973] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000000c1bff [125671.834973] FS: 0000000000000000(0000) GS:ffff88023fd40000(0000) knlGS:0000000000000000 [125671.834973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [125671.834973] CR2: 000000000073cae4 CR3: 00000000b7723000 CR4: 00000000000006e0 [125671.834973] Stack: [125671.834973] 0000000000000000 ffff8801422d5600 ffff8802286bbc00 0000000000000000 [125671.834973] 0000000000000001 ffff8802286bbc00 00000000000c1bff 0000000000000000 [125671.834973] ffff88002e639eb8 ffff8801ac91bc80 ffffffff81270541 ffff8801ac91bcb0 [125671.834973] Call Trace: [125671.834973] [<ffffffff81270541>] radix_tree_lookup+0xd/0xf [125671.834973] [<ffffffffa04ae6a6>] reada_peer_zones_set_lock+0x3e/0x60 [btrfs] [125671.834973] [<ffffffffa04ae8b9>] reada_pick_zone+0x29/0x103 [btrfs] [125671.834973] [<ffffffffa04af42f>] reada_start_machine_worker+0x129/0x2d3 [btrfs] [125671.834973] [<ffffffffa04880be>] btrfs_scrubparity_helper+0x185/0x3aa [btrfs] [125671.834973] [<ffffffffa0488341>] btrfs_readahead_helper+0xe/0x10 [btrfs] [125671.834973] [<ffffffff81069691>] process_one_work+0x271/0x4e9 [125671.834973] [<ffffffff81069dda>] worker_thread+0x1eb/0x2c9 [125671.834973] [<ffffffff81069bef>] ? rescuer_thread+0x2b3/0x2b3 [125671.834973] [<ffffffff8106f403>] kthread+0xd4/0xdc [125671.834973] [<ffffffff8149e242>] ret_from_fork+0x22/0x40 [125671.834973] [<ffffffff8106f32f>] ? kthread_stop+0x286/0x286 So fix this by taking the device_list_mutex in the readahead code. We can't use here the lighter approach of using a rcu_read_lock() and rcu_read_unlock() pair together with a list_for_each_entry_rcu() call because we end up doing calls to sleeping functions (kzalloc()) in the respective code path. Signed-off-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
-
Robert Hancock authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 4a60570d ] Some chips have attributes which exist on more than one page but the attribute is not presently marked as paged. This causes the attributes to be generated with the same label, which makes it impossible for userspace to tell them apart. Marking all such attributes as paged would result in the page suffix being added regardless of whether they were present on more than one page or not, which might break existing setups. Therefore, we add a second check which treats the attribute as paged, even if not marked as such, if it is present on multiple pages. Fixes: b4ce237b ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers") Signed-off-by:
Robert Hancock <hancock@sedsystems.ca> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Alexandra Winter authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 33572619 ] Enabling sysfs attribute bridge_hostnotify triggers a series of udev events for the MAC addresses of all currently connected peers. In case no VLAN is set for a peer, the device reports the corresponding MAC addresses with VLAN ID 4096. This currently results in attribute VLAN=4096 for all non-VLAN interfaces in the initial series of events after host-notify is enabled. Instead, no VLAN attribute should be reported in the udev event for non-VLAN interfaces. Only the initial events face this issue. For dynamic changes that are reported later, the device uses a validity flag. This also changes the code so that it now sets the VLAN attribute for MAC addresses with VID 0. On Linux, no qeth interface will ever be registered with VID 0: Linux kernel registers VID 0 on all network interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0. Peers with other OSs could register MACs with VID 0. Fixes: 9f48b9db ("qeth: bridgeport support - address notifications") Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Avri Altman authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 1c90836f ] struct ufs_dev_cmd is the main container that supports device management commands. In the case of a read descriptor request, we assume that the proper space was allocated in dev_cmd to hold the returning descriptor. This is no longer true, as there are flows that doesn't use dev_cmd for device management requests, and was wrong in the first place. Fixes: d44a5f98 (ufs: query descriptor API) Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Acked-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
George G. Davis authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 4f45d62a ] The following error occurs for the `make ARCH=arm64 checkstack` case: aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \ perl ./scripts/checkstack.pl arm64 wrong or unknown architecture "arm64" As suggested by Masahiro Yamada, fix the above error using regular expressions in the same way it was fixed for the `ARCH=x86` case via commit fda9f990 ("scripts/checkstack.pl: automatically handle 32-bit and 64-bit mode for ARCH=x86"). Suggested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
George G. Davis <george_davis@mentor.com> Signed-off-by:
-
Young Xiao authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 56cd0aef ] The PERF_EVENT_IOC_PERIOD ioctl command can be used to change the sample period of a running perf_event. Consequently, when calculating the next event period, the new period will only be considered after the previous one has overflowed. This patch changes the calculation of the remaining event ticks so that they are offset if the period has changed. See commit 3581fe0e ("ARM: 7556/1: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD") for details. Signed-off-by:
Young Xiao <92siuyang@gmail.com> Signed-off-by:
-
Yonglong Liu authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 2e1f1648 ] When doing a loopback test at copper ports, the serdes loopback and the phy loopback will fail, because of the adjust link had not finished, and phy not ready. Adds sleep between adjust link and test process to fix it. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit f532beee ] Fixes gcc '-Wunused-but-set-variable' warning: arch/mips/kernel/uprobes.c: In function 'arch_uprobe_pre_xol': arch/mips/kernel/uprobes.c:115:17: warning: variable 'epc' set but not used [-Wunused-but-set-variable] It's never used since introduction in commit 40e084a5 ("MIPS: Add uprobes support.") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: <ralf@linux-mips.org> Cc: <jhogan@kernel.org> Cc: <linux-kernel@vger.kernel.org> Cc: <linux-mips@vger.kernel.org> Signed-off-by:
-
Mike Marciniszyn authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 6d517353 ] By code inspection, the freeze_work is never canceled. Fix by adding a cancel_work_sync in the shutdown path to insure it is no longer running. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Helge Deller authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 6b98d913 ] Avoid such compiler warnings: arch/parisc/math-emu/cnv_float.h:71:27: warning: ‘<<’ in boolean context, did you mean ‘<’ ? [-Wint-in-bool-context] ((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB)) arch/parisc/math-emu/fcnvxf.c:257:6: note: in expansion of macro ‘Dint_isinexact_to_sgl’ if (Dint_isinexact_to_sgl(srcp1,srcp2)) { Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1836668 [ Upstream commit 1c7ebeab ] BUG: memory leak unreferenced object 0xffff8881df48cda0 (size 16): comm "syz-executor.0", pid 5077, jiffies 4295994670 (age 22.280s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d2d0d5fe>] parport_register_dev_model+0x141/0x6e0 [parport] [<00000000782f6dab>] 0xffffffffc15d1196 [<00000000d2ca6ae4>] platform_drv_probe+0x7e/0x100 [<00000000628c2a94>] really_probe+0x342/0x4d0 [<000000006874f5da>] driver_probe_device+0x8c/0x170 [<00000000424de37a>] __device_attach_driver+0xda/0x100 [<000000002acab09a>] bus_for_each_drv+0xfe/0x170 [<000000003d9e5f31>] __device_attach+0x190/0x230 [<0000000035d32f80>] bus_probe_device+0x123/0x140 [<00000000a05ba627>] device_add+0x7cc/0xce0 [<000000003f7560bf>] platform_device_add+0x230/0x3c0 [<000000002a0be07d>] 0xffffffffc15d0949 [<000000007361d8d2>] port_check+0x3b/0x50 [parport] [<000000004d67200f>] bus_for_each_dev+0x115/0x180 [<000000003ccfd11c>] __parport_register_driver+0x1f0/0x210 [parport] [<00000000987f06fc>] 0xffffffffc15d803e After commit 4e5a74f1 ("parport: Revert "parport: fix memory leak""), free_pardevice do not free par_dev->state, we should free it in error path of parport_register_dev_model before return. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 4e5a74f1 ("parport: Revert "parport: fix memory leak"") Signed-off-by:
-
Jann Horn authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 8404d7a6 upstream. A packed AppArmor policy contains null-terminated tag strings that are read by unpack_nameX(). However, unpack_nameX() uses string functions on them without ensuring that they are actually null-terminated, potentially leading to out-of-bounds accesses. Make sure that the tag string is null-terminated before passing it to strcmp(). Cc: stable@vger.kernel.org Fixes: 736ec752 ("AppArmor: policy routines for loading and unpacking policy") Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Andrey Smirnov authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 7c7da40d upstream. In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD need to be adjusted before being passed on uinput_ioctl_handler() since code built with -m32 will be passing slightly different values. Extend the code already covering UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well. Reported-by:
Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Peter Chen authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit c19dffc0 upstream. An endpoint conflict occurs when the USB is working in device mode during an isochronous communication. When the endpointA IN direction is an isochronous IN endpoint, and the host sends an IN token to endpointA on another device, then the OUT transaction may be missed regardless the OUT endpoint number. Generally, this occurs when the device is connected to the host through a hub and other devices are connected to the same hub. The affected OUT endpoint can be either control, bulk, isochronous, or an interrupt endpoint. After the OUT endpoint is primed, if an IN token to the same endpoint number on another device is received, then the OUT endpoint may be unprimed (cannot be detected by software), which causes this endpoint to no longer respond to the host OUT token, and thus, no corresponding interrupt occurs. There is no good workaround for this issue, the only thing the software could do is numbering isochronous IN from the highest endpoint since we have observed most of device number endpoint from the lowest. Cc: <stable@vger.kernel.org> #v3.14+ Cc: Fabio Estevam <festevam@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Jun Li <jun.li@nxp.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 6f303d60 upstream. We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. Signed-off-by:
-
Miguel Ojeda authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 0c97bf86 upstream. Starting with GCC 9, -Warray-bounds detects cases when memset is called starting on a member of a struct but the size to be cleared ends up writing over further members. Such a call happens in the trace code to clear, at once, all members after and including `seq` on struct trace_iterator: In function 'memset', inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3: ./include/linux/string.h:344:9: warning: '__builtin_memset' offset [8505, 8560] from the object at 'iter' is out of the bounds of referenced subobject 'seq' with type 'struct trace_seq' at offset 4368 [-Warray-bounds] 344 | return __builtin_memset(p, c, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to avoid GCC complaining about it, we compute the address ourselves by adding the offsetof distance instead of referring directly to the member. Since there are two places doing this clear (trace.c and trace_kdb.c), take the chance to move the workaround into a single place in the internal header. Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.comSigned-off-by:
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> [ Removed unnecessary parenthesis around "iter" ] Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Jan Kara authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 240b4cc8 upstream. Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0] dereference can dereference already freed request leading to kernel crashes or other issues (which one of our customers observed). Store cmd->cmnd[0] in a local variable before unlocking adapter->hw_lock to fix the issue. CC: <stable@vger.kernel.org> Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Jann Horn authored
BugLink: https://bugs.launchpad.net/bugs/1836668 commit 867bfa4a upstream. load_flat_shared_library() is broken: It only calls load_flat_file() if prepare_binprm() returns zero, but prepare_binprm() returns the number of bytes read - so this only happens if the file is empty. Instead, call into load_flat_file() if the number of bytes read is non-negative. (Even if the number of bytes is zero - in that case, load_flat_file() will see nullbytes and return a nice -ENOEXEC.) In addition, remove the code related to bprm creds and stop using prepare_binprm() - this code is loading a library, not a main executable, and it only actually uses the members "buf", "file" and "filename" of the linux_binprm struct. Instead, call kernel_read() directly. Link: http://lkml.kernel.org/r/20190524201817.16509-1-jannh@google.com Fixes: 287980e4 ("remove lots of IS_ERR_VALUE abuses") Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1836667Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1836666Signed-off-by:
-
Alexander Lochmann authored
BugLink: https://bugs.launchpad.net/bugs/1836666 commit f69e749a upstream. file_remove_privs() might be called for non-regular files, e.g. blkdev inode. There is no reason to do its job on things like blkdev inodes, pipes, or cdevs. Hence, abort if file does not refer to a regular inode. AV: more to the point, for devices there might be any number of inodes refering to given device. Which one to strip the permissions from, even if that made any sense in the first place? All of them will be observed with contents modified, after all. Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf Spinczyk) Reviewed-by:
Alexander Lochmann <alexander.lochmann@tu-dortmund.de> Signed-off-by:
Horst Schirmeier <horst.schirmeier@tu-dortmund.de> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Zubin Mithra <zsm@chromium.org> Signed-off-by:
-
Andrea Arcangeli authored
BugLink: https://bugs.launchpad.net/bugs/1836666 commit 04f5866e upstream. The core dumping code has always run without holding the mmap_sem for writing, despite that is the only way to ensure that the entire vma layout will not change from under it. Only using some signal serialization on the processes belonging to the mm is not nearly enough. This was pointed out earlier. For example in Hugh's post from Jul 2017: https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils "Not strictly relevant here, but a related note: I was very surprised to discover, only quite recently, how handle_mm_fault() may be called without down_read(mmap_sem) - when core dumping. That seems a misguided optimization to me, which would also be nice to correct" In particular because the growsdown and growsup can move the vm_start/vm_end the various loops the core dump does around the vma will not be consistent if page faults can happen concurrently. Pretty much all users calling mmget_not_zero()/get_task_mm() and then taking the mmap_sem had the potential to introduce unexpected side effects in the core dumping code. Adding mmap_sem for writing around the ->core_dump invocation is a viable long term fix, but it requires removing all copy user and page faults and to replace them with get_dump_page() for all binary formats which is not suitable as a short term fix. For the time being this solution manually covers the places that can confuse the core dump either by altering the vma layout or the vma flags while it runs. Once ->core_dump runs under mmap_sem for writing the function mmget_still_valid() can be dropped. Allowing mmap_sem protected sections to run in parallel with the coredump provides some minor parallelism advantage to the swapoff code (which seems to be safe enough by never mangling any vma field and can keep doing swapins in parallel to the core dumping) and to some other corner case. In order to facilitate the backporting I added "Fixes: 86039bd3" however the side effect of this same race condition in /proc/pid/mem should be reproducible since before 2.6.12-rc2 so I couldn't add any other "Fixes:" because there's no hash beyond the git genesis commit. Because find_extend_vma() is the only location outside of the process context that could modify the "mm" structures under mmap_sem for reading, by adding the mmget_still_valid() check to it, all other cases that take the mmap_sem for reading don't need the new check after mmget_not_zero()/get_task_mm(). The expand_stack() in page fault context also doesn't need the new check, because all tasks under core dumping are frozen. Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com Fixes: 86039bd3 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Reported-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Mike Rapoport <rppt@linux.ibm.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1836666 This reverts commit e9a60ab1609a7d975922adad1bf9c46ac6954584 which is commit fc340115 upstream. Hauke writes that this breaks the build and should be reverted. Reported-by:
Hauke Mehrtens <hauke@hauke-m.de> Cc: Christian Lamparter <chunkeey@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Jason Yan authored
BugLink: https://bugs.launchpad.net/bugs/1836666 [ Upstream commit 3b054179 ] 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: 2908d778 ("[SCSI] aic94xx: new driver") Reported-by:
Jian Luo <luojian5@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> Signed-off-by:
-
