commit dec1dc2a0ee8e929c12360c01f211daad862e96c Author: Greg Kroah-Hartman Date: Mon May 8 07:46:17 2017 +0200 Linux 4.4.67 commit 3b9983bb354eb107808a1fcf2eac569fd51c0595 Author: Adrian Salido Date: Thu Apr 27 10:32:55 2017 -0700 dm ioctl: prevent stack leak in dm ioctl call commit 4617f564c06117c7d1b611be49521a4430042287 upstream. When calling a dm ioctl that doesn't process any data (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct dm_ioctl are left initialized. Current code is incorrectly extending the size of data copied back to user, causing the contents of kernel stack to be leaked to user. Fix by only copying contents before data and allow the functions processing the ioctl to override. Signed-off-by: Adrian Salido Reviewed-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit da1ce38aaac7f08d319b4b76130aa4fd27c4489f Author: J. Bruce Fields Date: Fri Apr 21 15:26:30 2017 -0400 nfsd: stricter decoding of write-like NFSv2/v3 ops commit 13bf9fbff0e5e099e2b6f003a0ab8ae145436309 upstream. The NFSv2/v3 code does not systematically check whether we decode past the end of the buffer. This generally appears to be harmless, but there are a few places where we do arithmetic on the pointers involved and don't account for the possibility that a length could be negative. Add checks to catch these. Reported-by: Tuomas Haanpää Reported-by: Ari Kauppi Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 35e13333c217f0255a1e657ce075f0f72bc6383c Author: J. Bruce Fields Date: Tue Apr 25 16:21:34 2017 -0400 nfsd4: minor NFSv2/v3 write decoding cleanup commit db44bac41bbfc0c0d9dd943092d8bded3c9db19b upstream. Use a couple shortcuts that will simplify a following bugfix. (Minor backporting required to account for a change from f34b95689d2c "The NFSv2/NFSv3 server does not handle zero length WRITE requests correctly".) Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 16fb859f9b2bb246a18b4d0edc605774193c33b7 Author: Jaegeuk Kim Date: Tue Apr 12 16:05:36 2016 -0700 ext4/fscrypto: avoid RCU lookup in d_revalidate commit 03a8bb0e53d9562276045bdfcf2b5de2e4cff5a1 upstream. As Al pointed, d_revalidate should return RCU lookup before using d_inode. This was originally introduced by: commit 34286d666230 ("fs: rcu-walk aware d_revalidate method"). Reported-by: Al Viro Signed-off-by: Jaegeuk Kim Cc: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 41948f88a521b95e8abc793602015a6d45f52a06 Author: Theodore Ts'o Date: Sat Mar 26 16:15:42 2016 -0400 ext4 crypto: use dget_parent() in ext4_d_revalidate() commit 3d43bcfef5f0548845a425365011c499875491b0 upstream. This avoids potential problems caused by a race where the inode gets renamed out from its parent directory and the parent directory is deleted while ext4_d_revalidate() is running. Fixes: 28b4c263961c Reported-by: Al Viro Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 2faff9d1dfc560da3bfba6a8ab0c30246fd6c1cb Author: Theodore Ts'o Date: Sun Feb 7 19:35:05 2016 -0500 ext4 crypto: revalidate dentry after adding or removing the key commit 28b4c263961c47da84ed8b5be0b5116bad1133eb upstream. Add a validation check for dentries for encrypted directory to make sure we're not caching stale data after a key has been added or removed. Also check to make sure that status of the encryption key is updated when readdir(2) is executed. Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit e2968fb8e7980dccc199dac2593ad476db20969f Author: Richard Weinberger Date: Fri Sep 30 01:49:55 2016 -0400 ext4: require encryption feature for EXT4_IOC_SET_ENCRYPTION_POLICY commit 9a200d075e5d05be1fcad4547a0f8aee4e2f9a04 upstream. ...otherwise an user can enable encryption for certain files even when the filesystem is unable to support it. Such a case would be a filesystem created by mkfs.ext4's default settings, 1KiB block size. Ext4 supports encyption only when block size is equal to PAGE_SIZE. But this constraint is only checked when the encryption feature flag is set. Signed-off-by: Richard Weinberger Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit fee1f42b961e6cc3ec570e1fdba224d7d49b517d Author: Arnd Bergmann Date: Thu May 4 22:52:03 2017 +0200 IB/ehca: fix maybe-uninitialized warnings The driver causes two warnings about possibly uninitialized variables: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf': drivers/infiniband/hw/ehca/ehca_mrmw.c:1908:4: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/infiniband/hw/ehca/ehca_mrmw.c:1924:14: note: 'prev_pgaddr' was declared here drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_reg_mr': drivers/infiniband/hw/ehca/ehca_mrmw.c:2430:5: warning: 'hret' may be used uninitialized in this function [-Wmaybe-uninitialized] The first one is definitely a false positive, the second one may or may not be one. In both cases, adding an intialization is the safe and easy workaround. The driver was removed in mainline in commit e581d111dad3 ("staging/rdma: remove deprecated ehca driver"), in linux-4.6. In 4.4, the file is located in drivers/staging/rdma/ehca/ehca_mrmw.c, and the fix still applies. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 56cd2ed3e25ad14a49b99cbd4068aeaaa422fa32 Author: Arnd Bergmann Date: Thu May 4 22:52:02 2017 +0200 IB/qib: rename BITS_PER_PAGE to RVT_BITS_PER_PAGE We get this build warning on arm64 drivers/infiniband/hw/qib/qib_qp.c:44:0: error: "BITS_PER_PAGE" redefined [-Werror] #define BITS_PER_PAGE (PAGE_SIZE*BITS_PER_BYTE) This is fixed upstream in commit 898fa52b4ac3 ("IB/qib: Remove qpn, qp tables and related variables from qib"), which does a lot of other things as well. Instead, I just backport the rename of the local BITS_PER_PAGE definition to RVT_BITS_PER_PAGE. The driver first showed up in linux-2.6.35, and the fixup should still apply to that. The upstream fix went into v4.6, so we could apply this workaround to both 3.18 and 4.4. Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit a8d47b4b3cb654c161c7f24d731ea4f3963748b1 Author: Ross Lagerwall Date: Wed May 3 09:44:19 2017 +0100 netlink: Allow direct reclaim for fallback allocation The backport of d35c99ff77ec ("netlink: do not enter direct reclaim from netlink_dump()") to the 4.4 branch (first in 4.4.32) mistakenly removed direct claim from the initial large allocation _and_ the fallback allocation which means that allocations can spuriously fail. Fix the issue by adding back the direct reclaim flag to the fallback allocation. Fixes: 6d123f1d396b ("netlink: do not enter direct reclaim from netlink_dump()") Signed-off-by: Ross Lagerwall Signed-off-by: Greg Kroah-Hartman commit 35c9bfa51154cc3519e93970c69afe13f93757ac Author: Gabriel Krisman Bertazi Date: Wed Dec 28 16:42:00 2016 -0200 8250_pci: Fix potential use-after-free in error path commit c130b666a9a711f985a0a44b58699ebe14bb7245 upstream. Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") introduces a potential use-after-free in case the pciserial_init_ports call in serial8250_io_resume fails, which may happen if a memory allocation fails or if the .init quirk failed for whatever reason). If this happen, further pci_get_drvdata will return a pointer to freed memory. This patch reworks the PCI recovery resume hook to restore the old priv structure in this case, which should be ok, since the ports were already detached. Such error during recovery causes us to give up on the recovery. Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") Reported-by: Michal Suchanek Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Guilherme G. Piccoli Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman commit 6f81dea4037c878e27e3cb25cabc85c2f897fdfd Author: Matthew R. Ochs Date: Fri Sep 2 15:40:03 2016 -0500 scsi: cxlflash: Improve EEH recovery time commit 05dab43230fdc0d14ca885b473a2740fe017ecb1 upstream. When an EEH occurs during device initialization, the port timeout logic can cause excessive delays as MMIO reads will fail. Depending on where they are experienced, these delays can lead to a prolonged reset, causing an unnecessary triggering of other timeout logic in the SCSI stack or user applications. To expedite recovery, the port timeout logic is updated to decay the timeout at a much faster rate when in the presence of a likely EEH frozen event. Signed-off-by: Matthew R. Ochs Acked-by: Uma Krishnan Signed-off-by: Martin K. Petersen Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman commit 24d17d7853fa64189d32ac6416c6cacc3fed449c Author: Matthew R. Ochs Date: Fri Sep 2 15:39:30 2016 -0500 scsi: cxlflash: Fix to avoid EEH and host reset collisions commit 1d3324c382b1a617eb567e3650dcb51f22dfec9a upstream. The EEH reset handler is ignorant to the current state of the driver when processing a frozen event and initiating a device reset. This can be an issue if an EEH event occurs while a user or stack initiated reset is executing. More specifically, if an EEH occurs while the SCSI host reset handler is active, the reset initiated by the EEH thread will likely collide with the host reset thread. This can leave the device in an inconsistent state, or worse, cause a system crash. As a remedy, the EEH handler is updated to evaluate the device state and take appropriate action (proceed, wait, or disconnect host). The host reset handler is also updated to handle situations where an EEH occurred during a host reset. In such situations, the host reset handler will delay reporting back a success to give the EEH reset an opportunity to complete. Signed-off-by: Matthew R. Ochs Acked-by: Uma Krishnan Signed-off-by: Martin K. Petersen Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman commit 69a9e016f0cc091f225a2c485c66bd7703f144ee Author: Uma Krishnan Date: Fri Sep 2 15:38:48 2016 -0500 scsi: cxlflash: Scan host only after the port is ready for I/O commit bbbfae962b7c221237c0f92547ee0c83f7204747 upstream. When a port link is established, the AFU sends a 'link up' interrupt. After the link is up, corresponding initialization steps are performed on the card. Following that, when the card is ready for I/O, the AFU sends 'login succeeded' interrupt. Today, cxlflash invokes scsi_scan_host() upon receipt of both interrupts. SCSI commands sent to the port prior to the 'login succeeded' interrupt will fail with 'port not available' error. This is not desirable. Moreover, when async_scan is active for the host, subsequent scan calls are terminated with error. Due to this, the scsi_scan_host() call performed after 'login succeeded' interrupt could portentially return error and the devices may not be scanned properly. To avoid this problem, scsi_scan_host() should be called only after the 'login succeeded' interrupt. Signed-off-by: Uma Krishnan Acked-by: Matthew R. Ochs Signed-off-by: Martin K. Petersen Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman commit ec2170f98f9a218c62b9d49163dbbd0d8897a2a4 Author: Arnd Bergmann Date: Fri Jan 29 12:39:15 2016 +0100 net: tg3: avoid uninitialized variable warning commit e434e04110704eb91acfecbd0fb8ca8e2da9c29b upstream. The tg3_set_eeprom() function correctly initializes the 'start' variable, but gcc generates a false warning: drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom': drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] I have not come up with a way to restructure the code in a way that avoids the warning without making it less readable, so this adds an initialization for the declaration to shut up that warning. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fd79e436325841863d070f8e72246b437c0f5a15 Author: Arnd Bergmann Date: Mon Feb 29 13:20:28 2016 +0100 mtd: avoid stack overflow in MTD CFI code commit fddcca5107051adf9e4481d2a79ae0616577fd2c upstream. When map_word gets too large, we use a lot of kernel stack, and for MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended 1024 bytes in a number of functions: drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers': drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize': drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=] This can be avoided if all operations on the map word are done indirectly and the stack gets reused between the calls. We can mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other bank width is enabled, we also need to use a non-constant map_bankwidth() to convince the compiler to use less stack. Signed-off-by: Arnd Bergmann [Brian: this patch mostly achieves its goal by forcing MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit mappings; the rest of the change is mostly a wash, though it helps reduce stack size slightly. If we really care about supporting 256-bit mappings though, we should consider rewriting some of this code to avoid keeping and assigning so many 256-bit objects on the stack.] Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit ee6b88767e872fcc7af8e786a05d29d1ba229e75 Author: Lars Ellenberg Date: Fri Mar 20 15:47:22 2015 +0100 drbd: avoid redefinition of BITS_PER_PAGE commit 2630628b2dbc3fc320aafaf84836119e4e3d62f1 upstream. Apparently we now implicitly get definitions for BITS_PER_PAGE and BITS_PER_PAGE_MASK from the pid_namespace.h Instead of renaming our defines, I chose to define only if not yet defined, but to double check the value if already defined. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 938206b8d7980c60644d2ac46b13c3d236cb3eab Author: Arnd Bergmann Date: Mon Jul 4 17:07:45 2016 +0200 ALSA: ppc/awacs: shut up maybe-uninitialized warning commit b268c34e5ee92a4cc3099b0caaf26e6bfbdf0f18 upstream. The awacs sound driver produces a false-positive warning in ppc64_defconfig: sound/ppc/awacs.c: In function 'snd_pmac_awacs_init': include/sound/control.h:219:9: warning: 'master_vol' may be used uninitialized in this function [-Wmaybe-uninitialized] I haven't come up with a good way to rewrite the code to avoid the warning, so here is a bad one: I initialize the variable before the conditionall initialization so gcc no longer has to worry about it. Signed-off-by: Arnd Bergmann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2b3b19acfde4a01a327f257bd6a0a85ef6159d8 Author: Takashi Iwai Date: Mon Apr 24 14:09:55 2017 +0200 ASoC: intel: Fix PM and non-atomic crash in bytcr drivers commit 6e4cac23c5a648d50b107d1b53e9c4e1120c7943 upstream. The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry the ignore_suspend flag, and this prevents the suspend/resume working properly while the stream is running, since SST core code has the check of the running streams and returns -EBUSY. Drop these superfluous flags for fixing the behavior. Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE definitions, which leads to the kernel Oops at suspend/resume like: BUG: scheduling while atomic: systemd-sleep/3144/0x00000003 Call Trace: dump_stack+0x5c/0x7a __schedule_bug+0x55/0x70 __schedule+0x63c/0x8c0 schedule+0x3d/0x90 schedule_timeout+0x16b/0x320 ? del_timer_sync+0x50/0x50 ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? remove_wait_queue+0x60/0x60 ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core] ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core] .... This patch addresses these appropriately, too. [tiwai: applied only to bytcr_rt5640 as bytcr_rt5651 isn't present in 4.4.x yet] Signed-off-by: Takashi Iwai Acked-by: Vinod Koul Signed-off-by: Mark Brown Cc: # v4.1+ Signed-off-by: Greg Kroah-Hartman commit 6c106b55eb477c33c3e7626586cae899df0efce7 Author: Sachin Prabhu Date: Fri Mar 3 15:41:38 2017 -0800 Handle mismatched open calls commit 38bd49064a1ecb67baad33598e3d824448ab11ec upstream. A signal can interrupt a SendReceive call which result in incoming responses to the call being ignored. This is a problem for calls such as open which results in the successful response being ignored. This results in an open file resource on the server. The patch looks into responses which were cancelled after being sent and in case of successful open closes the open fids. For this patch, the check is only done in SendReceive2() RH-bz: 1403319 Signed-off-by: Sachin Prabhu Reviewed-by: Pavel Shilovsky Acked-by: Sachin Prabhu Signed-off-by: Pavel Shilovsky Signed-off-by: Greg Kroah-Hartman commit 911bd54922cdcc259daf73cb1a3a9d0305b9061d Author: Thomas Gleixner Date: Tue Jan 31 15:24:03 2017 +0100 timerfd: Protect the might cancel mechanism proper commit 1e38da300e1e395a15048b0af1e5305bd91402f6 upstream. The handling of the might_cancel queueing is not properly protected, so parallel operations on the file descriptor can race with each other and lead to list corruptions or use after free. Protect the context for these operations with a seperate lock. The wait queue lock cannot be reused for this because that would create a lock inversion scenario vs. the cancel lock. Replacing might_cancel with an atomic (atomic_t or atomic bit) does not help either because it still can race vs. the actual list operation. Reported-by: Dmitry Vyukov Signed-off-by: Thomas Gleixner Cc: "linux-fsdevel@vger.kernel.org" Cc: syzkaller Cc: Al Viro Cc: linux-fsdevel@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman