aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-10-12MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpcThomas Huth1-1/+1
Paul is handling almost all of the powerpc related KVM patches nowadays, so he should be mentioned in the MAINTAINERS file accordingly. Signed-off-by: Thomas Huth <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2017-10-12KVM: nVMX: fix guest CR4 loading when emulating L2 to L1 exitHaozhong Zhang1-1/+1
When KVM emulates an exit from L2 to L1, it loads L1 CR4 into the guest CR4. Before this CR4 loading, the guest CR4 refers to L2 CR4. Because these two CR4's are in different levels of guest, we should vmx_set_cr4() rather than kvm_set_cr4() here. The latter, which is used to handle guest writes to its CR4, checks the guest change to CR4 and may fail if the change is invalid. The failure may cause trouble. Consider we start a L1 guest with non-zero L1 PCID in use, (i.e. L1 CR4.PCIDE == 1 && L1 CR3.PCID != 0) and a L2 guest with L2 PCID disabled, (i.e. L2 CR4.PCIDE == 0) and following events may happen: 1. If kvm_set_cr4() is used in load_vmcs12_host_state() to load L1 CR4 into guest CR4 (in VMCS01) for L2 to L1 exit, it will fail because of PCID check. As a result, the guest CR4 recorded in L0 KVM (i.e. vcpu->arch.cr4) is left to the value of L2 CR4. 2. Later, if L1 attempts to change its CR4, e.g., clearing VMXE bit, kvm_set_cr4() in L0 KVM will think L1 also wants to enable PCID, because the wrong L2 CR4 is used by L0 KVM as L1 CR4. As L1 CR3.PCID != 0, L0 KVM will inject GP to L1 guest. Fixes: 4704d0befb072 ("KVM: nVMX: Exiting from L2 to L1") Cc: [email protected] Signed-off-by: Haozhong Zhang <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2017-10-12Merge tag 'fixes-for-v4.14-rc5' of ↵Greg Kroah-Hartman9-20/+62
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: USB: fixes for v4.14-rc5 A deadlock fix in dummy-hcd; Fixing a use-after-free bug in composite; Renesas got another fix for DMA programming (this time around a fix for receiving ZLP); Tegra PHY got a suspend fix; A memory leak on our configfs ABI got plugged. Other than these, a couple other minor fixes on usbtest.
2017-10-12iommu/exynos: Remove initconst attribute to avoid potential kernel oopsMarek Szyprowski1-1/+1
Exynos SYSMMU registers standard platform device with sysmmu_of_match table, what means that this table is accessed every time a new platform device is registered in a system. This might happen also after the boot, so the table must not be attributed as initconst to avoid potential kernel oops caused by access to freed memory. Fixes: 6b21a5db3642 ("iommu/exynos: Support for device tree") Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2017-10-12Merge tag 'drm-misc-fixes-2017-10-11' of ↵Dave Airlie2-5/+13
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Core Changes: - sync_file: Fix race in SYNC_IOC_FILE_INFO (John) - atomic_helper: Give up reference taken in suspend helper (Jeffy) Cc: John Einar Reitan <[email protected]> Cc: Jeffy Chen <[email protected]> * tag 'drm-misc-fixes-2017-10-11' of git://anongit.freedesktop.org/drm/drm-misc: sync_file: Return consistent status in SYNC_IOC_FILE_INFO drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
2017-10-11ACPI: properties: Fix __acpi_node_get_property_reference() return codesSakari Ailus1-4/+6
Fix more return codes for device property: Align return codes of __acpi_node_get_property_reference(). In particular, what was missed previously: -EPROTO could be returned in certain cases, now -EINVAL; -EINVAL was returned if the property was not found, now -ENOENT; -EINVAL was returned also if the index was higher than the number of entries in a package, now -ENOENT. Reported-by: Hyungwoo Yang <[email protected]> Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args) Signed-off-by: Sakari Ailus <[email protected]> Tested-by: Hyungwoo Yang <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-10-11ACPI: properties: Align return codes of __acpi_node_get_property_reference()Sakari Ailus2-10/+13
acpi_fwnode_get_reference_args(), the function implementing ACPI support for fwnode_property_get_reference_args(), returns directly error codes from __acpi_node_get_property_reference(). The latter uses different error codes than the OF implementation. In particular, the OF implementation uses -ENOENT to indicate that the property is not found, a reference entry is empty and there are no more references. Document and align the error codes for property for fwnode_property_get_reference_args() so that they match with of_parse_phandle_with_args(). Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args) Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-10-11Merge tag 'rpmsg-v4.14-fixes' of git://github.com/andersson/remoteprocLinus Torvalds1-4/+10
Pull rpmsg fixes from Bjorn Andersson: "This corrects two mistakes in the Qualcomm GLINK SMEM driver" * tag 'rpmsg-v4.14-fixes' of git://github.com/andersson/remoteproc: rpmsg: glink: Fix memory leak in qcom_glink_alloc_intent() rpmsg: glink: Unlock on error in qcom_glink_request_intent()
2017-10-11Merge tag 'rproc-v4.14-fixes' of git://github.com/andersson/remoteprocLinus Torvalds2-5/+6
Pull remoteproc fixes from Bjorn Andersson: "This fixes a couple of issues in the imx_rproc driver and corrects the Kconfig dependencies of the Qualcomm remoteproc drivers" * tag 'rproc-v4.14-fixes' of git://github.com/andersson/remoteproc: remoteproc: imx_rproc: fix return value check in imx_rproc_addr_init() remoteproc: qcom: fix RPMSG_QCOM_GLINK_SMEM dependencies remoteproc: imx_rproc: fix a couple off by one bugs
2017-10-11scsi: fc: check for rport presence in fc_block_scsi_ehJohannes Thumshirn1-0/+3
Coverity-scan recently found a possible NULL pointer dereference in fc_block_scsi_eh() as starget_to_rport() either returns the rport for the startget or NULL. While it is rather unlikely to have fc_block_scsi_eh() called without an rport associated it's a good idea to catch potential misuses of the API gracefully. Signed-off-by: Johannes Thumshirn <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2017-10-11scsi: qla2xxx: Fix uninitialized work elementQuinn Tran1-1/+2
Fixes following stack trace kernel: Call Trace: kernel: dump_stack+0x63/0x84 kernel: __warn+0xd1/0xf0 kernel: warn_slowpath_null+0x1d/0x20 kernel: __queue_work+0x37a/0x420 kernel: queue_work_on+0x27/0x40 kernel: queue_work+0x14/0x20 [qla2xxx] kernel: schedule_work+0x13/0x20 [qla2xxx] kernel: qla2x00_post_work+0xab/0xb0 [qla2xxx] kernel: qla2x00_post_aen_work+0x3b/0x50 [qla2xxx] kernel: qla2x00_async_event+0x20d/0x15d0 [qla2xxx] kernel: ? lock_timer_base+0x7d/0xa0 kernel: qla24xx_intr_handler+0x1da/0x310 [qla2xxx] kernel: qla2x00_poll+0x36/0x60 [qla2xxx] kernel: qla2x00_mailbox_command+0x659/0xec0 [qla2xxx] kernel: ? proc_create_data+0x7a/0xd0 kernel: qla25xx_init_rsp_que+0x15b/0x240 [qla2xxx] kernel: ? request_irq+0x14/0x20 [qla2xxx] kernel: qla25xx_create_rsp_que+0x256/0x3c0 [qla2xxx] kernel: qla2xxx_create_qpair+0x2af/0x5b0 [qla2xxx] kernel: qla2x00_probe_one+0x1107/0x1c30 [qla2xxx] Fixes: ec7193e26055 ("qla2xxx: Fix delayed response to command for loop mode/direct connect.") Cc: <[email protected]> # 4.13 Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2017-10-11remoteproc: imx_rproc: fix return value check in imx_rproc_addr_init()Wei Yongjun1-3/+2
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Reviewed-by: Oleksij Rempel <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]>
2017-10-11drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channelJani Nikula1-1/+1
While technically CHV isn't DDI, we do look at the VBT based DDI port info for HDMI DDC pin and DP AUX channel. (We call these "alternate", but they're really just something that aren't platform defaults.) In commit e4ab73a13291 ("drm/i915: Respect alternate_ddc_pin for all DDI ports") Ville writes, "IIRC there may be CHV system that might actually need this." I'm not sure why there couldn't be even more platforms that need this, but start conservative, and parse the info for CHV in addition to DDI. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100553 Reported-by: Marek Wilczewski <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d0815082cb98487618429b62414854137049b888.1506586821.git.jani.nikula@intel.com (cherry picked from commit 348e4058ebf53904e817eec7a1b25327143c2ed2) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-11scsi: libiscsi: fix shifting of DID_REQUEUE host byteJohannes Thumshirn1-1/+1
The SCSI host byte should be shifted left by 16 in order to have scsi_decide_disposition() do the right thing (.i.e. requeue the command). Signed-off-by: Johannes Thumshirn <[email protected]> Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common") Cc: Lee Duncan <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: Chris Leech <[email protected]> Acked-by: Lee Duncan <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2017-10-11xfs: handle error if xfs_btree_get_bufs failsEric Sandeen1-0/+8
Jason reported that a corrupted filesystem failed to replay the log with a metadata block out of bounds warning: XFS (dm-2): _xfs_buf_find: Block out of range: block 0x80270fff8, EOFS 0x9c40000 _xfs_buf_find() and xfs_btree_get_bufs() return NULL if that happens, and then when xfs_alloc_fix_freelist() calls xfs_trans_binval() on that NULL bp, we oops with: BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 We don't handle _xfs_buf_find errors very well, every caller higher up the stack gets to guess at why it failed. But we should at least handle it somehow, so return EFSCORRUPTED here. Reported-by: Jason L Tibbitts III <[email protected]> Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11xfs: reinit btree pointer on attr tree inactivation walkBrian Foster1-0/+2
xfs_attr3_root_inactive() walks the attr fork tree to invalidate the associated blocks. xfs_attr3_node_inactive() recursively descends from internal blocks to leaf blocks, caching block address values along the way to revisit parent blocks, locate the next entry and descend down that branch of the tree. The code that attempts to reread the parent block is unsafe because it assumes that the local xfs_da_node_entry pointer remains valid after an xfs_trans_brelse() and re-read of the parent buffer. Under heavy memory pressure, it is possible that the buffer has been reclaimed and reallocated by the time the parent block is reread. This means that 'btree' can point to an invalid memory address, lead to a random/garbage value for child_fsb and cause the subsequent read of the attr fork to go off the rails and return a NULL buffer for an attr fork offset that is most likely not allocated. Note that this problem can be manufactured by setting XFS_ATTR_BTREE_REF to 0 to prevent LRU caching of attr buffers, creating a file with a multi-level attr fork and removing it to trigger inactivation. To address this problem, reinit the node/btree pointers to the parent buffer after it has been re-read. This ensures btree points to a valid record and allows the walk to proceed. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11xfs: Fix bool initialization/comparisonThomas Meyer5-8/+8
Bool initializations should use true and false. Bool tests don't need comparisons. Signed-off-by: Thomas Meyer <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11xfs: don't change inode mode if ACL update failsDave Chinner1-6/+16
If we get ENOSPC half way through setting the ACL, the inode mode can still be changed even though the ACL does not exist. Reorder the operation to only change the mode of the inode if the ACL is set correctly. Whilst this does not fix the problem with crash consistency (that requires attribute addition to be a deferred op) it does prevent ENOSPC and other non-fatal errors setting an xattr to be handled sanely. This fixes xfstests generic/449. Signed-Off-By: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11xfs: move more RT specific code under CONFIG_XFS_RTDave Chinner3-0/+27
Various utility functions and interfaces that iterate internal devices try to reference the realtime device even when RT support is not compiled into the kernel. Make sure this code is excluded from the CONFIG_XFS_RT=n build, and where appropriate stub functions to return fatal errors if they ever get called when RT support is not present. Signed-Off-By: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11xfs: Don't log uninitialised fields in inode structuresDave Chinner3-58/+50
Prevent kmemcheck from throwing warnings about reading uninitialised memory when formatting inodes into the incore log buffer. There are several issues here - we don't always log all the fields in the inode log format item, and we never log the inode the di_next_unlinked field. In the case of the inode log format item, this is exacerbated by the old xfs_inode_log_format structure padding issue. Hence make the padded, 64 bit aligned version of the structure the one we always use for formatting the log and get rid of the 64 bit variant. This means we'll always log the 64-bit version and so recovery only needs to convert from the unpadded 32 bit version from older 32 bit kernels. Signed-Off-By: Dave Chinner <[email protected]> Tested-by: Tetsuo Handa <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-10-11media: dvb_frontend: only use kref after initializedMauro Carvalho Chehab1-4/+21
As reported by Laurent, when a DVB frontend need to register two drivers (e. g. a tuner and a demod), if the second driver fails to register (for example because it was not compiled), the error handling logic frees the frontend by calling dvb_frontend_detach(). That used to work fine, but changeset 1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend") added a kref at struct dvb_frontend. So, now, instead of just freeing the data, the error handling do a kref_put(). That works fine only after dvb_register_frontend() succeeds. While it would be possible to add a helper function that would be initializing earlier the kref, that would require changing every single DVB frontend on non-trivial ways, and would make frontends different than other drivers. So, instead of doing that, let's focus on the real issue: only call kref_put() after kref_init(). That's easy to check, as, when the dvb frontend is successfuly registered, it will allocate its own private struct. So, if such struct is allocated, it means that it is safe to use kref_put(). If not, then nobody is using yet the frontend, and it is safe to just deallocate it. Fixes: 1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend") Reported-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2017-10-119p: set page uptodate when required in write_end()Alexander Levin1-3/+7
Commit 77469c3f570 prevented setting the page as uptodate when we wrote the right amount of data, fix that. Fixes: 77469c3f570 ("9p: saner ->write_end() on failing copy into non-uptodate page") Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Alexander Levin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-10-11Merge tag 'gpio-v4.14-2' of ↵Linus Torvalds3-12/+17
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Here are some smallish GPIO fixes for v4.14. Like with pin control: some build/Kconfig noise and one serious bug in a specific driver. - Three Kconfig/build warning fixes - A fix for lost edge IRQs in the OMAP driver" * tag 'gpio-v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: omap: Fix lost edge interrupts gpio: omap: omap_gpio_show_rev is not __init gpio: acpi: work around false-positive -Wstring-overflow warning gpio: thunderx: select IRQ_DOMAIN_HIERARCHY instead of depends on
2017-10-11Merge tag 'pinctrl-v4.14-3' of ↵Linus Torvalds3-5/+14
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Two small things and a slightly larger thing in the Intel Cherryview. - Fix two build problems - Fix a regression on the Intel Cherryview interrupt path" * tag 'pinctrl-v4.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping pinctrl/amd: Fix build dependency on pinmux code pinctrl: bcm2835: fix build warning in bcm2835_gpio_irq_handle_bank
2017-10-11Merge branch 'for-linus' of ↵Linus Torvalds2-8/+21
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro: "Fairly old DIO bug caught by Andreas (3.10+) and several slightly younger blk_rq_map_user_iov() bugs, both on map and copy codepaths (Vitaly and me)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: bio_copy_user_iov(): don't ignore ->iov_offset more bio_map_user_iov() leak fixes fix unbalanced page refcounting in bio_map_user_iov direct-io: Prevent NULL pointer access in submit_page_section
2017-10-11x86/mm: Disable various instrumentations of mm/mem_encrypt.c and mm/tlb.cTom Lendacky1-2/+9
Some routines in mem_encrypt.c are called very early in the boot process, e.g. sme_enable(). When CONFIG_KCOV=y is defined the resulting code added to sme_enable() (and others) for KCOV instrumentation results in a kernel crash. Disable the KCOV instrumentation for mem_encrypt.c by adding KCOV_INSTRUMENT_mem_encrypt.o := n to arch/x86/mm/Makefile. In order to avoid other possible early boot issues, model mem_encrypt.c after head64.c in regards to tools. In addition to disabling KCOV as stated above and a previous patch that disables branch profiling, also remove the "-pg" CFLAG if CONFIG_FUNCTION_TRACER is enabled and set KASAN_SANITIZE to "n", each of which are done on a file basis. Reported-by: kernel test robot <[email protected]> Signed-off-by: Tom Lendacky <[email protected]> Reviewed-by: Borislav Petkov <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-11ALSA: caiaq: Fix stray URB at probe error pathTakashi Iwai1-3/+9
caiaq driver doesn't kill the URB properly at its error path during the probe, which may lead to a use-after-free error later. This patch addresses it. Reported-by: Johan Hovold <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-10-11HID: hid-elecom: extend to fix descriptor for HUGE trackballAlex Manoussakis4-4/+14
In addition to DEFT, Elecom introduced a larger trackball called HUGE, in both wired (M-HT1URBK) and wireless (M-HT1DRBK) versions. It has the same buttons and behavior as the DEFT. This patch adds the two relevant USB IDs to enable operation of the three Fn buttons on the top of the device. Cc: Diego Elio Petteno <[email protected]> Signed-off-by: Alex Manoussakis <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2017-10-11HID: usbhid: fix out-of-bounds bugJaejoong Kim1-1/+11
The hid descriptor identifies the length and type of subordinate descriptors for a device. If the received hid descriptor is smaller than the size of the struct hid_descriptor, it is possible to cause out-of-bounds. In addition, if bNumDescriptors of the hid descriptor have an incorrect value, this can also cause out-of-bounds while approaching hdesc->desc[n]. So check the size of hid descriptor and bNumDescriptors. BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20 Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261 CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #169 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __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+0x22f/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427 usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004 hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944 usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 Cc: [email protected] Reported-by: Andrey Konovalov <[email protected]> Signed-off-by: Jaejoong Kim <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
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-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 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-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]>
Powered by cgit, Gruvboxed by Blaster4385.