summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2020-08-21nvme-tcp: fix possible hang waiting for icresp responseSagi Grimberg
commit adc99fd378398f4c58798a1c57889872967d56a6 upstream. If the controller died exactly when we are receiving icresp we hang because icresp may never return. Make sure to set a high finite limit. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speedsRussell King
commit 09781ba0395c46b1c844f47e405e3ce7856f5989 upstream. To support the change in "phy: armada-38x: fix NETA lockup when repeatedly switching speeds" we need to update the DT with the additional register. Fixes: 14dc100b4411 ("phy: armada38x: add common phy support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21xfrm: Fix crash when the hold queue is used.Steffen Klassert
commit 101dde4207f1daa1fda57d714814a03835dccc3f upstream. The commits "xfrm: Move dst->path into struct xfrm_dst" and "net: Create and use new helper xfrm_dst_child()." changed xfrm bundle handling under the assumption that xdst->path and dst->child are not a NULL pointer only if dst->xfrm is not a NULL pointer. That is true with one exception. If the xfrm hold queue is used to wait until a SA is installed by the key manager, we create a dummy bundle without a valid dst->xfrm pointer. The current xfrm bundle handling crashes in that case. Fix this by extending the NULL check of dst->xfrm with a test of the DST_XFRM_QUEUE flag. Fixes: 0f6c480f23f4 ("xfrm: Move dst->path into struct xfrm_dst") Fixes: b92cf4aab8e6 ("net: Create and use new helper xfrm_dst_child().") Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: dts sunxi: Relax a bit the CMA pool allocation rangeMaxime Ripard
commit 92025b90f18d45e26b7f17d68756b1abd771b9d3 upstream. The hardware codec on the A10, A10s, A13 and A20 needs buffer in the first 256MB of RAM. This was solved by setting the CMA pool at a fixed address in that range. However, in recent kernels there's something else that comes in and reserve some range that end up conflicting with our default pool requirement, and thus makes its reservation fail. The video codec will then use buffers from the usual default pool, outside of the range it can access, and will fail to decode anything. Since we're only concerned about that 256MB, we can however relax the allocation to just specify the range that's allowed, and not try to enforce a specific address. Fixes: 5949bc5602cc ("ARM: dts: sun4i-a10: Add Video Engine and reserved memory nodes") Fixes: 960432010156 ("ARM: dts: sun5i: Add Video Engine and reserved memory nodes") Fixes: c2a641a74850 ("ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20200704130829.34297-1-maxime@cerno.tech Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21net/x25: Fix null-ptr-deref in x25_disconnectYueHaibing
commit 8999dc89497ab1c80d0718828e838c7cd5f6bffe upstream. We should check null before do x25_neigh_put in x25_disconnect, otherwise may cause null-ptr-deref like this: #include <sys/socket.h> #include <linux/x25.h> int main() { int sck_x25; sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0); close(sck_x25); return 0; } BUG: kernel NULL pointer dereference, address: 00000000000000d8 CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3- RIP: 0010:x25_disconnect+0x91/0xe0 Call Trace: x25_release+0x18a/0x1b0 __sock_release+0x3d/0xc0 sock_close+0x13/0x20 __fput+0x107/0x270 ____fput+0x9/0x10 task_work_run+0x6d/0xb0 exit_to_usermode_loop+0x102/0x110 do_syscall_64+0x23c/0x260 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21net/x25: Fix x25_neigh refcnt leak when x25 disconnectXiyu Yang
commit 4becb7ee5b3d2829ed7b9261a245a77d5b7de902 upstream. x25_connect() invokes x25_get_neigh(), which returns a reference of the specified x25_neigh object to "x25->neighbour" with increased refcnt. When x25 connect success and returns, the reference still be hold by "x25->neighbour", so the refcount should be decreased in x25_disconnect() to keep refcount balanced. The reference counting issue happens in x25_disconnect(), which forgets to decrease the refcnt increased by x25_get_neigh() in x25_connect(), causing a refcnt leak. Fix this issue by calling x25_neigh_put() before x25_disconnect() returns. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21libtraceevent: Fix build with binutils 2.35Ben Hutchings
commit 39efdd94e314336f4acbac4c07e0f37bdc3bef71 upstream. In binutils 2.35, 'nm -D' changed to show symbol versions along with symbol names, with the usual @@ separator. When generating libtraceevent-dynamic-list we need just the names, so strip off the version suffix if present. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Cc: linux-trace-devel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21rds: Prevent kernel-infoleak in rds_notify_queue_get()Peilin Ye
commit bbc8a99e952226c585ac17477a85ef1194501762 upstream. rds_notify_queue_get() is potentially copying uninitialized kernel stack memory to userspace since the compiler may leave a 4-byte hole at the end of `cmsg`. In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which unfortunately does not always initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: f037590fff30 ("rds: fix a leak of kernel memory") Fixes: bdbe6fbc6a2f ("RDS: recv.c") Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21drm: hold gem reference until object is no longer accessedSteve Cohen
commit 8490d6a7e0a0a6fab5c2d82d57a3937306660864 upstream. A use-after-free in drm_gem_open_ioctl can happen if the GEM object handle is closed between the idr lookup and retrieving the size from said object since a local reference is not being held at that point. Hold the local reference while the object can still be accessed to fix this and plug the potential security hole. Signed-off-by: Steve Cohen <cohens@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1595284250-31580-1-git-send-email-cohens@codeaurora.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21drm/dbi: Fix SPI Type 1 (9-bit) transferPaul Cercueil
commit 900ab59e2621053b009f707f80b2c19ce0af5dee upstream. The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit data, the 9th (MSB) bit being the data/command bit. In order to do that, it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if the byte corresponds to data, clears it otherwise. The 7 MSB are padding. The array of now 16-bit values is then passed to the SPI core for transfer. This function was broken since its introduction, as the length of the SPI transfer was set to the payload size before its conversion, but the payload doubled in size due to the 8-bit -> 16-bit conversion. Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support") Cc: <stable@vger.kernel.org> # 5.4+ Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200703141341.1266263-1-paul@crapouillou.net Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()Peilin Ye
commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 upstream. Compiler leaves a 4-byte hole near the end of `dev_info`, causing amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace when `size` is greater than 356. In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which unfortunately does not initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()") Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"Alex Deucher
commit 87004abfbc27261edd15716515d89ab42198b405 upstream. This regressed some working configurations so revert it. Will fix this properly for 5.9 and backport then. This reverts commit 38e0c89a19fd13f28d2b4721035160a3e66e270b. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21virtio_balloon: fix up endian-ness for free cmd idMichael S. Tsirkin
commit 168c358af2f8c5a37f8b5f877ba2cc93995606ee upstream. free cmd id is read using virtio endian, spec says all fields in balloon are LE. Fix it up. Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Wei Wang <wei.w.wang@intel.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: dts: imx6qdl-icore: Fix OTG_ID pin and sdcard detectMichael Trimarchi
commit 4a601da92c2a782e5c022680d476104586b74994 upstream. The current pin muxing scheme muxes GPIO_1 pad for USB_OTG_ID because of which when card is inserted, usb otg is enumerated and the card is never detected. [ 64.492645] cfg80211: failed to load regulatory.db [ 64.492657] imx-sdma 20ec000.sdma: external firmware not found, using ROM firmware [ 76.343711] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 76.349742] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2 [ 76.388862] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 76.396650] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 [ 76.405412] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 76.412763] usb usb2: Product: EHCI Host Controller [ 76.417666] usb usb2: Manufacturer: Linux 5.8.0-rc1-next-20200618 ehci_hcd [ 76.424623] usb usb2: SerialNumber: ci_hdrc.0 [ 76.431755] hub 2-0:1.0: USB hub found [ 76.435862] hub 2-0:1.0: 1 port detected The TRM mentions GPIO_1 pad should be muxed/assigned for card detect and ENET_RX_ER pad for USB_OTG_ID for proper operation. This patch fixes pin muxing as per TRM and is tested on a i.Core 1.5 MX6 DL SOM. [ 22.449165] mmc0: host does not support reading read-only switch, assuming write-enable [ 22.459992] mmc0: new high speed SDHC card at address 0001 [ 22.469725] mmcblk0: mmc0:0001 EB1QT 29.8 GiB [ 22.478856] mmcblk0: p1 p2 Fixes: 6df11287f7c9 ("ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support") Cc: stable@vger.kernel.org Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: dts: imx6sx-sdb: Fix the phy-mode on fec2Fabio Estevam
commit c696afd331be1acb39206aba53048f2386b781fc upstream. Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the phy-mode for fec1, but missed to fix it for the fec2 node. Fix fec2 to also use "rgmii-id" as the phy-mode. Cc: <stable@vger.kernel.org> Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: dts: imx6sx-sabreauto: Fix the phy-mode on fec2Fabio Estevam
commit d36f260718d83928e6012247a7e1b9791cdb12ff upstream. Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the phy-mode for fec1, but missed to fix it for the fec2 node. Fix fec2 to also use "rgmii-id" as the phy-mode. Cc: <stable@vger.kernel.org> Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpointsWill Deacon
commit eec13b42d41b0f3339dcf0c4da43734427c68620 upstream. Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire unexpectedly. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. Cc: <stable@vger.kernel.org> Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework") Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21wireless: Use offsetof instead of custom macro.Pi-Hsun Shih
commit 6989310f5d4327e8595664954edd40a7f99ddd0d upstream. Use offsetof to calculate offset of a field to take advantage of compiler built-in version when possible, and avoid UBSAN warning when compiling with Clang: ================================================================== UBSAN: Undefined behaviour in net/wireless/wext-core.c:525:14 member access within null pointer of type 'struct iw_point' CPU: 3 PID: 165 Comm: kworker/u16:3 Tainted: G S W 4.19.23 #43 Workqueue: cfg80211 __cfg80211_scan_done [cfg80211] Call trace: dump_backtrace+0x0/0x194 show_stack+0x20/0x2c __dump_stack+0x20/0x28 dump_stack+0x70/0x94 ubsan_epilogue+0x14/0x44 ubsan_type_mismatch_common+0xf4/0xfc __ubsan_handle_type_mismatch_v1+0x34/0x54 wireless_send_event+0x3cc/0x470 ___cfg80211_scan_done+0x13c/0x220 [cfg80211] __cfg80211_scan_done+0x28/0x34 [cfg80211] process_one_work+0x170/0x35c worker_thread+0x254/0x380 kthread+0x13c/0x158 ret_from_fork+0x10/0x18 =================================================================== Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20191204081307.138765-1-pihsun@chromium.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-219p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_workWang Hai
commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29 upstream. p9_read_work and p9_fd_cancelled may be called concurrently. In some cases, req->req_list may be deleted by both p9_read_work and p9_fd_cancelled. We can fix it by ignoring replies associated with a cancelled request and ignoring cancelled request if message has been received before lock. Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to "cancelled" function") Cc: <stable@vger.kernel.org> # v3.12+ Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21vhost/scsi: fix up req type endian-nessMichael S. Tsirkin
commit 295c1b9852d000580786375304a9800bd9634d15 upstream. vhost/scsi doesn't handle type conversion correctly for request type when using virtio 1.0 and up for BE, or cross-endian platforms. Fix it up using vhost_32_to_cpu. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ALSA: hda/realtek - Fixed HP right speaker no soundKailang Yang
commit 5649625344fe1f4695eace7c37d011e317bf66d5 upstream. HP NB right speaker had no sound output. This platform was connected to I2S Amp for speaker out.(None Realtek I2S Amp IC) EC need to check codec GPIO1 pin to initial I2S Amp. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/01285f623ac7447187482fb4a8ecaa7c@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ALSA: hda/realtek: Fix add a "ultra_low_power" function for intel reference ↵PeiSen Hou
board (alc256) commit 6fa38ef1534e7e9320aa15e329eb1404ab2f70ac upstream. Intel requires to enable power saving mode for intel reference board (alc256) Signed-off-by: PeiSen Hou <pshou@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200727115647.10967-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ALSA: usb-audio: Add implicit feedback quirk for SSL2Laurence Tratt
commit 3da87ec67a491b9633a82045896c076b794bf938 upstream. As expected, this requires the same quirk as the SSL2+ in order for the clock to sync. This was suggested by, and tested on an SSL2, by Dmitry. Suggested-by: Dmitry <dpavlushko@gmail.com> Signed-off-by: Laurence Tratt <laurie@tratt.net> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200621075005.52mjjfc6dtdjnr3h@overdrive.tratt.net Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21mm/filemap.c: don't bother dropping mmap_sem for zero size readaheadJan Kara
commit 5c72feee3e45b40a3c96c7145ec422899d0e8964 upstream. When handling a page fault, we drop mmap_sem to start async readahead so that we don't block on IO submission with mmap_sem held. However there's no point to drop mmap_sem in case readahead is disabled. Handle that case to avoid pointless dropping of mmap_sem and retrying the fault. This was actually reported to block mlockall(MCL_CURRENT) indefinitely. Fixes: 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking operations") Reported-by: Minchan Kim <minchan@kernel.org> Reported-by: Robert Stupp <snazy@gmx.de> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Minchan Kim <minchan@kernel.org> Link: http://lkml.kernel.org/r/20200212101356.30759-1-jack@suse.cz Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21ath10k: enable transmit data ack RSSI for QCA9884Abhishek Ambure
commit cc78dc3b790619aa05f22a86a9152986bd73698c upstream. For all data packets transmitted, host gets htt tx completion event. Some QCA9984 firmware releases support WMI_SERVICE_TX_DATA_ACK_RSSI, which gives data ack rssi values to host through htt event of data tx completion. Data ack rssi values are valid if A0 bit is set in HTT rx message. So enable the feature also for QCA9884. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00044 Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org> [kvalo@codeaurora.org: improve commit log] Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21sunrpc: check that domain table is empty at module unload.NeilBrown
commit f45db2b909c7e76f35850e78f017221f30282b8e upstream. The domain table should be empty at module unload. If it isn't there is a bug somewhere. So check and report. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651 Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21Revert "dpaa_eth: fix usage as DSA master, try 3"Vladimir Oltean
This reverts commit e930ef001d91b6c8446e52719966cc86c46e29a0 which was commit 5d14c304bfc14b4fd052dc83d5224376b48f52f0 upstream. The patch is not wrong, but the Fixes: tag is. It should have been: Fixes: 060ad66f9795 ("dpaa_eth: change DMA device") which means that it's fixing a commit which was introduced in: git tag --contains 060ad66f97954 v5.5 which then means it should have not been backported to linux-5.4.y, where things _were_ working and now they're not. Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21Linux 5.2.55v5.2.55Paul Gortmaker
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21vfio-pci: Avoid recursive read-lock usageAlex Williamson
commit bc93b9ae0151ae5ad5b8504cdc598428ea99570b upstream. A down_read on memory_lock is held when performing read/write accesses to MMIO BAR space, including across the copy_to/from_user() callouts which may fault. If the user buffer for these copies resides in an mmap of device MMIO space, the mmap fault handler will acquire a recursive read-lock on memory_lock. Avoid this by reducing the lock granularity. Sequential accesses requiring multiple ioread/iowrite cycles are expected to be rare, therefore typical accesses should not see additional overhead. VGA MMIO accesses are expected to be non-fatal regardless of the PCI memory enable bit to allow legacy probing, this behavior remains with a comment added. ioeventfds are now included in memory access testing, with writes dropped while memory space is disabled. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Reported-by: Zhiyi Guo <zhguo@redhat.com> Tested-by: Zhiyi Guo <zhguo@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21PM: wakeup: Show statistics for deleted wakeup sources againzhuguangqing
commit e976eb4b91e906f20ec25b20c152d53c472fc3fd upstream. After commit 00ee22c28915 (PM / wakeup: Use seq_open() to show wakeup stats), print_wakeup_source_stats(m, &deleted_ws) is not called from wakeup_sources_stats_seq_show() any more. Because deleted_ws is one of the wakeup sources, it should be shown too, so add it to the end of all other wakeup sources. Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21regmap: debugfs: check count when read regmap filePeng Fan
commit 74edd08a4fbf51d65fd8f4c7d8289cd0f392bd91 upstream. When executing the following command, we met kernel dump. dmesg -c > /dev/null; cd /sys; for i in `ls /sys/kernel/debug/regmap/* -d`; do echo "Checking regmap in $i"; cat $i/registers; done && grep -ri "0x02d0" *; It is because the count value is too big, and kmalloc fails. So add an upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21sctp: shrink stream outq when fails to do addstream reconfXin Long
commit 3ecdda3e9ad837cf9cb41b6faa11b1af3a5abc0c upstream. When adding a stream with stream reconf, the new stream firstly is in CLOSED state but new out chunks can still be enqueued. Then once gets the confirmation from the peer, the state will change to OPEN. However, if the peer denies, it needs to roll back the stream. But when doing that, it only sets the stream outcnt back, and the chunks already in the new stream don't get purged. It caused these chunks can still be dequeued in sctp_outq_dequeue_data(). As its stream is still in CLOSE, the chunk will be enqueued to the head again by sctp_outq_head_data(). This chunk will never be sent out, and the chunks after it can never be dequeued. The assoc will be 'hung' in a dead loop of sending this chunk. To fix it, this patch is to purge these chunks already in the new stream by calling sctp_stream_shrink_out() when failing to do the addstream reconf. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Reported-by: Ying Xu <yinxu@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21sctp: shrink stream outq only when new outcnt < old outcntXin Long
commit 8f13399db22f909a35735bf8ae2f932e0c8f0e30 upstream. It's not necessary to go list_for_each for outq->out_chunk_list when new outcnt >= old outcnt, as no chunk with higher sid than new (outcnt - 1) exists in the outqueue. While at it, also move the list_for_each code in a new function sctp_stream_shrink_out(), which will be used in the next patch. Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21AX.25: Prevent integer overflows in connect and sendmsgDan Carpenter
commit 17ad73e941b71f3bec7523ea4e9cbc3752461c2d upstream. We recently added some bounds checking in ax25_connect() and ax25_sendmsg() and we so we removed the AX25_MAX_DIGIS checks because they were no longer required. Unfortunately, I believe they are required to prevent integer overflows so I have added them back. Fixes: 8885bb0621f0 ("AX.25: Prevent out-of-bounds read in ax25_sendmsg()") Fixes: 2f2a7ffad5c6 ("AX.25: Fix out-of-bounds read in ax25_connect()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21tcp: allow at most one TLP probe per flightYuchung Cheng
[ Upstream commit 76be93fc0702322179bb0ea87295d820ee46ad14 ] Previously TLP may send multiple probes of new data in one flight. This happens when the sender is cwnd limited. After the initial TLP containing new data is sent, the sender receives another ACK that acks partial inflight. It may re-arm another TLP timer to send more, if no further ACK returns before the next TLP timeout (PTO) expires. The sender may send in theory a large amount of TLP until send queue is depleted. This only happens if the sender sees such irregular uncommon ACK pattern. But it is generally undesirable behavior during congestion especially. The original TLP design restrict only one TLP probe per inflight as published in "Reducing Web Latency: the Virtue of Gentle Aggression", SIGCOMM 2013. This patch changes TLP to send at most one probe per inflight. Note that if the sender is app-limited, TLP retransmits old data and did not have this issue. Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [PG: use v5.4-stable version for "unused_1" bit count."] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21rxrpc: Fix sendmsg() returning EPIPE due to recvmsg() returning ENODATADavid Howells
commit 639f181f0ee20d3249dbc55f740f0167267180f0 upstream. rxrpc_sendmsg() returns EPIPE if there's an outstanding error, such as if rxrpc_recvmsg() indicating ENODATA if there's nothing for it to read. Change rxrpc_recvmsg() to return EAGAIN instead if there's nothing to read as this particular error doesn't get stored in ->sk_err by the networking core. Also change rxrpc_sendmsg() so that it doesn't fail with delayed receive errors (there's no way for it to report which call, if any, the error was caused by). Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21qrtr: orphan socket in qrtr_release()Cong Wang
commit af9f691f0f5bdd1ade65a7b84927639882d7c3e5 upstream. We have to detach sock from socket in qrtr_release(), otherwise skb->sk may still reference to this socket when the skb is released in tun->queue, particularly sk->sk_wq still points to &sock->wq, which leads to a UAF. Reported-and-tested-by: syzbot+6720d64f31c081c2f708@syzkaller.appspotmail.com Fixes: 28fb4e59a47d ("net: qrtr: Expose tunneling endpoint to user space") Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21net: udp: Fix wrong clean up for IS_UDPLITE macroMiaohe Lin
commit b0a422772fec29811e293c7c0e6f991c0fd9241d upstream. We can't use IS_UDPLITE to replace udp_sk->pcflag when UDPLITE_RECV_CC is checked. Fixes: b2bf1e2659b1 ("[UDP]: Clean up for IS_UDPLITE macro") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21net-sysfs: add a newline when printing 'tx_timeout' by sysfsXiongfeng Wang
commit 9bb5fbea59f36a589ef886292549ca4052fe676c upstream. When I cat 'tx_timeout' by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cat /sys/devices/virtual/net/lo/queues/tx-0/tx_timeout 0root@syzkaller:~# Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21drivers/net/wan/x25_asy: Fix to make it workXie He
commit 8fdcabeac39824fe67480fd9508d80161c541854 upstream. This driver is not working because of problems of its receiving code. This patch fixes it to make it work. When the driver receives an LAPB frame, it should first pass the frame to the LAPB module to process. After processing, the LAPB module passes the data (the packet) back to the driver, the driver should then add a one-byte pseudo header and pass the data to upper layers. The changes to the "x25_asy_bump" function and the "x25_asy_data_indication" function are to correctly implement this procedure. Also, the "x25_asy_unesc" function ignores any frame that is shorter than 3 bytes. However the shortest frames are 2-byte long. So we need to change it to allow 2-byte frames to pass. Cc: Eric Dumazet <edumazet@google.com> Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Xie He <xie.he.0141@gmail.com> Reviewed-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21dev: Defer free of skbs in flush_backlogSubash Abhinov Kasiviswanathan
commit 7df5cb75cfb8acf96c7f2342530eb41e0c11f4c3 upstream. IRQs are disabled when freeing skbs in input queue. Use the IRQ safe variant to free skbs here. Fixes: 145dd5f9c88f ("net: flush the softnet backlog in process context") Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21AX.25: Prevent out-of-bounds read in ax25_sendmsg()Peilin Ye
commit 8885bb0621f01a6c82be60a91e5fc0f6e2f71186 upstream. Checks on `addr_len` and `usax->sax25_ndigis` are insufficient. ax25_sendmsg() can go out of bounds when `usax->sax25_ndigis` equals to 7 or 8. Fix it. It is safe to remove `usax->sax25_ndigis > AX25_MAX_DIGIS`, since `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)` Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-21AX.25: Fix out-of-bounds read in ax25_connect()Peilin Ye
commit 2f2a7ffad5c6cbf3d438e813cfdc88230e185ba6 upstream. Checks on `addr_len` and `fsa->fsa_ax25.sax25_ndigis` are insufficient. ax25_connect() can go out of bounds when `fsa->fsa_ax25.sax25_ndigis` equals to 7 or 8. Fix it. This issue has been reported as a KMSAN uninit-value bug, because in such a case, ax25_connect() reaches into the uninitialized portion of the `struct sockaddr_storage` statically allocated in __sys_connect(). It is safe to remove `fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS` because `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)`. Reported-by: syzbot+c82752228ed975b0a623@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=55ef9d629f3b3d7d70b69558015b63b48d01af66 Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18Linux 5.2.54v5.2.54Paul Gortmaker
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18block: check queue's limits.discard_granularity in __blkdev_issue_discard()Coly Li
commit b35fd7422c2f8e04496f5a770bd4e1a205414b3f upstream. If create a loop device with a backing NVMe SSD, current loop device driver doesn't correctly set its queue's limits.discard_granularity and leaves it as 0. If a discard request at LBA 0 on this loop device, in __blkdev_issue_discard() the calculated req_sects will be 0, and a zero length discard request will trigger a BUG() panic in generic block layer code at block/blk-mq.c:563. [ 955.565006][ C39] ------------[ cut here ]------------ [ 955.559660][ C39] invalid opcode: 0000 [#1] SMP NOPTI [ 955.622171][ C39] CPU: 39 PID: 248 Comm: ksoftirqd/39 Tainted: G E 5.8.0-default+ #40 [ 955.622171][ C39] Hardware name: Lenovo ThinkSystem SR650 -[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE160M-2.70]- 07/17/2020 [ 955.622175][ C39] RIP: 0010:blk_mq_end_request+0x107/0x110 [ 955.622177][ C39] Code: 48 8b 03 e9 59 ff ff ff 48 89 df 5b 5d 41 5c e9 9f ed ff ff 48 8b 35 98 3c f4 00 48 83 c7 10 48 83 c6 19 e8 cb 56 c9 ff eb cb <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 54 [ 955.622179][ C39] RSP: 0018:ffffb1288701fe28 EFLAGS: 00010202 [ 955.749277][ C39] RAX: 0000000000000001 RBX: ffff956fffba5080 RCX: 0000000000004003 [ 955.749278][ C39] RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000000 [ 955.749279][ C39] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 955.749279][ C39] R10: ffffb1288701fd28 R11: 0000000000000001 R12: ffffffffa8e05160 [ 955.749280][ C39] R13: 0000000000000004 R14: 0000000000000004 R15: ffffffffa7ad3a1e [ 955.749281][ C39] FS: 0000000000000000(0000) GS:ffff95bfbda00000(0000) knlGS:0000000000000000 [ 955.749282][ C39] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 955.749282][ C39] CR2: 00007f6f0ef766a8 CR3: 0000005a37012002 CR4: 00000000007606e0 [ 955.749283][ C39] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 955.749284][ C39] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 955.749284][ C39] PKRU: 55555554 [ 955.749285][ C39] Call Trace: [ 955.749290][ C39] blk_done_softirq+0x99/0xc0 [ 957.550669][ C39] __do_softirq+0xd3/0x45f [ 957.550677][ C39] ? smpboot_thread_fn+0x2f/0x1e0 [ 957.550679][ C39] ? smpboot_thread_fn+0x74/0x1e0 [ 957.550680][ C39] ? smpboot_thread_fn+0x14e/0x1e0 [ 957.550684][ C39] run_ksoftirqd+0x30/0x60 [ 957.550687][ C39] smpboot_thread_fn+0x149/0x1e0 [ 957.886225][ C39] ? sort_range+0x20/0x20 [ 957.886226][ C39] kthread+0x137/0x160 [ 957.886228][ C39] ? kthread_park+0x90/0x90 [ 957.886231][ C39] ret_from_fork+0x22/0x30 [ 959.117120][ C39] ---[ end trace 3dacdac97e2ed164 ]--- This is the procedure to reproduce the panic, # modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1 # losetup -f /dev/nvme0n1 --direct-io=on # blkdiscard /dev/loop0 -o 0 -l 0x200 This patch fixes the issue by checking q->limits.discard_granularity in __blkdev_issue_discard() before composing the discard bio. If the value is 0, then prints a warning oops information and returns -EOPNOTSUPP to the caller to indicate that this buggy device driver doesn't support discard request. Fixes: 9b15d109a6b2 ("block: improve discard bio alignment in __blkdev_issue_discard()") Fixes: c52abf563049 ("loop: Better discard support for block devices") Reported-and-suggested-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Coly Li <colyli@suse.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: Enzo Matsumiya <ematsumiya@suse.com> Cc: Evan Green <evgreen@chromium.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Xiao Ni <xni@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18watchdog: initialize device before misc_registerKrzysztof Sobota
commit cb36e29bb0e4b0c33c3d5866a0a4aebace4c99b7 upstream. When watchdog device is being registered, it calls misc_register that makes watchdog available for systemd to open. This is a data race scenario, because when device is open it may still have device struct not initialized - this in turn causes a crash. This patch moves device initialization before misc_register call and it solves the problem printed below. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1 at lib/kobject.c:612 kobject_get+0x50/0x54 kobject: '(null)' ((ptrval)): is not initialized, yet kobject_get() is being called. Modules linked in: k2_reset_status(O) davinci_wdt(+) sfn_platform_hwbcn(O) fsmddg_sfn(O) clk_misc_mmap(O) clk_sw_bcn(O) fsp_reset(O) cma_mod(O) slave_sup_notif(O) fpga_master(O) latency(O+) evnotify(O) enable_arm_pmu(O) xge(O) rio_mport_cdev br_netfilter bridge stp llc nvrd_checksum(O) ipv6 CPU: 3 PID: 1 Comm: systemd Tainted: G O 4.19.113-g2579778-fsm4_k2 #1 Hardware name: Keystone [<c02126c4>] (unwind_backtrace) from [<c020da94>] (show_stack+0x18/0x1c) [<c020da94>] (show_stack) from [<c07f87d8>] (dump_stack+0xb4/0xe8) [<c07f87d8>] (dump_stack) from [<c0221f70>] (__warn+0xfc/0x114) [<c0221f70>] (__warn) from [<c0221fd8>] (warn_slowpath_fmt+0x50/0x74) [<c0221fd8>] (warn_slowpath_fmt) from [<c07fd394>] (kobject_get+0x50/0x54) [<c07fd394>] (kobject_get) from [<c0602ce8>] (get_device+0x1c/0x24) [<c0602ce8>] (get_device) from [<c06961e0>] (watchdog_open+0x90/0xf0) [<c06961e0>] (watchdog_open) from [<c06001dc>] (misc_open+0x130/0x17c) [<c06001dc>] (misc_open) from [<c0388228>] (chrdev_open+0xec/0x1a8) [<c0388228>] (chrdev_open) from [<c037fa98>] (do_dentry_open+0x204/0x3cc) [<c037fa98>] (do_dentry_open) from [<c0391e2c>] (path_openat+0x330/0x1148) [<c0391e2c>] (path_openat) from [<c0394518>] (do_filp_open+0x78/0xec) [<c0394518>] (do_filp_open) from [<c0381100>] (do_sys_open+0x130/0x1f4) [<c0381100>] (do_sys_open) from [<c0201000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xd2ceffa8 to 0xd2cefff0) ffa0: b6f69968 00000000 ffffff9c b6ebd210 000a0001 00000000 ffc0: b6f69968 00000000 00000000 00000142 fffffffd ffffffff 00b65530 bed7bb78 ffe0: 00000142 bed7ba70 b6cc2503 b6cc41d6 ---[ end trace 7b16eb105513974f ]--- ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1 at lib/refcount.c:153 kobject_get+0x24/0x54 refcount_t: increment on 0; use-after-free. Modules linked in: k2_reset_status(O) davinci_wdt(+) sfn_platform_hwbcn(O) fsmddg_sfn(O) clk_misc_mmap(O) clk_sw_bcn(O) fsp_reset(O) cma_mod(O) slave_sup_notif(O) fpga_master(O) latency(O+) evnotify(O) enable_arm_pmu(O) xge(O) rio_mport_cdev br_netfilter bridge stp llc nvrd_checksum(O) ipv6 CPU: 3 PID: 1 Comm: systemd Tainted: G W O 4.19.113-g2579778-fsm4_k2 #1 Hardware name: Keystone [<c02126c4>] (unwind_backtrace) from [<c020da94>] (show_stack+0x18/0x1c) [<c020da94>] (show_stack) from [<c07f87d8>] (dump_stack+0xb4/0xe8) [<c07f87d8>] (dump_stack) from [<c0221f70>] (__warn+0xfc/0x114) [<c0221f70>] (__warn) from [<c0221fd8>] (warn_slowpath_fmt+0x50/0x74) [<c0221fd8>] (warn_slowpath_fmt) from [<c07fd368>] (kobject_get+0x24/0x54) [<c07fd368>] (kobject_get) from [<c0602ce8>] (get_device+0x1c/0x24) [<c0602ce8>] (get_device) from [<c06961e0>] (watchdog_open+0x90/0xf0) [<c06961e0>] (watchdog_open) from [<c06001dc>] (misc_open+0x130/0x17c) [<c06001dc>] (misc_open) from [<c0388228>] (chrdev_open+0xec/0x1a8) [<c0388228>] (chrdev_open) from [<c037fa98>] (do_dentry_open+0x204/0x3cc) [<c037fa98>] (do_dentry_open) from [<c0391e2c>] (path_openat+0x330/0x1148) [<c0391e2c>] (path_openat) from [<c0394518>] (do_filp_open+0x78/0xec) [<c0394518>] (do_filp_open) from [<c0381100>] (do_sys_open+0x130/0x1f4) [<c0381100>] (do_sys_open) from [<c0201000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xd2ceffa8 to 0xd2cefff0) ffa0: b6f69968 00000000 ffffff9c b6ebd210 000a0001 00000000 ffc0: b6f69968 00000000 00000000 00000142 fffffffd ffffffff 00b65530 bed7bb78 ffe0: 00000142 bed7ba70 b6cc2503 b6cc41d6 ---[ end trace 7b16eb1055139750 ]--- Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Krzysztof Sobota <krzysztof.sobota@nokia.com> Link: https://lore.kernel.org/r/20200717103109.14660-1-krzysztof.sobota@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18i2c: rcar: avoid race when unregistering slaveWolfram Sang
commit c7c9e914f9a0478fba4dc6f227cfd69cf84a4063 upstream. Due to the lockless design of the driver, it is theoretically possible to access a NULL pointer, if a slave interrupt was running while we were unregistering the slave. To make this rock solid, disable the interrupt for a short time while we are clearing the interrupt_enable register. This patch is purely based on code inspection. The OOPS is super-hard to trigger because clearing SAR (the address) makes interrupts even more unlikely to happen as well. While here, reinit SCR to SDBS because this bit should always be set according to documentation. There is no effect, though, because the interface is disabled. Fixes: 7b814d852af6 ("i2c: rcar: avoid race when unregistering slave client") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18ceph: handle zero-length feature mask in session messagesJeff Layton
commit 02e37571f9e79022498fd0525c073b07e9d9ac69 upstream. Most session messages contain a feature mask, but the MDS will routinely send a REJECT message with one that is zero-length. Commit 0fa8263367db ("ceph: fix endianness bug when handling MDS session feature bits") fixed the decoding of the feature mask, but failed to account for the MDS sending a zero-length feature mask. This causes REJECT message decoding to fail. Skip trying to decode a feature mask if the word count is zero. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/46823 Fixes: 0fa8263367db ("ceph: fix endianness bug when handling MDS session feature bits") Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Tested-by: Patrick Donnelly <pdonnell@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18ALSA: usb-audio: fix overeager device match for MacroSilicon MS2109Hector Martin
commit 14a720dc1f5332f3bdf30a23a3bc549e81be974c upstream. Matching by device matches all interfaces, which breaks the video/HID portions of the device depending on module load order. Fixes: e337bf19f6af ("ALSA: usb-audio: add quirk for MacroSilicon MS2109") Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20200810045319.128745-1-marcan@marcan.st Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-08-18ASoC: topology: fix kernel oops on route addition errorPierre-Louis Bossart
commit 6f0307df83f2aa6bdf656c2219c89ce96502d20e upstream. When errors happens while loading graph components, the kernel oopses while trying to remove all topology components. This can be root-caused to a list pointing to memory that was already freed on error. remove_route() is already called on errors and will perform the required cleanups so there's no need to free the route memory in soc_tplg_dapm_graph_elems_load() if the route was added to the list. We do however want to free the routes allocated but not added to the list. Fixes: 7df04ea7a31ea ('ASoC: topology: modify dapm route loading routine and add dapm route unloading') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200707203749.113883-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>