aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-10-11livepatch: unpatch all klp_objects if klp_module_coming failsJoe Lawrence1-23/+37
When an incoming module is considered for livepatching by klp_module_coming(), it iterates over multiple patches and multiple kernel objects in this order: list_for_each_entry(patch, &klp_patches, list) { klp_for_each_object(patch, obj) { which means that if one of the kernel objects fails to patch, klp_module_coming()'s error path needs to unpatch and cleanup any kernel objects that were already patched by a previous patch. Reported-by: Miroslav Benes <[email protected]> Suggested-by: Petr Mladek <[email protected]> Signed-off-by: Joe Lawrence <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2017-10-11usb: usbtest: fix NULL pointer dereferenceAlan Stern1-2/+3
If the usbtest driver encounters a device with an IN bulk endpoint but no OUT bulk endpoint, it will try to dereference a NULL pointer (out->desc.bEndpointAddress). The problem can be solved by adding a missing test. Signed-off-by: Alan Stern <[email protected]> Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11usb: gadget: configfs: Fix memory leak of interface directory dataAndrew Gabbasov4-14/+25
Kmemleak checking configuration reports a memory leak in usb_os_desc_prepare_interf_dir function when rndis function instance is freed and then allocated again. For example, this happens with FunctionFS driver with RNDIS function enabled when "ffs-test" test application is run several times in a row. The data for intermediate "os_desc" group for interface directories is allocated as a single VLA chunk and (after a change of default groups handling) is not ever freed and actually not stored anywhere besides inside a list of default groups of a parent group. The fix is to make usb_os_desc_prepare_interf_dir function return a pointer to allocated data (as a pointer to the first VLA item) instead of (an unused) integer and to make the caller component (currently the only one is RNDIS function) responsible for storing the pointer and freeing the memory when appropriate. Fixes: 1ae1602de028 ("configfs: switch ->default groups to a linked list") Cc: [email protected] Signed-off-by: Andrew Gabbasov <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11usb: gadget: composite: Fix use-after-free in usb_composite_overwrite_optionsAndrew Gabbasov1-0/+5
KASAN enabled configuration reports an error BUG: KASAN: use-after-free in usb_composite_overwrite_options+... [libcomposite] at addr ... Read of size 1 by task ... when some driver is un-bound and then bound again. For example, this happens with FunctionFS driver when "ffs-test" test application is run several times in a row. If the driver has empty manufacturer ID string in initial static data, it is then replaced with generated string. After driver unbinding the generated string is freed, but the driver data still keep that pointer. And if the driver is then bound again, that pointer is re-used for string emptiness check. The fix is to clean up the driver string data upon its unbinding to drop the pointer to freed memory. Fixes: cc2683c318a5 ("usb: gadget: Provide a default implementation of default manufacturer string") Cc: [email protected] Signed-off-by: Andrew Gabbasov <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11usb: misc: usbtest: Fix overflow in usbtest_do_ioctl()Dan Carpenter1-0/+5
There used to be a test against "if (param->sglen > MAX_SGLEN)" but it was removed during a refactor. It leads to an integer overflow and a stack overflow in test_queue() if we try to create a too large urbs[] array on the stack. There is a second integer overflow in test_queue() as well if "param->iterations" is too high. I don't immediately see that it's harmful but I've added a check to prevent it and silence the static checker warning. Fixes: 18fc4ebdc705 ("usb: misc: usbtest: Remove timeval usage") Acked-by: Deepa Dinamani <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packetKazuya Mizuguchi1-1/+1
The DREQE bit of the DnFIFOSEL should be set to 1 after the DE bit of USB-DMAC on R-Car SoCs is set to 1 after the USB-DMAC received a zero-length packet. Otherwise, a transfer completion interruption of USB-DMAC doesn't happen. Even if the driver changes the sequence, normal operations (transmit/receive without zero-length packet) will not cause any side-effects. So, this patch fixes the sequence anyway. Signed-off-by: Kazuya Mizuguchi <[email protected]> [shimoda: revise the commit log] Fixes: e73a9891b3a1 ("usb: renesas_usbhs: add DMAEngine support") Cc: <[email protected]> # v3.1+ Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11USB: dummy-hcd: Fix deadlock caused by disconnect detectionAlan Stern1-3/+6
The dummy-hcd driver calls the gadget driver's disconnect callback under the wrong conditions. It should invoke the callback when Vbus power is turned off, but instead it does so when the D+ pullup is turned off. This can cause a deadlock in the composite core when a gadget driver is unregistered: [ 88.361471] ============================================ [ 88.362014] WARNING: possible recursive locking detected [ 88.362580] 4.14.0-rc2+ #9 Not tainted [ 88.363010] -------------------------------------------- [ 88.363561] v4l_id/526 is trying to acquire lock: [ 88.364062] (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite] [ 88.365051] [ 88.365051] but task is already holding lock: [ 88.365826] (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite] [ 88.366858] [ 88.366858] other info that might help us debug this: [ 88.368301] Possible unsafe locking scenario: [ 88.368301] [ 88.369304] CPU0 [ 88.369701] ---- [ 88.370101] lock(&(&cdev->lock)->rlock); [ 88.370623] lock(&(&cdev->lock)->rlock); [ 88.371145] [ 88.371145] *** DEADLOCK *** [ 88.371145] [ 88.372211] May be due to missing lock nesting notation [ 88.372211] [ 88.373191] 2 locks held by v4l_id/526: [ 88.373715] #0: (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite] [ 88.374814] #1: (&(&dum_hcd->dum->lock)->rlock){....}, at: [<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd] [ 88.376289] [ 88.376289] stack backtrace: [ 88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9 [ 88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 88.379504] Call Trace: [ 88.380019] dump_stack+0x86/0xc7 [ 88.380605] __lock_acquire+0x841/0x1120 [ 88.381252] lock_acquire+0xd5/0x1c0 [ 88.381865] ? composite_disconnect+0x43/0x100 [libcomposite] [ 88.382668] _raw_spin_lock_irqsave+0x40/0x54 [ 88.383357] ? composite_disconnect+0x43/0x100 [libcomposite] [ 88.384290] composite_disconnect+0x43/0x100 [libcomposite] [ 88.385490] set_link_state+0x2d4/0x3c0 [dummy_hcd] [ 88.386436] dummy_pullup+0xa7/0xf0 [dummy_hcd] [ 88.387195] usb_gadget_disconnect+0xd8/0x160 [udc_core] [ 88.387990] usb_gadget_deactivate+0xd3/0x160 [udc_core] [ 88.388793] usb_function_deactivate+0x64/0x80 [libcomposite] [ 88.389628] uvc_function_disconnect+0x1e/0x40 [usb_f_uvc] This patch changes the code to test the port-power status bit rather than the port-connect status bit when deciding whether to isue the callback. Signed-off-by: Alan Stern <[email protected]> Reported-by: David Tulloh <[email protected]> CC: <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11usb: phy: tegra: Fix phy suspend for UDCJon Hunter1-0/+17
Commit dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124") added UDC support for Tegra but with UDC support enabled, is was found that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend. The hang occurred during the suspend of the USB PHY when the Tegra PHY driver attempted to disable the PHY clock. The problem is that before the Tegra PHY driver is suspended, the chipidea driver already disabled the PHY clock and when the Tegra PHY driver suspended, it could not read DEVLC register and caused the device to hang. The Tegra USB PHY driver is used by both the Tegra EHCI driver and now the chipidea UDC driver and so simply removing the disabling of the PHY clock from the USB PHY driver would not work for the Tegra EHCI driver. Fortunately, the status of the USB PHY clock can be read from the USB_SUSP_CTRL register and therefore, to workaround this issue, simply poll the register prior to disabling the clock in USB PHY driver to see if clock gating has already been initiated. Please note that it can take a few uS for the clock to disable and so simply reading this status register once on entry is not sufficient. Similarly when turning on the PHY clock, it is possible that the clock is already enabled or in the process of being enabled, and so check for this when enabling the PHY. Please note that no issues are seen with Tegra20 because it has a slightly different PHY to Tegra30/114/124. Fixes: dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124") Reviewed-by: Dmitry Osipenko <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-10-11gpu: ipu-v3: pre: implement workaround for ERR009624Lucas Stach1-0/+29
The PRE has a bug where a software write to the CTRL register can block the setting of the ENABLE bit by the hardware in auto repeat mode. When this happens the PRE will fail to handle new jobs. To work around this software must not write to CTRL register when the PRE store engine is inside the unsafe window, where a hardware update to the ENABLE bit may happen. Signed-off-by: Lucas Stach <[email protected]> [[email protected]: rebased before PRE tiled prefetch support] Signed-off-by: Philipp Zabel <[email protected]>
2017-10-11gpu: ipu-v3: prg: wait for double buffers to be filled on channel startupLucas Stach1-0/+7
Wait for both double buffer to be filled when first starting a channel. This makes channel startup a lot more reliable, probably because it allows the internal state machine to settle before the requests from the IPU are coming in. Signed-off-by: Lucas Stach <[email protected]> [[email protected]: rebased before switch to runtime PM] Signed-off-by: Philipp Zabel <[email protected]>
2017-10-11gpu: ipu-v3: Allow channel burst locking on i.MX6 onlyPhilipp Zabel1-0/+8
The IDMAC_LOCK_EN registers on i.MX51 have a different layout, and on i.MX53 enabling the lock feature causes bursts to get lost. Restrict enabling the burst lock feature to i.MX6. Reported-by: Patrick Brünn <[email protected]> Fixes: 790cb4c7c954 ("drm/imx: lock scanout transfers for consecutive bursts") Tested-by: Patrick Brünn <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
2017-10-11ALSA: seq: Fix use-after-free at creating a portTakashi Iwai2-3/+10
There is a potential race window opened at creating and deleting a port via ioctl, as spotted by fuzzing. snd_seq_create_port() creates a port object and returns its pointer, but it doesn't take the refcount, thus it can be deleted immediately by another thread. Meanwhile, snd_seq_ioctl_create_port() still calls the function snd_seq_system_client_ev_port_start() with the created port object that is being deleted, and this triggers use-after-free like: BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511 ___slab_alloc+0x425/0x460 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x150/0x190 snd_seq_create_port+0x94/0x9b0 [snd_seq] snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717 __slab_free+0x204/0x310 kfree+0x15f/0x180 port_delete+0x136/0x1a0 [snd_seq] snd_seq_delete_port+0x235/0x350 [snd_seq] snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 Call Trace: [<ffffffff81b03781>] dump_stack+0x63/0x82 [<ffffffff81531b3b>] print_trailer+0xfb/0x160 [<ffffffff81536db4>] object_err+0x34/0x40 [<ffffffff815392d3>] kasan_report.part.2+0x223/0x520 [<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30 [<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq] [<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0 [<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] [<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq] [<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80 [<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0 ..... We may fix this in a few different ways, and in this patch, it's fixed simply by taking the refcount properly at snd_seq_create_port() and letting the caller unref the object after use. Also, there is another potential use-after-free by sprintf() call in snd_seq_create_port(), and this is moved inside the lock. This fix covers CVE-2017-15265. Reported-and-tested-by: Michael23 Yu <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-10-10bio_copy_user_iov(): don't ignore ->iov_offsetAl Viro1-2/+2
Since "block: support large requests in blk_rq_map_user_iov" we started to call it with partially drained iter; that works fine on the write side, but reads create a copy of iter for completion time. And that needs to take the possibility of ->iov_iter != 0 into account... Cc: [email protected] #v4.5+ Signed-off-by: Al Viro <[email protected]>
2017-10-10more bio_map_user_iov() leak fixesAl Viro1-5/+9
we need to take care of failure exit as well - pages already in bio should be dropped by analogue of bio_unmap_pages(), since their refcounts had been bumped only once per reference in bio. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2017-10-10fix unbalanced page refcounting in bio_map_user_iovVitaly Mayatskikh1-0/+8
bio_map_user_iov and bio_unmap_user do unbalanced pages refcounting if IO vector has small consecutive buffers belonging to the same page. bio_add_pc_page merges them into one, but the page reference is never dropped. Cc: [email protected] Signed-off-by: Vitaly Mayatskikh <[email protected]> Signed-off-by: Al Viro <[email protected]>
2017-10-10net: call cgroup_sk_alloc() earlier in sk_clone_lock()Eric Dumazet1-2/+1
If for some reason, the newly allocated child need to be freed, we will call cgroup_put() (via sk_free_unlock_clone()) while the corresponding cgroup_get() was not yet done, and we will free memory too soon. Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets") Signed-off-by: Eric Dumazet <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-10Revert "net: defer call to cgroup_sk_alloc()"Eric Dumazet3-6/+13
This reverts commit fbb1fb4ad415cb31ce944f65a5ca700aaf73a227. This was not the proper fix, lets cleanly revert it, so that following patch can be carried to stable versions. sock_cgroup_ptr() callers do not expect a NULL return value. Signed-off-by: Eric Dumazet <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-10direct-io: Prevent NULL pointer access in submit_page_sectionAndreas Gruenbacher1-1/+2
In the code added to function submit_page_section by commit b1058b981, sdio->bio can currently be NULL when calling dio_bio_submit. This then leads to a NULL pointer access in dio_bio_submit, so check for a NULL bio in submit_page_section before trying to submit it instead. Fixes xfstest generic/250 on gfs2. Cc: [email protected] # v3.10+ Signed-off-by: Andreas Gruenbacher <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Al Viro <[email protected]>
2017-10-10PCI: aardvark: Move to struct pci_host_bridge IRQ mapping functionsThomas Petazzoni1-0/+2
struct pci_host_bridge gained hooks to map/swizzle IRQs, so that the IRQ mapping can be done automatically by PCI core code through the pci_assign_irq() function instead of resorting to arch-specific implementation callbacks to carry out the same task which force PCI host bridge drivers implementation to implement per-arch kludges to carry out a task that is inherently architecture agnostic. Commit 769b461fc0c0 ("arm64: PCI: Drop DT IRQ allocation from pcibios_alloc_irq()") was assuming all PCI host controller drivers had been converted to use ->map_irq(), but that wasn't the case: pci-aardvark had not been converted. Due to this, it broke the support for legacy PCI interrupts when using the pci-aardvark driver (used on Marvell Armada 3720 platforms). In order to fix this, we make sure the ->map_irq and ->swizzle_irq fields of pci_host_bridge are properly filled in. Fixes: 769b461fc0c0 ("arm64: PCI: Drop DT IRQ allocation from pcibios_alloc_irq()") Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] # v4.13+
2017-10-10Revert "PCI: tegra: Do not allocate MSI target memory"Thierry Reding1-16/+6
This reverts commit d7bd554f27c942e6b8b54100b4044f9be1038edf. It turns out that Tegra20 has a bug in the implementation of the MSI target address register (which is worked around by the existence of the struct tegra_pcie_soc.msi_base_shift parameter) that restricts the MSI target memory to the lower 32 bits of physical memory on that particular generation. The offending patch causes a regression on TrimSlice, which is a Tegra20-based device and has a PCI network interface card. An initial, simpler fix was to change the MSI target address for Tegra20 only, but it was pointed out that the offending commit also prevents the use of 32-bit only MSI capable devices, even on later chips. Technically this was never guaranteed to work with the prior code in the first place because the allocated page could have resided beyond the 4 GiB boundary, but it is still possible that this could've introduced a regression. The proper fix that was settled on is to select a fixed address within the lowest 32 bits of physical address space that is otherwise unused, but testing of that patch has provided mixed results that are not fully understood yet. Given all of the above and the relative urgency to get this fixed in v4.13, revert the offending commit until a universal fix is found. Fixes: d7bd554f27c9 ("PCI: tegra: Do not allocate MSI target memory") Reported-by: Tomasz Maciej Nowak <[email protected]> Reported-by: Erik Faye-Lund <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] # 4.13.x
2017-10-10Merge branch 'nfp-fix-ethtool-stats-and-page-allocation'David S. Miller2-9/+19
Jakub Kicinski says: ==================== nfp: fix ethtool stats and page allocation Two fixes for net. First one makes sure we handle gather of stats on 32bit machines correctly (ouch). The second fix solves a potential NULL-deref if we fail to allocate a page with XDP running. I used Fixes: tags pointing to where the bug was introduced, but for patch 1 it has been in the driver "for ever" and fix won't backport cleanly beyond commit 325945ede6d4 ("nfp: split software and hardware vNIC statistics") which is in net. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-10-10nfp: handle page allocation failuresJakub Kicinski1-6/+14
page_address() does not handle NULL argument gracefully, make sure we NULL-check the page pointer before passing it to page_address(). Fixes: ecd63a0217d5 ("nfp: add XDP support in the driver") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-10nfp: fix ethtool stats gather retryJakub Kicinski1-3/+5
The while loop fetching 64 bit ethtool statistics may have to retry multiple times, it shouldn't modify the outside state. Fixes: 4c3523623dc0 ("net: add driver for Netronome NFP4000/NFP6000 NIC VFs") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-10Merge branch '40GbE' of ↵David S. Miller2-28/+37
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2017-10-10 This series contains updates to i40e only. Stefano Brivio fixes the grammar in a function header comment. Alex fixes a memory leak where we were not correctly placing the pages from buffers that had been used to return a filter programming status back on the ring. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-10-10Merge tag 'seccomp-v4.14-rc5' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull seccomp fixlet from Kees Cook: "Minor seccomp fix for v4.14-rc5. I debated sending this at all for v4.14, but since it fixes a minor issue in the prior fix, which also went to -stable, it seemed better to just get all of it cleaned up right now. - fix missed "static" to avoid Sparse warning (Colin King)" * tag 'seccomp-v4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: seccomp: make function __get_seccomp_filter static
2017-10-10Merge tag 'nfsd-4.14-1' of git://linux-nfs.org/~bfields/linuxLinus Torvalds2-3/+10
Pull nfsd fix from Bruce Fields: "One fix for a 4.14 regression, and one minor fix to the MAINTAINERs file. (I was weirdly flattered by the idea that lots of random people suddenly seemed to think Jeff and I were VFS experts. Turns out it was just a typo)" * tag 'nfsd-4.14-1' of git://linux-nfs.org/~bfields/linux: nfsd4: define nfsd4_secinfo_no_name_release() MAINTAINERS: associate linux/fs.h with VFS instead of file locking
2017-10-10wimax/i2400m: Remove VLAISBehan Webster1-1/+1
Convert Variable Length Array in Struct (VLAIS) to valid C by converting local struct definition to use a flexible array. The structure is only used to define a cast of a buffer so the size of the struct is not used to allocate storage. Signed-off-by: Behan Webster <[email protected]> Signed-off-by: Mark Charebois <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-10seccomp: make function __get_seccomp_filter staticColin Ian King1-1/+1
The function __get_seccomp_filter is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: symbol '__get_seccomp_filter' was not declared. Should it be static? Signed-off-by: Colin Ian King <[email protected]> Fixes: 66a733ea6b61 ("seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2017-10-10remoteproc: qcom: fix RPMSG_QCOM_GLINK_SMEM dependenciesArnd Bergmann1-0/+2
When RPMSG_QCOM_GLINK_SMEM=m and one driver causes the qcom_common.c file to be compiled as built-in, we get a link error: drivers/remoteproc/qcom_common.o: In function `glink_subdev_remove': qcom_common.c:(.text+0x130): undefined reference to `qcom_glink_smem_unregister' qcom_common.c:(.text+0x130): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `qcom_glink_smem_unregister' drivers/remoteproc/qcom_common.o: In function `glink_subdev_probe': qcom_common.c:(.text+0x160): undefined reference to `qcom_glink_smem_register' qcom_common.c:(.text+0x160): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `qcom_glink_smem_register' Out of the three PIL driver instances, QCOM_ADSP_PIL already has a Kconfig dependency to prevent this from happening, but the other two do not. This adds the same dependency there. Fixes: eea07023e6d9 ("remoteproc: qcom: adsp: Allow defining GLINK edge") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]>
2017-10-10remoteproc: imx_rproc: fix a couple off by one bugsDan Carpenter1-2/+2
The priv->mem[] array has IMX7D_RPROC_MEM_MAX elements so the > should be >= to avoid writing one element beyond the end of the array. Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]>
2017-10-10rpmsg: glink: Fix memory leak in qcom_glink_alloc_intent()Dan Carpenter1-3/+8
We need to free "intent" and "intent->data" on a couple error paths. Fixes: 933b45da5d1d ("rpmsg: glink: Add support for TX intents") Acked-by: Sricharan R <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]>
2017-10-10rpmsg: glink: Unlock on error in qcom_glink_request_intent()Dan Carpenter1-1/+2
If qcom_glink_tx() fails, then we need to unlock before returning the error code. Fixes: 27b9c5b66b23 ("rpmsg: glink: Request for intents when unavailable") Acked-by: Sricharan R <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]>
2017-10-10Merge tag 'f2fs-for-4.14-rc5' of ↵Linus Torvalds3-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs Pull f2fs fix from Jaegeuk Kim: "This contains one bug fix which causes a kernel panic during fstrim introduced in 4.14-rc1" * tag 'f2fs-for-4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs: f2fs: fix potential panic during fstrim
2017-10-10Merge tag 'linux-kselftest-4.14-rc5-fixes' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fixes from Shuah Khan: - fix for x86: sysret_ss_attrs test build failure preventing the x86 tests from running - fix mqueue: fix regression in silencing test run output * tag 'linux-kselftest-4.14-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: mqueue: fix regression in silencing output from RUN_TESTS selftests: x86: sysret_ss_attrs doesn't build on a PIE build
2017-10-10iommu/amd: Do not disable SWIOTLB if SME is activeTom Lendacky1-4/+6
When SME memory encryption is active it will rely on SWIOTLB to handle DMA for devices that cannot support the addressing requirements of having the encryption mask set in the physical address. The IOMMU currently disables SWIOTLB if it is not running in passthrough mode. This is not desired as non-PCI devices attempting DMA may fail. Update the code to check if SME is active and not disable SWIOTLB. Fixes: 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption") Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2017-10-10Merge tag 'perf-urgent-for-mingo-4.14-20171010' of ↵Ingo Molnar5-22/+50
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: - Unbreak 'perf record' for arm/arm64 with events with explicit PMU (Mark Rutland) - Add missing separator for "perf script -F ip,brstack" (and brstackoff) (Mark Santaniello) - One line, comment only, sync kernel ABI header with tooling header (Arnaldo Carvalho de Melo) Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2017-10-11crypto: shash - Fix zero-length shash ahash digest crashHerbert Xu1-3/+5
The shash ahash digest adaptor function may crash if given a zero-length input together with a null SG list. This is because it tries to read the SG list before looking at the length. This patch fixes it by checking the length first. Cc: <[email protected]> Reported-by: Stephan Müller<[email protected]> Signed-off-by: Herbert Xu <[email protected]> Tested-by: Stephan Müller <[email protected]>
2017-10-10quota: Generate warnings for DQUOT_SPACE_NOFAIL allocationsJan Kara1-11/+16
Eryu has reported that since commit 7b9ca4c61bc2 "quota: Reduce contention on dq_data_lock" test generic/233 occasionally fails. This is caused by the fact that since that commit we don't generate warning and set grace time for quota allocations that have DQUOT_SPACE_NOFAIL set (these are for example some metadata allocations in ext4). We need these allocations to behave regularly wrt warning generation and grace time setting so fix the code to return to the original behavior. Reported-and-tested-by: Eryu Guan <[email protected]> CC: [email protected] Fixes: 7b9ca4c61bc278b771fb57d6290a31ab1fc7fdac Signed-off-by: Jan Kara <[email protected]>
2017-10-10i40e: Fix memory leak related filter programming statusAlexander Duyck1-27/+36
It looks like we weren't correctly placing the pages from buffers that had been used to return a filter programming status back on the ring. As a result they were being overwritten and tracking of the pages was lost. This change works to correct that by incorporating part of i40e_put_rx_buffer into the programming status handler code. As a result we should now be correctly placing the pages for those buffers on the re-allocation list instead of letting them stay in place. Fixes: 0e626ff7ccbf ("i40e: Fix support for flow director programming status") Reported-by: Anders K. Pedersen <[email protected]> Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Anders K Pedersen <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2017-10-10i40e: Fix comment about locking for __i40e_read_nvm_word()Stefano Brivio1-1/+1
Caller needs to acquire the lock. Called functions will not. Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update") Signed-off-by: Stefano Brivio <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2017-10-10KVM: MMU: always terminate page walks at level 1Ladi Prosek2-8/+9
is_last_gpte() is not equivalent to the pseudo-code given in commit 6bb69c9b69c31 ("KVM: MMU: simplify last_pte_bitmap") because an incorrect value of last_nonleaf_level may override the result even if level == 1. It is critical for is_last_gpte() to return true on level == 1 to terminate page walks. Otherwise memory corruption may occur as level is used as an index to various data structures throughout the page walking code. Even though the actual bug would be wherever the MMU is initialized (as in the previous patch), be defensive and ensure here that is_last_gpte() returns the correct value. This patch is also enough to fix CVE-2017-12188. Fixes: 6bb69c9b69c315200ddc2bc79aee14c0184cf5b2 Cc: [email protected] Cc: Andy Honig <[email protected]> Signed-off-by: Ladi Prosek <[email protected]> [Panic if walk_addr_generic gets an incorrect level; this is a serious bug and it's not worth a WARN_ON where the recovery path might hide further exploitable issues; suggested by Andrew Honig. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2017-10-10KVM: nVMX: update last_nonleaf_level when initializing nested EPTLadi Prosek1-0/+1
The function updates context->root_level but didn't call update_last_nonleaf_level so the previous and potentially wrong value was used for page walks. For example, a zero value of last_nonleaf_level would allow a potential out-of-bounds access in arch/x86/mmu/paging_tmpl.h's walk_addr_generic function (CVE-2017-12188). Fixes: 155a97a3d7c78b46cef6f1a973c831bc5a4f82bb Signed-off-by: Ladi Prosek <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2017-10-10xen/vcpu: Use a unified name about cpu hotplug state for pv and pvhvmZhenzhong Duan1-2/+2
As xen_cpuhp_setup is called by PV and PVHVM, the name of "x86/xen/hvm_guest" is confusing. Signed-off-by: Zhenzhong Duan <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
2017-10-10ALSA: usb-audio: Kill stray URB at exitingTakashi Iwai2-2/+12
USB-audio driver may leave a stray URB for the mixer interrupt when it exits by some error during probe. This leads to a use-after-free error as spotted by syzkaller like: ================================================================== BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x23d/0x350 mm/kasan/report.c:409 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430 snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 .... Allocated by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772 kmalloc ./include/linux/slab.h:493 kzalloc ./include/linux/slab.h:666 snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540 create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618 .... Freed by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524 slab_free_hook mm/slub.c:1390 slab_free_freelist_hook mm/slub.c:1412 slab_free mm/slub.c:2988 kfree+0xf6/0x2f0 mm/slub.c:3919 snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244 snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250 __snd_device_free+0x1ff/0x380 sound/core/device.c:91 snd_device_free_all+0x8f/0xe0 sound/core/device.c:244 snd_card_do_free sound/core/init.c:461 release_card_device+0x47/0x170 sound/core/init.c:181 device_release+0x13f/0x210 drivers/base/core.c:814 .... Actually such a URB is killed properly at disconnection when the device gets probed successfully, and what we need is to apply it for the error-path, too. In this patch, we apply snd_usb_mixer_disconnect() at releasing. Also introduce a new flag, disconnected, to struct usb_mixer_interface for not performing the disconnection procedure twice. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-10-10x86/hyperv: Fix hypercalls with extended CPU ranges for TLB flushingMarcelo Henrique Cerri1-3/+3
Do not consider the fixed size of hv_vp_set when passing the variable header size to hv_do_rep_hypercall(). The Hyper-V hypervisor specification states that for a hypercall with a variable header only the size of the variable portion should be supplied via the input control. For HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX calls that means the fixed portion of hv_vp_set should not be considered. That fixes random failures of some applications that are unexpectedly killed with SIGBUS or SIGSEGV. Signed-off-by: Marcelo Henrique Cerri <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Jork Loeser <[email protected]> Cc: Josh Poulson <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Simon Xiao <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vitaly Kuznetsov <[email protected]> Cc: [email protected] Fixes: 628f54cc6451 ("x86/hyper-v: Support extended CPU ranges for TLB flush hypercalls") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-10x86/hyperv: Don't use percpu areas for pcpu_flush/pcpu_flush_ex structuresVitaly Kuznetsov1-6/+28
hv_do_hypercall() does virt_to_phys() translation and with some configs (CONFIG_SLAB) this doesn't work for percpu areas, we pass wrong memory to hypervisor and get #GP. We could use working slow_virt_to_phys() instead but doing so kills the performance. Move pcpu_flush/pcpu_flush_ex structures out of percpu areas and allocate memory on first call. The additional level of indirection gives us a small performance penalty, in future we may consider introducing hypercall functions which avoid virt_to_phys() conversion and cache physical addresses of pcpu_flush/pcpu_flush_ex structures somewhere. Reported-by: Simon Xiao <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Jork Loeser <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-10x86/hyperv: Clear vCPU banks between calls to avoid flushing unneeded vCPUsVitaly Kuznetsov3-5/+18
hv_flush_pcpu_ex structures are not cleared between calls for performance reasons (they're variable size up to PAGE_SIZE each) but we must clear hv_vp_set.bank_contents part of it to avoid flushing unneeded vCPUs. The rest of the structure is formed correctly. To do the clearing in an efficient way stash the maximum possible vCPU number (this may differ from Linux CPU id). Reported-by: Jork Loeser <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-10perf/x86/intel/uncore: Fix memory leaks on allocation failuresColin Ian King1-2/+10
Currently if an allocation fails then the error return paths don't free up any currently allocated pmus[].boxes and pmus causing a memory leak. Add an error clean up exit path that frees these objects. Detected by CoverityScan, CID#711632 ("Resource Leak") Signed-off-by: Colin Ian King <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: 087bfbb03269 ("perf/x86: Add generic Intel uncore PMU support") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-10x86/unwind: Disable unwinder warnings on 32-bitJosh Poimboeuf1-0/+7
x86-32 doesn't have stack validation, so in most cases it doesn't make sense to warn about bad frame pointers. Reported-by: Tetsuo Handa <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Byungchul Park <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: LKP <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/a69658760800bf281e6353248c23e0fa0acf5230.1507597785.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>
2017-10-10x86/unwind: Align stack pointer in unwinder dumpJosh Poimboeuf1-1/+2
When printing the unwinder dump, the stack pointer could be unaligned, for one of two reasons: - stack corruption; or - GCC created an unaligned stack. There's no way for the unwinder to tell the difference between the two, so we have to assume one or the other. GCC unaligned stacks are very rare, and have only been spotted before GCC 5. Presumably, if we're doing an unwinder stack dump, stack corruption is more likely than a GCC unaligned stack. So always align the stack before starting the dump. Reported-and-tested-by: Tetsuo Handa <[email protected]> Reported-and-tested-by: Fengguang Wu <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Byungchul Park <[email protected]> Cc: LKP <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/2f540c515946ab09ed267e1a1d6421202a0cce08.1507597785.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.