- 15 May, 2017 2 commits
-
-
Arnd Bergmann authored
commit ffb6e0c9 upstream. The platform_sysrq_reset_seq code was intended as a way for an embedded platform to provide its own sysrq sequence at compile time. After over two years, nobody has started using it in an upstream kernel, and the platforms that were interested in it have moved on to devicetree, which can be used to configure the sequence without requiring kernel changes. The method is also incompatible with the way that most architectures build support for multiple platforms into a single kernel. Now the code is producing warnings when built with gcc-5.1: drivers/tty/sysrq.c: In function 'sysrq_init': drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds] key = platform_sysrq_reset_seq[i]; We could fix this, but it seems unlikely that it will ever be used, so let's just remove the code instead. We still have the option to pass the sequence either in DT, using the kernel command line, or using the /sys/module/sysrq/parameters/reset_seq file. Fixes: 154b7a48 ("Input: sysrq - allow specifying alternate reset sequence") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cong Wang authored
commit b5c66bab upstream. posix_acl_update_mode() could possibly clear 'acl', if so we leak the memory pointed by 'acl'. Save this pointer before calling posix_acl_update_mode() and release the memory if 'acl' really gets cleared. Link: http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangcong@gmail.comSigned-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reported-by:
Mark Salyzyn <salyzyn@android.com> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Greg Kurz <groug@kaod.org> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 08 May, 2017 38 commits
-
-
Greg Kroah-Hartman authored
-
Adrian Salido authored
commit 4617f564 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 <salidoa@google.com> Reviewed-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Masahiro Yamada authored
commit de461993 upstream. If "make kvmconfig" is run with "-j" option, a warning message, "jobserver unavailable: using -j1. Add `+' to parent make rule.", is displayed. $ make -s defconfig *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # $ make -j8 kvmconfig Using ./.config as base Merging ./arch/x86/configs/kvm_guest.config [ snip ] # # merged configuration written to ./.config (needs make) # make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. scripts/kconfig/conf --oldconfig Kconfig [ snip ] # # configuration written to .config # Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Reviewed-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Arnd Bergmann authored
Picked from commit 287980e4 ("remove lots of IS_ERR_VALUE abuses") upstream. The original fix that was backported to 3.18 already addressed the warning in some configurations, but not in others, leaving us with the same output: ../fs/gfs2/dir.c: In function 'get_first_leaf': ../fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, bh_out); ^ ../fs/gfs2/dir.c: In function 'dir_split_leaf.isra.20': ../fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] This takes the approach that we took in later versions in mainline, but does not backport the entire patch, as that would be too large for stable and IIRC caused regressions in other drivers. Fixes: 9d46d31e ("gfs2: avoid uninitialized variable warning") Signed-off-by:
-
Jeff Kirsher authored
commit 30544af5 upstream. We were using s64 for lat_ns (latency nano-second value) since in our calculations a negative value could be a resultant. For negative values, we then assign lat_ns to be zero, so the value passed to do_div() was never negative, but do_div() expects the argument type to be u64, so do a cast to resolve a compile warning seen on PowerPC. CC: Yanjiang Jin <yanjiang.jin@windriver.com> CC: Yanir Lubetkin <yanirx.lubetkin@intel.com> Reported-by:
Yanjiang Jin <yanjiang.jin@windriver.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Rusty Russell authored
commit f36963c9 upstream. da91309e (cpumask: Utility function to set n'th cpu...) created a genuinely weird function. I never saw it before, it went through DaveM. (He only does this to make us other maintainers feel better about our own mistakes.) cpumask_set_cpu_local_first's purpose is say "I need to spread things across N online cpus, choose the ones on this numa node first"; you call it in a loop. It can fail. One of the two callers ignores this, the other aborts and fails the device open. It can fail in two ways: allocating the off-stack cpumask, or through a convoluted codepath which AFAICT can only occur if cpu_online_mask changes. Which shouldn't happen, because if cpu_online_mask can change while you call this, it could return a now-offline cpu anyway. It contains a nonsensical test "!cpumask_of_node(numa_node)". This was drawn to my attention by Geert, who said this causes a warning on Sparc. It sets a single bit in a cpumask instead of returning a cpu number, because that's what the callers want. It could be made more efficient by passing the previous cpu rather than an index, but that would be more invasive to the callers. [backporting for 3.18: only two callers exist, otherwise no change. The same warning shows up for "!cpumask_of_node()", and I thought about just addressing the warning, but using the whole fix seemed better in the end as one of the two callers also lacks the error handling] Fixes: da91309e Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased) Tested-by:
Amir Vadai <amirv@mellanox.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
commit 4a3893d0 upstream. Currently an allyesconfig build [gcc-4.9.1] can generate the following: WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in reference from the function cpumask_empty.constprop.3() to the variable .init.data:nmi_ipi_mask which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c. Normally we would not see a symbol entry for cpumask_empty since it is: static inline bool cpumask_empty(const struct cpumask *srcp) however in this case, the variant of the symbol gets emitted when GCC does constant propagation optimization. Fix things up so that any locally optimized constprop variants don't warn when accessing variables that live in the __init sections. [arnd: adapted text_sections definition to 3.18] Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Paul Gortmaker authored
commit 09c20c03 upstream. Currently the match() function supports a leading * to match any prefix and a trailing * to match any suffix. However there currently is not a combination of both that can be used to target matches of whole families of functions that share a common substring. Here we expand the *foo and foo* match to also support *foo* with the goal of targeting compiler generated symbol names that contain strings like ".constprop." and ".isra." Signed-off-by:
-
Arnd Bergmann authored
The advansys driver was converted to the proper DMA API in linux-4.2, but the 3.18-stable kernel still warns about this: drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp] The warning clearly is not helpful in 3.18 any more, it just clutters up the build log. This removes the warning instead, and clarifies the comment above it. Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Arnd Bergmann authored
We get a warning about a broken pointer conversion on 64-bit architectures: drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru': drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (p->virt, (void __user *)sg[i].addr_bus, ^ drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] ((void __user *)sg[j].addr_bus, sg_list[j].virt, ^ This has clearly never worked right, so we can add an #ifdef around the code. The driver was moved to staging in linux-4.0 and finally removed in 4.2, so upstream does not have a fix for it. The driver originally got this mostly right, though probably by accident. Fixes: f4c2c15b ("[PATCH] Convert i2o to compat_ioctl") Signed-off-by: -
Benjamin Romer authored
commit f84bd626 upstream. Properly handle the return value from queue_delayed_work() - it's a bool, not an int, so using a less than comparison isn't appropriate. This mistake was found by David Binderman <dcb314@hotmail.com>. [arnd: the fix is from 4.4 but needed some minor fixup to adapt to context changes] Signed-off-by:
Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by:
-
Ralf Baechle authored
commit 2d76e963 upstream. HOSTCC arch/mips/boot/elf2ecoff arch/mips/boot/elf2ecoff.c: In function ‘main’: arch/mips/boot/elf2ecoff.c:271:8: warning: variable ‘shstrtab’ set but not used [-Wunused-but-set-variable] char *shstrtab; Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Ralf Baechle authored
commit 26f7c4bd upstream. These are generated by very recent toolchains and result in an error message when attenpting to convert a kernel from ELF to ECOFF. Signed-off-by:
-
Arnd Bergmann authored
kernelci found build error on the 3.18 stable tree that don't show up in later versions: arch/mips/jz4740/irq.h:21:38: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] arch/mips/jz4740/irq.h:20:39: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] include/linux/irqdesc.h:92:33: error: 'NR_IRQS' undeclared here (not in a function) arch/mips/jz4740/irq.c:91:41: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/irq.c:68:6: error: conflicting types for 'jz4740_irq_resume' arch/mips/jz4740/irq.c:62:6: error: conflicting types for 'jz4740_irq_suspend' arch/mips/jz4740/irq.c:49:39: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/gpio.c:47:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:447:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:446:23: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:427:14: error: implicit declaration of function 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration] arch/mips/jz4740/gpio.c:269:9: error: implicit declaration of function 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration] The problem seems to be caused by commit 83bc7692 ("MIPS: JZ4740: Use generic irq chip") from linux-3.2, but only showed up in a defconfig build when qi_lb60_defconfig was added in linux-3.13 and that configuration never successfully built. The code has changed in a number of ways before 4.4, which builds fine. While I did not bisect the problem to a specific change, I found a simple fix by including the obviously missing header. Cc: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Stephen Rothwell authored
commit badbda53 upstream. pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and architecture, so use max_t(unsigned long, ...) when comparing it. fixes these warnings: In file included from include/asm-generic/bug.h:13:0, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/mm.h:8, from include/linux/memblock.h:18, from mm/cma.c:28: mm/cma.c: In function 'cma_init_reserved_mem': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ mm/cma.c:186:27: note: in expansion of macro 'max' alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); ^ mm/cma.c: In function 'cma_declare_contiguous': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ include/linux/kernel.h:747:9: note: in definition of macro 'max' typeof(y) _max2 = (y); ^ mm/cma.c:270:29: note: in expansion of macro 'max' (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)); ^ include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); ^ include/linux/kernel.h:747:21: note: in definition of macro 'max' typeof(y) _max2 = (y); ^ mm/cma.c:270:29: note: in expansion of macro 'max' (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)); ^ [akpm@linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/20160526150748.5be38a4f@canb.auug.org.auSigned-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Arnd Bergmann authored
commit 54309784 upstream. On a cross-toolchain without glibc support, libgcov may not be available, and attempting to build an arm64 kernel with GCOV enabled then results in a build error: /home/arnd/cross-gcc/lib/gcc/aarch64-linux/5.2.1/../../../../aarch64-linux/bin/ld: cannot find -lgcov We don't really want to link libgcov into the vdso anyway, so this patch just disables GCOV in the vdso directory, just as we do for most other architectures. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit 3e7a8716 upstream. Not all architectures are able to call __builtin_return_address(). On ARM, the mISDN code produces this warning: hardware/mISDN/w6692.c: In function 'w6692_dctrl': hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__, ^ hardware/mISDN/mISDNipac.c: In function 'open_dchannel': hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__, ^ In a lot of cases, this is relatively easy to work around by passing the value of __builtin_return_address(0) from the callers into the functions that want it. One exception is the indirect 'open' function call in struct isac_hw. While it would be possible to fix this as well, this patch only addresses the other callers properly and lets this one return the direct parent function, which should be good enough. Signed-off-by:
-
James Bottomley authored
commit e03c2da6 upstream. non-x86 builds want the #warning in the IPS code about compiling on the wrong architecture removed because it keeps triggering on their platforms build farms. Transform from a compile time warning into a runtime one with taint to preserve the original intent of the authors. Acked-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Arnd Bergmann authored
commit 7835bfb5 upstream. The return type of find_first_bit() is architecture specific, on ARM it is 'unsigned int', while the asm-generic code used on x86 and a lot of other architectures returns 'unsigned long'. When building the mlx5 driver on ARM, we get a warning about this: infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages': infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer types lacks a cast m = min(m, find_first_bit(&tmp, sizeof(tmp))); This patch changes the driver to use min_t to make it behave the same way on all architectures. Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
commit f3e2d56d upstream. Building an arm allmodconfig kernel triggers a lengthy but harmless warning in the isicom driver: drvers/tty/isicom.c: In function 'isicom_send_break': uapi/linux/swab.h:13:15: warning: integer overflow in expression [-Woverflow] (((__u16)(x) & (__u16)0x00ffU) << 8) | \ ^ uapi/linux/swab.h:107:2: note: in expansion of macro '___constant_swab16' ___constant_swab16(x) : \ ^ uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16' #define __cpu_to_le16(x) ((__force __le16)__swab16((x))) ^ linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16' #define cpu_to_le16 __cpu_to_le16 ^ include/asm/io.h:270:6: note: in expansion of macro 'cpu_to_le16' cpu_to_le16(v),__io(p)); }) ^ drivers/tty/isicom.c:1058:2: note: in expansion of macro 'outw' outw((length & 0xff00), base); ^ Apparently, the problem is related to the fact that the value 0xff00, when used as a 16-bit number, is negative and passed into bitwise operands of the generic byte swapping code. Marking the input argument as unsigned in both technically correct and avoids the warning. Signed-off-by:
-
Arnd Bergmann authored
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 e581d111 ("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 authored
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 898fa52b ("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: f931551b ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by:
-
Arnd Bergmann authored
The driver uses a 32-bit variable to store a pointer, causing a couple of warnings: ../drivers/staging/bcm/CmHost.c: In function 'StoreCmControlResponseMessage': ../drivers/staging/bcm/CmHost.c:1503:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( ^ ../drivers/staging/bcm/CmHost.c:1546:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( ^ ../drivers/staging/bcm/CmHost.c:1564:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] (struct bcm_connect_mgr_params *) ntohl( I fixed other warnings in an earlier commit 9f1c75ac ("staging/bcm: fix most build warnings"), but couldn't figure out what was the intended behavior on 64-bit machines here. The driver was removed in linux-3.19, commit d09e9b16 ("staging: bcm: remove driver") which explains that it never worked on 64-bit machines. This adds a Kconfig dependency instead to prevent it from being built in the known broken configuration. This workaround applies to v2.6.37 or higher. Fixes: f8942e07 ("staging: Beeceem USB Wimax driver") Signed-off-by:
-
Arnd Bergmann authored
gcc-6 produces a harmless warning: drivers/staging/imx-drm/imx-hdmi.c: In function 'hdmi_config_AVI': drivers/staging/imx-drm/imx-hdmi.c:967:2: error: this 'else' clause does not guard... [-Werror=misleading-indentation] Commit d083c312 ("drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little") in linux-4.3 fixes this with a larger rewrite that is not applicable here. After that rewrite, the variable that gets assigned here no longer exists. The assignment is rather pointless here, as we just set a variable to zero that is later added into another variable using a bitwise or operator, and that has no effect, so I'm just changing the indentation here to shut up the warning. The driver was originally merged in linux-3.13, and the fix applies to all versions between that and 4.2. Fixes: 9aaf880e ("imx-drm: Add mx6 hdmi transmitter support") Signed-off-by:
-
Arnd Bergmann authored
We get a warning for the large stack usage in some configurations: drivers/staging/vt6655/device_main.c: In function 'device_ioctl': drivers/staging/vt6655/device_main.c:2974:1: warning: the frame size of 1304 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is addressed in linux-3.19 with commit 67013f2c ("staging: vt6655: mac80211 conversion add main mac80211 functions"), which obsoletes the device_ioctl() function, but as that does not apply to stable kernels, this picks an easier way out by using dynamic allocation. The driver was merged in 2.6.31, and the fix applies to all versions before 3.19. Fixes: 5449c685 ("Staging: Add pristine upstream vt6655 driver sources") Signed-off-by:
-
Fabio Estevam authored
commit 06f9eb88 upstream. Building arm64.allmodconfig leads to the following warning: usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined #define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE) ^ In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0, from /home/build/work/batch/include/linux/clocksource.h:19, from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19, from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27, from /home/build/work/batch/arch/arm64/include/asm/timex.h:19, from /home/build/work/batch/include/linux/timex.h:65, from /home/build/work/batch/include/linux/sched.h:19, from /home/build/work/batch/arch/arm64/include/asm/compat.h:25, from /home/build/work/batch/arch/arm64/include/asm/stat.h:23, from /home/build/work/batch/include/linux/stat.h:5, from /home/build/work/batch/include/linux/module.h:10, from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19: arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition #define NCAPS 2 So add a ARM64 prefix to avoid such problem. Reported-by:
Olof's autobuilder <build@lixom.net> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arnd Bergmann authored
This shuts up a warning in the 3.18-stable series that has been fixed in newer kernels with commit 498a92d4 ("ARM: cns3xxx: pci: avoid potential stack overflow"): arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:313:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The fix that went into v4.4 is known to be buggy and was later fixed again with commit 88e9da9a ("CNS3xxx: Fix PCI cns3xxx_write_config()"). While we could backport both to 3.18, they are fairly invasive and the warning is definitely harmless here as the call chain is known to not overflow the stack of the init task. This simply adds a Makefile flag to extend the limit for this one file. Signed-off-by:
-
Kirill A. Shutemov authored
commit 6b7339f4 upstream. Reading page fault handler code I've noticed that under right circumstances kernel would map anonymous pages into file mappings: if the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated on ->mmap(), kernel would handle page fault to not populated pte with do_anonymous_page(). Let's change page fault handler to use do_anonymous_page() only on anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not shared. For file mappings without vm_ops->fault() or shred VMA without vm_ops, page fault on pte_none() entry would lead to SIGBUS. Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Eric Dumazet authored
commit b98b0bc8 upstream. CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930 ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
-
Guillaume Nault authored
commit 32c23116 upstream. Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind(). Without lock, a concurrent call could modify the socket flags between the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way, a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it would then leave a stale pointer there, generating use-after-free errors when walking through the list or modifying adjacent entries. BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8 Write of size 8 by task syz-executor/10987 CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0 Call Trace: [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 [< inline >] print_address_description mm/kasan/report.c:194 [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283 [< inline >] kasan_report mm/kasan/report.c:303 [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329 [< inline >] __write_once_size ./include/linux/compiler.h:249 [< inline >] __hlist_del ./include/linux/list.h:622 [< inline >] hlist_del_init ./include/linux/list.h:637 [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239 [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff813774f9>] task_work_run+0xf9/0x170 [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448 Allocated: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0 [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20 [ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708 [ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716 [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721 [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326 [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388 [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182 [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153 [ 1116.897025] [< inline >] sock_create net/socket.c:1193 [ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223 [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203 [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6 Freed: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0 [ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352 [ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 1116.897025] [< inline >] slab_free mm/slub.c:2951 [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973 [ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369 [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444 [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452 [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460 [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471 [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589 [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243 [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170 [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Memory state around the buggy address: ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table. Fixes: c51ce497 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case") Reported-by:
Baozeng Ding <sploving1@gmail.com> Reported-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Jan Kara authored
commit 07393101 upstream. When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. References: CVE-2016-7097 Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
Peter Zijlstra authored
commit c3c87e77 upstream. The fix from 9fc81d87 ("perf: Fix events installation during moving group") was incomplete in that it failed to recognise that creating a group with events for different CPUs is semantically broken -- they cannot be co-scheduled. Furthermore, it leads to real breakage where, when we create an event for CPU Y and then migrate it to form a group on CPU X, the code gets confused where the counter is programmed -- triggered in practice as well by me via the perf fuzzer. Fix this by tightening the rules for creating groups. Only allow grouping of counters that can be co-scheduled in the same context. This means for the same task and/or the same cpu. Fixes: 9fc81d87 ("perf: Fix events installation during moving group") Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Seung-Woo Kim authored
commit 60a2362f upstream. After freeing pin from regulator_ena_gpio_free, loop can access the pin. So this patch fixes not to access pin after freeing. Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit 3aa02cb6 upstream. Currently kill_fasync() is called outside the stream lock in snd_pcm_period_elapsed(). This is potentially racy, since the stream may get released even during the irq handler is running. Although snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't guarantee that the irq handler finishes, thus the kill_fasync() call outside the stream spin lock may be invoked after the substream is detached, as recently reported by KASAN. As a quick workaround, move kill_fasync() call inside the stream lock. The fasync is rarely used interface, so this shouldn't have a big impact from the performance POV. Ideally, we should implement some sync mechanism for the proper finish of stream and irq handler. But this oneliner should suffice for most cases, so far. Reported-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sachin Prabhu authored
commit 38bd4906 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 <sprabhu@redhat.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Acked-by:
-
Thomas Gleixner authored
commit 1e38da30 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 <dvyukov@google.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "linux-fsdevel@vger.kernel.org" Cc: syzkaller <syzkaller@googlegroups.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanosSigned-off-by:
-
Arnd Bergmann authored
commit e434e041 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 authored
commit 0335695d upstream. The current_user_ns() macro currently returns &init_user_ns when user namespaces are disabled, and that causes several warnings when building with gcc-6.0 in code that compares the result of the macro to &init_user_ns itself: fs/xfs/xfs_ioctl.c: In function 'xfs_ioctl_setattr_check_projid': fs/xfs/xfs_ioctl.c:1249:22: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (current_user_ns() == &init_user_ns) This is a legitimate warning in principle, but here it isn't really helpful, so I'm reprasing the definition in a way that shuts up the warning. Apparently gcc only warns when comparing identical literals, but it can figure out that the result of an inline function can be identical to a constant expression in order to optimize a condition yet not warn about the fact that the condition is known at compile time. This is exactly what we want here, and it looks reasonable because we generally prefer inline functions over macros anyway. Signed-off-by:
Serge Hallyn <serge.hallyn@canonical.com> Cc: David Howells <dhowells@redhat.com> Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
