Loic Poulain [Tue, 3 Apr 2018 09:19:01 +0000 (11:19 +0200)]
PCI: kirin: Fix reset gpio name
[ Upstream commit
5db8f8d1099bd93a64a80b609dbcce887327ffc8 ]
As documented in the devicetree bindings (pci/kirin-pcie.txt) and the
reset gpio name must be 'reset-gpios'. However, current driver
erroneously looks for a 'reset-gpio' resource which makes the driver
probe fail. Fix it.
Fixes:
fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller driver")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
[lorenzo.pieralisi@arm.com: updated the commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Xiaowei Song <songxiaowei@hisilicon.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Sun, 8 Apr 2018 09:05:15 +0000 (11:05 +0200)]
soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure
[ Upstream commit
144345a4a8c3b497a3f60d3af9d6071a37660186 ]
If CONFIG_RASPBERRYPI_FIRMWARE=n:
drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_polarity’:
drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used uninitialized in this function
drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_direction’:
drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used uninitialized in this function
The dummy firmware interface functions return 0, which means success,
causing subsequent code to make use of the never initialized output
parameter.
Fix this by making the dummy functions return an error code (-ENOSYS)
instead.
Note that this assumes the firmware always fills in the requested data
in the CONFIG_RASPBERRYPI_FIRMWARE=y case.
Fixes:
d45f1a563b92dac7 ("staging: vc04_services: fix up rpi firmware functions")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Sun, 1 Apr 2018 16:42:25 +0000 (09:42 -0700)]
soc: bcm: raspberrypi-power: Fix use of __packed
[ Upstream commit
0a12e80ce4230434c2ed66ad0d65af0b7ccecea8 ]
Commit
a09cd356586d ("ARM: bcm2835: add rpi power domain driver")
attempted to annotate the structure rpi_power_domain_packet with
__packed but introduced a typo and made it named __packet instead. Just
drop the annotation since the structure is naturally aligned already.
Fixes:
a09cd356586d ("ARM: bcm2835: add rpi power domain driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Wed, 28 Mar 2018 23:41:52 +0000 (23:41 +0000)]
eCryptfs: don't pass up plaintext names when using filename encryption
[ Upstream commit
e86281e700cca8a773f9a572fa406adf2784ba5c ]
Both ecryptfs_filldir() and ecryptfs_readlink_lower() use
ecryptfs_decode_and_decrypt_filename() to translate lower filenames to
upper filenames. The function correctly passes up lower filenames,
unchanged, when filename encryption isn't in use. However, it was also
passing up lower filenames when the filename wasn't encrypted or
when decryption failed. Since
88ae4ab9802e, eCryptfs refuses to lookup
lower plaintext names when filename encryption is enabled so this
resulted in a situation where userspace would see lower plaintext
filenames in calls to getdents(2) but then not be able to lookup those
filenames.
An example of this can be seen when enabling filename encryption on an
eCryptfs mount at the root directory of an Ext4 filesystem:
$ ls -1i /lower
12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE--
11 lost+found
$ ls -1i /upper
ls: cannot access '/upper/lost+found': No such file or directory
? lost+found
12 test
With this change, the lower lost+found dentry is ignored:
$ ls -1i /lower
12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE--
11 lost+found
$ ls -1i /upper
12 test
Additionally, some potentially noisy error/info messages in the related
code paths are turned into debug messages so that the logs can't be
easily filled.
Fixes:
88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
oder_chiou@realtek.com [Fri, 30 Mar 2018 07:41:55 +0000 (15:41 +0800)]
ASoC: rt5514: Add the missing register in the readable table
[ Upstream commit
5ef5ac8de125fe6b4b23293bee026ca7ea1529b9 ]
The patch adds the missing register in the readable table.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Brunet [Mon, 9 Apr 2018 13:59:20 +0000 (15:59 +0200)]
clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux
[ Upstream commit
4ad69b80e886a845f56ce0a3d10211208693d92b ]
CLK_MUX_ROUND_CLOSEST is part of the clk_mux documentation but clk_mux
directly calls __clk_mux_determine_rate(), which overrides the flag.
As result, if clk_mux is instantiated with CLK_MUX_ROUND_CLOSEST, the
flag will be ignored and the clock rounded down.
To solve this, this patch expose clk_mux_determine_rate_flags() in the
clk-provider API and uses it in the determine_rate() callback of clk_mux.
Fixes:
15a02c1f6dd7 ("clk: Add __clk_mux_determine_rate_closest")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jacopo Mondi [Mon, 16 Apr 2018 13:56:08 +0000 (15:56 +0200)]
dt-bindings: dmaengine: rcar-dmac: document R8A77965 support
[ Upstream commit
b89bc283286b105e50aab9ab35992c0237ac77d8 ]
Add documentation for r8a77965 compatible string to rcar-dmac device
tree bindings documentation.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jacopo Mondi [Mon, 16 Apr 2018 13:55:28 +0000 (15:55 +0200)]
dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF
[ Upstream commit
7de5b7e5f6a67c285b86d1478e8e150929c93482 ]
Add documentation for r8a77965 compatible string to Renesas sci-serial
device tree bindings documentation.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matheus Castello [Wed, 11 Apr 2018 05:17:03 +0000 (01:17 -0400)]
dt-bindings: pinctrl: sunxi: Fix reference to driver
[ Upstream commit
b614e905a0bc8fc5d4fa72665ac26ae00c874a4e ]
Bindings describe hardware, not drivers.
Use reference to hardware Allwinner A1X Pin Controller instead driver.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukasz Majewski [Wed, 4 Apr 2018 07:52:04 +0000 (09:52 +0200)]
doc: Add vendor prefix for Kieback & Peter GmbH
[ Upstream commit
99bf8f27f3f94d2a37291354b8dc83f13728f75f ]
The 'kiebackpeter' entry has been added to vendor-prefixes.txt to indicate
products from Kieback & Peter GmbH.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Zapolskiy [Fri, 13 Apr 2018 12:44:16 +0000 (15:44 +0300)]
spi: sh-msiof: Fix bit field overflow writes to TSCR/RSCR
[ Upstream commit
10b4640833e95eeacaef8060bc1b35e636df3218 ]
The change fixes a bit field overflow which allows to write to higher
bits while calculating SPI transfer clock and setting BRPS and BRDV
bit fields, the problem is reproduced if 'parent_rate' to 'spi_hz'
ratio is greater than 1024, for instance
p->min_div = 2,
MSO rate =
33333333,
SPI device rate = 10000
results in
k = 5, i.e. BRDV = 0b100 or 1/32 prescaler output,
BRPS = 105,
TSCR value = 0x6804, thus MSSEL and MSIMM bit fields are non-zero.
Fixes:
65d5665bb260 ("spi: sh-msiof: Update calculation of frequency dividing")
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Redfearn [Fri, 13 Apr 2018 08:50:44 +0000 (09:50 +0100)]
MIPS: dts: Boston: Fix PCI bus dtc warnings:
[ Upstream commit
2c2bf522ed8cbfaac666f7dc65cfd38de2b89f0f ]
dtc recently (v1.4.4-8-g756ffc4f52f6) added PCI bus checks. Fix the
warnings now emitted:
arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@
10000000: missing bus-range for PCI bridge
arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@
12000000: missing bus-range for PCI bridge
arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@
14000000: missing bus-range for PCI bridge
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/19070/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chengguang Xu [Sat, 14 Apr 2018 12:16:06 +0000 (20:16 +0800)]
isofs: fix potential memory leak in mount option parsing
[ Upstream commit
4f34a5130a471f32f2fe7750769ab4057dc3eaa0 ]
When specifying string type mount option (e.g., iocharset)
several times in a mount, current option parsing may
cause memory leak. Hence, call kfree for previous one
in this case. Meanwhile, check memory allocation result
for it.
Signed-off-by: Chengguang Xu <cgxu519@gmx.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Tue, 3 Apr 2018 09:08:52 +0000 (11:08 +0200)]
s390/smsgiucv: disable SMSG on module unload
[ Upstream commit
760dd0eeaec1689430243ead14e5a429613d8c52 ]
The module exit function of the smsgiucv module uses the incorrect CP
command to disable SMSG messages. The correct command is "SET SMSG OFF".
Use it.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sinan Kaya [Fri, 13 Apr 2018 02:30:44 +0000 (22:30 -0400)]
MIPS: io: Add barrier after register read in readX()
[ Upstream commit
a1cc7034e33d12dc17d13fbcd7d597d552889097 ]
While a barrier is present in the writeX() functions before the register
write, a similar barrier is missing in the readX() functions after the
register read. This could allow memory accesses following readX() to
observe stale data.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/19069/
[jhogan@kernel.org: Tidy commit message]
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amir Goldstein [Thu, 5 Apr 2018 13:18:03 +0000 (16:18 +0300)]
fsnotify: fix ignore mask logic in send_to_group()
[ Upstream commit
92183a42898dc400b89da35685d1814ac6acd3d8 ]
The ignore mask logic in send_to_group() does not match the logic
in fanotify_should_send_event(). In the latter, a vfsmount mark ignore
mask precedes an inode mark mask and in the former, it does not.
That difference may cause events to be sent to fanotify backend for no
reason. Fix the logic in send_to_group() to match that of
fanotify_should_send_event().
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnaldo Carvalho de Melo [Thu, 12 Apr 2018 17:58:24 +0000 (14:58 -0300)]
perf report: Fix switching to another perf.data file
[ Upstream commit
7b366142a50ad79e48de8e67c5b3e8cfb9fa82dd ]
In the TUI the 's' hotkey can be used to switch to another perf.data
file in the current directory, but that got broken in Fixes:
b01141f4f59c ("perf annotate: Initialize the priv are in symbol__new()"),
that would show this once another file was chosen:
┌─Fatal Error─────────────────────────────────────┐
│Annotation needs to be init before symbol__init()│
│ │
│ │
│Press any key... │
└─────────────────────────────────────────────────┘
Fix it by just silently bailing out if symbol__annotation_init() was already
called, just like is done with symbol__init(), i.e. they are done just once at
session start, not when switching to a new perf.data file.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Martin Liška <mliska@suse.cz>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes:
b01141f4f59c ("perf annotate: Initialize the priv are in symbol__new()")
Link: https://lkml.kernel.org/n/tip-ogppdtpzfax7y1h6gjdv5s6u@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jakub Kicinski [Wed, 11 Apr 2018 23:47:35 +0000 (16:47 -0700)]
nfp: ignore signals when communicating with management FW
[ Upstream commit
5496295aefe86995e41398b0f76de601308fc3f5 ]
We currently allow signals to interrupt the wait for management FW
commands. Exiting the wait should not cause trouble, the FW will
just finish executing the command in the background and new commands
will wait for the old one to finish.
However, this may not be what users expect (Ctrl-C not actually stopping
the command). Moreover some systems routinely request link information
with signals pending (Ubuntu 14.04 runs a landscape-sysinfo python tool
from MOTD) worrying users with errors like these:
nfp 0000:04:00.0: nfp_nsp: Error -512 waiting for code 0x0007 to start
nfp 0000:04:00.0: nfp: reading port table failed -512
Make the wait for management FW responses non-interruptible.
Fixes:
1a64821c6af7 ("nfp: add support for service processor access")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sinan Kaya [Tue, 3 Apr 2018 12:55:03 +0000 (08:55 -0400)]
MIPS: io: Prevent compiler reordering writeX()
[ Upstream commit
f6b7aeee8f167409195fbf1364d02988fecad1d0 ]
writeX() has strong ordering semantics with respect to memory updates.
In the absence of a write barrier or a compiler barrier, the compiler
can reorder register and memory update instructions. This breaks the
writeX() API.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18997/
[jhogan@kernel.org: Tidy commit message]
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krish Sadhukhan [Wed, 11 Apr 2018 05:10:16 +0000 (01:10 -0400)]
x86: Add check for APIC access address for vmentry of L2 guests
[ Upstream commit
f0f4cf5b306620282db0c59ff963012e1973e025 ]
According to the sub-section titled 'VM-Execution Control Fields' in the
section titled 'Basic VM-Entry Checks' in Intel SDM vol. 3C, the following
vmentry check must be enforced:
If the 'virtualize APIC-accesses' VM-execution control is 1, the
APIC-access address must satisfy the following checks:
- Bits 11:0 of the address must be 0.
- The address should not set any bits beyond the processor's
physical-address width.
This patch adds the necessary check to conform to this rule. If the check
fails, we cause the L2 VMENTRY to fail which is what the associated unit
test (following patch) expects.
Reviewed-by: Mihai Carabas <mihai.carabas@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hu huajun [Wed, 11 Apr 2018 07:16:40 +0000 (15:16 +0800)]
KVM: X86: fix incorrect reference of trace_kvm_pi_irte_update
[ Upstream commit
2698d82e519413c6ad287e6f14b29e0373ed37f8 ]
In arch/x86/kvm/trace.h, this function is declared as host_irq the
first input, and vcpu_id the second, instead of otherwise.
Signed-off-by: hu huajun <huhuajun@linux.alibaba.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Fri, 6 Apr 2018 22:36:11 +0000 (15:36 -0700)]
Input: synaptics-rmi4 - fix an unchecked out of memory error path
[ Upstream commit
839c42273617787318da7baf6151d553108f5e17 ]
When extending the rmi_spi buffers, we must check that no out of memory
error occurs, otherwise we may access data above the currently allocated
memory.
Propagate the error code returned by 'rmi_spi_manage_pools()' instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anson Huang [Wed, 28 Mar 2018 03:22:37 +0000 (11:22 +0800)]
clocksource/drivers/imx-tpm: Correct some registers operation flow
[ Upstream commit
506a7be93ff773d5d4cf75a59f342865605b4910 ]
According to i.MX7ULP reference manual, TPM_SC_CPWMS can ONLY be written when
counter is disabled, TPM_SC_TOF is write-1-clear, TPM_C0SC_CHF is also
write-1-clear, correct these registers initialization flow;
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 16 Jun 2018 07:45:18 +0000 (09:45 +0200)]
Linux 4.14.50
Bin Liu [Tue, 17 Apr 2018 19:53:13 +0000 (14:53 -0500)]
crypto: omap-sham - fix memleak
commit
9dbc8a0328efa485a6f5b68b867f9f523a3fbeff upstream.
Fixes:
8043bb1ae03cb ("crypto: omap-sham - convert driver logic to use sgs for data xmit")
The memory pages freed in omap_sham_finish_req() were less than those
allocated in omap_sham_copy_sgs().
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu <b-liu@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Thu, 3 May 2018 12:29:30 +0000 (22:29 +1000)]
crypto: vmx - Remove overly verbose printk from AES XTS init
commit
730f23b66095a700e2f0786abda6bca011b31558 upstream.
In p8_aes_xts_init() we do a printk(KERN_INFO ...) to report the
fallback implementation we're using. However with a slow console this
can significantly affect the speed of crypto operations. So remove it.
Fixes:
c07f5d3da643 ("crypto: vmx - Adding support for XTS")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Thu, 3 May 2018 12:29:29 +0000 (22:29 +1000)]
crypto: vmx - Remove overly verbose printk from AES init routines
commit
1411b5218adbcf1d45ddb260db5553c52e8d917c upstream.
In the vmx AES init routines we do a printk(KERN_INFO ...) to report
the fallback implementation we're using.
However with a slow console this can significantly affect the speed of
crypto operations. Using 'cryptsetup benchmark' the removal of the
printk() leads to a ~5x speedup for aes-cbc decryption.
So remove them.
Fixes:
8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
Fixes:
8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
Fixes:
4f7f60d312b3 ("crypto: vmx - Adding CTR routines for VMX module")
Fixes:
cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Glauber [Mon, 9 Apr 2018 15:45:51 +0000 (17:45 +0200)]
crypto: cavium - Limit result reading attempts
commit
c782a8c43e94ba6c09e9de2d69b5e3a5840ce61c upstream.
After issuing a request an endless loop was used to read the
completion state from memory which is asynchronously updated
by the ZIP coprocessor.
Add an upper bound to the retry attempts to prevent a CPU getting stuck
forever in case of an error. Additionally, add a read memory barrier
and a small delay between the reading attempts.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Reviewed-by: Robert Richter <rrichter@cavium.com>
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Glauber [Mon, 9 Apr 2018 15:45:50 +0000 (17:45 +0200)]
crypto: cavium - Fix fallout from CONFIG_VMAP_STACK
commit
37ff02acaa3d7be87ecb89f198a549ffd3ae2403 upstream.
Enabling virtual mapped kernel stacks breaks the thunderx_zip
driver. On compression or decompression the executing CPU hangs
in an endless loop. The reason for this is the usage of __pa
by the driver which does no longer work for an address that is
not part of the 1:1 mapping.
The zip driver allocates a result struct on the stack and needs
to tell the hardware the physical address within this struct
that is used to signal the completion of the request.
As the hardware gets the wrong address after the broken __pa
conversion it writes to an arbitrary address. The zip driver then
waits forever for the completion byte to contain a non-zero value.
Allocating the result struct from 1:1 mapped memory resolves this
bug.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Reviewed-by: Robert Richter <rrichter@cavium.com>
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Fri, 27 Apr 2018 08:40:11 +0000 (11:40 +0300)]
crypto: caam - fix size of RSA prime factor q
commit
4bffaab373d9afaf862f3924442c33340bd26736 upstream.
Fix a typo where size of RSA prime factor q is using the size of
prime factor p.
Cc: <stable@vger.kernel.org> # 4.13+
Fixes:
52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
Fixes:
4a651b122adb ("crypto: caam - add support for RSA key form 3")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Wed, 28 Mar 2018 12:39:19 +0000 (15:39 +0300)]
crypto: caam/qi - fix IV DMA mapping and updating
commit
3a488aaec6f343b5dc6d94529847a840bbeaf009 upstream.
There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated IV (req->info) will contain the last block of plaintext
(instead of the last block of ciphertext)
While these two issues could be fixed separately, it's straightforward
to fix both in the same time - by using the {ablkcipher,aead}_edesc
extended descriptor to store the IV that will be fed to the crypto engine;
this allows for fixing (2) by saving req->src[last_block] in req->info
directly, i.e. without allocating yet another temporary buffer.
A side effect of the fix is that it's no longer possible to have the IV
contiguous with req->src or req->dst.
Code checking for this case is removed.
Cc: <stable@vger.kernel.org> # 4.14+
Fixes:
a68a19380522 ("crypto: caam/qi - properly set IV after {en,de}crypt")
Link: http://lkml.kernel.org/r/20170113084620.GF22022@gondor.apana.org.au
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Wed, 28 Mar 2018 12:39:18 +0000 (15:39 +0300)]
crypto: caam - fix IV DMA mapping and updating
commit
115957bb3e59fcb226ce76b97af14533f239e0ac upstream.
There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated req->info will contain the last block of plaintext
(instead of the last block of ciphertext)
While these two issues could be fixed separately, it's straightforward
to fix both in the same time - by allocating extra space in the
ablkcipher_edesc for the IV that will be fed to the crypto engine;
this allows for fixing (2) by saving req->src[last_block] in req->info
directly, i.e. without allocating another temporary buffer.
A side effect of the fix is that it's no longer possible to have the IV
and req->src contiguous. Code checking for this case is removed.
Cc: <stable@vger.kernel.org> # 4.13+
Fixes:
854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt")
Link: http://lkml.kernel.org/r/20170113084620.GF22022@gondor.apana.org.au
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Wed, 28 Mar 2018 12:39:17 +0000 (15:39 +0300)]
crypto: caam - fix DMA mapping dir for generated IV
commit
a38acd236cac914aafffd80af79b9556fc2c3934 upstream.
In case of GIVCIPHER, IV is generated by the device.
Fix the DMA mapping direction.
Cc: <stable@vger.kernel.org> # 3.19+
Fixes:
7222d1a34103 ("crypto: caam - add support for givencrypt cbc(aes) and rfc3686(ctr(aes))")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Mon, 16 Apr 2018 13:07:05 +0000 (08:07 -0500)]
crypto: caam - strip input zeros from RSA input buffer
commit
8a2a0dd35f2e54c023d9041a5428b6c5639af86c upstream.
Sometimes the provided RSA input buffer provided is not stripped
of leading zeros. This could cause its size to be bigger than that
of the modulus, making the HW complain:
caam_jr 2142000.jr1:
40000789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb size N < (F + 11) when formatting is used.
Fix the problem by stripping off the leading zero from input data
before feeding it to the CAAM accelerator.
Fixes:
8c419778ab57e ("crypto: caam - add support for RSA algorithm")
Cc: <stable@vger.kernel.org> # 4.8+
Reported-by: Martin Townsend <mtownsend1973@gmail.com>
Link: https://lkml.kernel.org/r/CABatt_ytYORYKtApcB4izhNanEKkGFi9XAQMjHi_n-8YWoCRiw@mail.gmail.com
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Wienke [Mon, 4 Jun 2018 20:37:26 +0000 (13:37 -0700)]
Input: elan_i2c - add ELAN0612 (Lenovo v330 14IKB) ACPI ID
commit
e6e7e9cd8eed0e18217c899843bffbe8c7dae564 upstream.
Add ELAN0612 to the list of supported touchpads; this ID is used in Lenovo
v330 14IKB devices.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199253
Signed-off-by: Johannes Wienke <languitar@semipol.de>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ethan Lee [Thu, 31 May 2018 23:13:17 +0000 (16:13 -0700)]
Input: goodix - add new ACPI id for GPD Win 2 touch screen
commit
5ca4d1ae9bad0f59bd6f851c39b19f5366953666 upstream.
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Wed, 6 Jun 2018 15:38:09 +0000 (17:38 +0200)]
kvm: x86: use correct privilege level for sgdt/sidt/fxsave/fxrstor access
commit
3c9fa24ca7c9c47605672916491f79e8ccacb9e6 upstream.
The functions that were used in the emulation of fxrstor, fxsave, sgdt and
sidt were originally meant for task switching, and as such they did not
check privilege levels. This is very bad when the same functions are used
in the emulation of unprivileged instructions. This is CVE-2018-10853.
The obvious fix is to add a new argument to ops->read_std and ops->write_std,
which decides whether the access is a "system" access or should use the
processor's CPL.
Fixes:
129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Martin [Thu, 10 May 2018 17:08:23 +0000 (18:08 +0100)]
tty: pl011: Avoid spuriously stuck-off interrupts
commit
4a7e625ce50412a7711efa0f2ef0b96ce3826759 upstream.
Commit
9b96fbacda34 ("serial: PL011: clear pending interrupts")
clears the RX and receive timeout interrupts on pl011 startup, to
avoid a screaming-interrupt scenario that can occur when the
firmware or bootloader leaves these interrupts asserted.
This has been noted as an issue when running Linux on qemu [1].
Unfortunately, the above fix seems to lead to potential
misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously
on driver startup, if the RX FIFO is also already full to the
trigger level.
Clearing the RX FIFO interrupt does not change the FIFO fill level.
In this scenario, because the interrupt is now clear and because
the FIFO is already full to the trigger level, no new assertion of
the RX FIFO interrupt can occur unless the FIFO is drained back
below the trigger level. This never occurs because the pl011
driver is waiting for an RX FIFO interrupt to tell it that there is
something to read, and does not read the FIFO at all until that
interrupt occurs.
Thus, simply clearing "spurious" interrupts on startup may be
misguided, since there is no way to be sure that the interrupts are
truly spurious, and things can go wrong if they are not.
This patch instead clears the interrupt condition by draining the
RX FIFO during UART startup, after clearing any potentially
spurious interrupt. This should ensure that an interrupt will
definitely be asserted if the RX FIFO subsequently becomes
sufficiently full.
The drain is done at the point of enabling interrupts only. This
means that it will occur any time the UART is newly opened through
the tty layer. It will not apply to polled-mode use of the UART by
kgdboc: since that scenario cannot use interrupts by design, this
should not matter. kgdboc will interact badly with "normal" use of
the UART in any case: this patch makes no attempt to paper over
such issues.
This patch does not attempt to address the case where the RX FIFO
fills faster than it can be drained: that is a pathological
hardware design problem that is beyond the scope of the driver to
work around. As a failsafe, the number of poll iterations for
draining the FIFO is limited to twice the FIFO size. This will
ensure that the kernel at least boots even if it is impossible to
drain the FIFO for some reason.
[1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo
before enabled the interruption
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html
Reported-by: Wei Xu <xuwei5@hisilicon.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
Fixes:
9b96fbacda34 ("serial: PL011: clear pending interrupts")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gil Kupfer [Fri, 1 Jun 2018 07:47:47 +0000 (00:47 -0700)]
vmw_balloon: fixing double free when batching mode is off
commit
b23220fe054e92f616b82450fae8cd3ab176cc60 upstream.
The balloon.page field is used for two different purposes if batching is
on or off. If batching is on, the field point to the page which is used
to communicate with with the hypervisor. If it is off, balloon.page
points to the page that is about to be (un)locked.
Unfortunately, this dual-purpose of the field introduced a bug: when the
balloon is popped (e.g., when the machine is reset or the balloon driver
is explicitly removed), the balloon driver frees, unconditionally, the
page that is held in balloon.page. As a result, if batching is
disabled, this leads to double freeing the last page that is sent to the
hypervisor.
The following error occurs during rmmod when kernel checkers are on, and
the balloon is not empty:
[ 42.307653] ------------[ cut here ]------------
[ 42.307657] Kernel BUG at
ffffffffba1e4b28 [verbose debug info unavailable]
[ 42.307720] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 42.312512] Modules linked in: vmw_vsock_vmci_transport vsock ppdev joydev vmw_balloon(-) input_leds serio_raw vmw_vmci parport_pc shpchp parport i2c_piix4 nfit mac_hid autofs4 vmwgfx drm_kms_helper hid_generic syscopyarea sysfillrect usbhid sysimgblt fb_sys_fops hid ttm mptspi scsi_transport_spi ahci mptscsih drm psmouse vmxnet3 libahci mptbase pata_acpi
[ 42.312766] CPU: 10 PID: 1527 Comm: rmmod Not tainted 4.12.0+ #5
[ 42.312803] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2016
[ 42.313042] task:
ffff9bf9680f8000 task.stack:
ffffbfefc1638000
[ 42.313290] RIP: 0010:__free_pages+0x38/0x40
[ 42.313510] RSP: 0018:
ffffbfefc163be98 EFLAGS:
00010246
[ 42.313731] RAX:
000000000000003e RBX:
ffffffffc02b9720 RCX:
0000000000000006
[ 42.313972] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff9bf97e08e0a0
[ 42.314201] RBP:
ffffbfefc163be98 R08:
0000000000000000 R09:
0000000000000000
[ 42.314435] R10:
0000000000000000 R11:
0000000000000000 R12:
ffffffffc02b97e4
[ 42.314505] R13:
ffffffffc02b9748 R14:
ffffffffc02b9728 R15:
0000000000000200
[ 42.314550] FS:
00007f3af5fec700(0000) GS:
ffff9bf97e080000(0000) knlGS:
0000000000000000
[ 42.314599] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 42.314635] CR2:
00007f44f6f4ab24 CR3:
00000003a7d12000 CR4:
00000000000006e0
[ 42.314864] Call Trace:
[ 42.315774] vmballoon_pop+0x102/0x130 [vmw_balloon]
[ 42.315816] vmballoon_exit+0x42/0xd64 [vmw_balloon]
[ 42.315853] SyS_delete_module+0x1e2/0x250
[ 42.315891] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 42.315924] RIP: 0033:0x7f3af5b0e8e7
[ 42.315949] RSP: 002b:
00007fffe6ce0148 EFLAGS:
00000206 ORIG_RAX:
00000000000000b0
[ 42.315996] RAX:
ffffffffffffffda RBX:
000055be676401e0 RCX:
00007f3af5b0e8e7
[ 42.316951] RDX:
000000000000000a RSI:
0000000000000800 RDI:
000055be67640248
[ 42.317887] RBP:
0000000000000003 R08:
0000000000000000 R09:
1999999999999999
[ 42.318845] R10:
0000000000000883 R11:
0000000000000206 R12:
00007fffe6cdf130
[ 42.319755] R13:
0000000000000000 R14:
0000000000000000 R15:
000055be676401e0
[ 42.320606] Code: c0 74 1c f0 ff 4f 1c 74 02 5d c3 85 f6 74 07 e8 0f d8 ff ff 5d c3 31 f6 e8 c6 fb ff ff 5d c3 48 c7 c6 c8 0f c5 ba e8 58 be 02 00 <0f> 0b 66 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 75 01 c3 55 48
[ 42.323462] RIP: __free_pages+0x38/0x40 RSP:
ffffbfefc163be98
[ 42.325735] ---[ end trace
872e008e33f81508 ]---
To solve the bug, we eliminate the dual purpose of balloon.page.
Fixes:
f220a80f0c2e ("VMware balloon: add batching to the vmw_balloon.")
Cc: stable@vger.kernel.org
Reported-by: Oleksandr Natalenko <onatalen@redhat.com>
Signed-off-by: Gil Kupfer <gilkup@gmail.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
Tested-by: Oleksandr Natalenko <oleksandr@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Lindgren [Fri, 4 May 2018 17:44:09 +0000 (10:44 -0700)]
serial: 8250: omap: Fix idling of clocks for unused uarts
commit
13dc04d0e5fdc25c8f713ad23fdce51cf2bf96ba upstream.
I noticed that unused UARTs won't necessarily idle properly always
unless at least one byte tx transfer is done first.
After some debugging I narrowed down the problem to the scr register
dma configuration bits that need to be set before softreset for the
clocks to idle. Unless we do this, the module clkctrl idlest bits
may be set to 1 instead of 3 meaning the clock will never idle and
is blocking deeper idle states for the whole domain.
This might be related to the configuration done by the bootloader
or kexec booting where certain configurations cause the 8250 or
the clkctrl clock to jam in a way where setting of the scr bits
and reset is needed to clear it. I've tried diffing the 8250
registers for the various modes, but did not see anything specific.
So far I've only seen this on omap4 but I'm suspecting this might
also happen on the other clkctrl using SoCs considering they
already have a quirk enabled for UART_ERRATA_CLOCK_DISABLE.
Let's fix the issue by configuring scr before reset for basic dma
even if we don't use it. The scr register will be reset when we do
softreset few lines after, and we restore scr on resume. We should
do this for all the SoCs with UART_ERRATA_CLOCK_DISABLE quirk flag
set since the ones with UART_ERRATA_CLOCK_DISABLE are all based
using clkctrl similar to omap4.
Looks like both OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL
bits are needed for the clkctrl to idle after a softreset.
And we need to add omap4 to also use the UART_ERRATA_CLOCK_DISABLE
for the related workaround to be enabled. This same compatible
value will also be used for omap5.
Fixes:
cdb929e4452a ("serial: 8250_omap: workaround errata around idling UART after using DMA")
Cc: Keerthy <j-keerthy@ti.com>
Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Szyprowski [Thu, 10 May 2018 06:41:13 +0000 (08:41 +0200)]
serial: samsung: fix maxburst parameter for DMA transactions
commit
aa2f80e752c75e593b3820f42c416ed9458fa73e upstream.
The best granularity of residue that DMA engine can report is in the BURST
units, so the serial driver must use MAXBURST = 1 and DMA_SLAVE_BUSWIDTH_1_BYTE
if it relies on exact number of bytes transferred by DMA engine.
Fixes:
62c37eedb74c ("serial: samsung: add dma reqest/release functions")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Mon, 7 May 2018 17:11:30 +0000 (19:11 +0200)]
tty/serial: atmel: use port->name as name in request_irq()
commit
9594b5be7ec110ed11acec58fa94f3f293668c85 upstream.
I was puzzled while looking at /proc/interrupts and random things showed
up between reboots. This occurred more often but I realised it later. The
"correct" output should be:
|38: 11861 atmel-aic5 2 Level ttyS0
but I saw sometimes
|38: 6426 atmel-aic5 2 Level tty1
and accounted it wrongly as correct. This is use after free and the
former example randomly got the "old" pointer which pointed to the same
content. With SLAB_FREELIST_RANDOM and HARDENED I even got
|38: 7067 atmel-aic5 2 Level E=Started User Manager for UID 0
or other nonsense.
As it turns out the tty, pointer that is accessed in atmel_startup(), is
freed() before atmel_shutdown(). It seems to happen quite often that the
tty for ttyS0 is allocated and freed while ->shutdown is not invoked. I
don't do anything special - just a systemd boot :)
Use dev_name(&pdev->dev) as the IRQ name for request_irq(). This exists
as long as the driver is loaded so no use-after-free here.
Cc: stable@vger.kernel.org
Fixes:
761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 1 Jun 2018 09:28:21 +0000 (11:28 +0200)]
serial: sh-sci: Stop using printk format %pCr
commit
d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Tue, 10 Apr 2018 05:38:54 +0000 (14:38 +0900)]
usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting
commit
bd6bce004d78b867ba0c6d3712f1c5b50398af9a upstream.
This patch fixes an issue that reconnection is possible to fail
because unexpected state handling happens by the irqs. To fix the issue,
the driver disables the controller's irqs when disconnected.
Fixes:
746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Mon, 21 May 2018 11:18:07 +0000 (20:18 +0900)]
usb: gadget: function: printer: avoid wrong list handling in printer_write()
commit
4a014a7339f441b0851ce012f469c0fadac61c81 upstream.
When printer_write() calls usb_ep_queue(), a udc driver (e.g.
renesas_usbhs driver) may call usb_gadget_giveback_request() in
the udc .queue ops immediately. Then, printer_write() calls
list_add(&req->list, &dev->tx_reqs_active) wrongly. After that,
if we do unbind the printer driver, WARN_ON() happens in
printer_func_unbind() because the list entry is not removed.
So, this patch moves list_add(&req->list, &dev->tx_reqs_active)
calling before usb_ep_queue().
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manu Gautam [Wed, 2 May 2018 21:06:10 +0000 (02:36 +0530)]
phy: qcom-qusb2: Fix crash if nvmem cell not specified
commit
0b4555e776ba0712c6fafb98b226b21fd05d2427 upstream.
Driver currently crashes due to NULL pointer deference
while updating PHY tune register if nvmem cell is NULL.
Since, fused value for Tune1/2 register is optional,
we'd rather bail out.
Fixes:
ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ethan Lee [Fri, 1 Jun 2018 18:46:08 +0000 (11:46 -0700)]
Input: xpad - add GPD Win 2 Controller USB IDs
commit
c1ba08390a8bb13c927e699330896adc15b78205 upstream.
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Kappner [Sat, 19 May 2018 04:50:16 +0000 (21:50 -0700)]
usb-storage: Add compatibility quirk flags for G-Technologies G-Drive
commit
ca7d9515d0e6825351ce106066cea1f60e40b1c8 upstream.
The "G-Drive" (sold by G-Technology) external USB 3.0 drive
hangs on write access under UAS and usb-storage:
[ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[ 136.079152] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[ 136.079176] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[ 136.079180] print_req_error: critical target error, dev sdi, sector 0
[ 136.079183] Buffer I/O error on dev sdi, logical block 0, lost sync page write
[ 136.173148] EXT4-fs (sdi): mounted filesystem with ordered data mode. Opts: (null)
[ 140.583998] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 140.584010] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[ 140.584016] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[ 140.584022] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 18 00 00 00 08 00 00
[ 140.584025] print_req_error: critical target error, dev sdi, sector
3905159192
[ 140.584044] print_req_error: critical target error, dev sdi, sector
3905159192
[ 140.584052] Aborting journal on device sdi-8.
The proposed patch adds compatibility quirks. Because the drive requires two
quirks (one to work with UAS, and another to work with usb-storage), adding this
under unusual_devs.h and not just unusual_uas.h so kernels compiled without UAS
receive the quirk. With the patch, the drive works reliably on UAS and usb-
storage.
(tested on NEC Corporation uPD720200 USB 3.0 host controller).
Signed-off-by: Alexander Kappner <agk@godking.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Kappner [Sat, 19 May 2018 04:50:15 +0000 (21:50 -0700)]
usb-storage: Add support for FL_ALWAYS_SYNC flag in the UAS driver
commit
8c4e97ddfe73a0958bb0abf7e6a3bc4cc3e04936 upstream.
The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS
and is required to work around devices that become unstable upon being
queried for cache. This code is taken straight from:
drivers/usb/storage/scsiglue.c:284
Signed-off-by: Alexander Kappner <agk@godking.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Sat, 19 May 2018 01:13:42 +0000 (20:13 -0500)]
usbip: vhci_sysfs: fix potential Spectre v1
commit
a0d6ec88090d7b1b008429c44532a388e29bb1bd upstream.
pdev_nr and rhport can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev'
drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev'
Fix this by sanitizing pdev_nr and rhport before using them to index
vhcis and vhci->vhci_hcd_ss->vdev respectively.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=
152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 20 May 2018 13:19:46 +0000 (15:19 +0200)]
NFC: pn533: don't send USB data off of the stack
commit
dbafc28955fa6779dc23d1607a0fee5e509a278b upstream.
It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all. Fix this up by properly allocating the data for the small
"commands" that get sent to the device off of the stack.
We do this for one command by having a whole urb just for ack messages,
as they can be submitted in interrupt context, so we can not use
usb_bulk_msg(). But the poweron command can sleep (and does), so use
usb_bulk_msg() for that transfer.
Reported-by: Carlos Manuel Santos <cmmpsantos@gmail.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laura Abbott [Mon, 14 May 2018 21:35:09 +0000 (14:35 -0700)]
staging: android: ion: Switch to pr_warn_once in ion_buffer_destroy
commit
45ad559a29629cb1c64ee636563c69b71524f077 upstream.
Syzbot reported yet another warning with Ion:
WARNING: CPU: 0 PID: 1467 at drivers/staging/android/ion/ion.c:122
ion_buffer_destroy+0xd4/0x190 drivers/staging/android/ion/ion.c:122
Kernel panic - not syncing: panic_on_warn set ...
This is catching that a buffer was freed with an existing kernel mapping
still present. This can be easily be triggered from userspace by calling
DMA_BUF_SYNC_START without calling DMA_BUF_SYNC_END. Switch to a single
pr_warn_once to indicate the error without being disruptive.
Reported-by: syzbot+cd8bcd40cb049efa2770@syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Wed, 6 Jun 2018 15:37:49 +0000 (17:37 +0200)]
KVM: x86: pass kvm_vcpu to kvm_read_guest_virt and kvm_write_guest_virt_system
commit
ce14e868a54edeb2e30cb7a7b104a2fc4b9d76ca upstream.
Int the next patch the emulator's .read_std and .write_std callbacks will
grow another argument, which is not needed in kvm_read_guest_virt and
kvm_write_guest_virt_system's callers. Since we have to make separate
functions, let's give the currently existing names a nicer interface, too.
Fixes:
129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Wilhelm [Mon, 11 Jun 2018 07:43:44 +0000 (09:43 +0200)]
kvm: nVMX: Enforce cpl=0 for VMX instructions
commit
727ba748e110b4de50d142edca9d6a9b7e6111d8 upstream.
VMX instructions executed inside a L1 VM will always trigger a VM exit
even when executed with cpl 3. This means we must perform the
privilege check in software.
Fixes:
70f3aac964ae("kvm: nVMX: Remove superfluous VMX instruction fault checks")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Wilhelm <fwilhelm@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Wed, 6 Jun 2018 14:43:02 +0000 (16:43 +0200)]
KVM: x86: introduce linear_{read,write}_system
commit
79367a65743975e5cac8d24d08eccc7fdae832b0 upstream.
Wrap the common invocation of ctxt->ops->read_std and ctxt->ops->write_std, so
as to have a smaller patch when the functions grow another argument.
Fixes:
129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wanpeng Li [Sun, 13 May 2018 09:24:47 +0000 (02:24 -0700)]
KVM: X86: Fix reserved bits check for MOV to CR3
commit
a780a3ea628268b2ad0ed43d7f28d90db0ff18be upstream.
MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4.
It should be checked when PCIDE bit is not set, however commit
'
d1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on
its physical address width")' removes the bit 63 checking
unconditionally. This patch fixes it by checking bit 63 of CR3
when PCIDE bit is not set in CR4.
Fixes:
d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its physical address width)
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: stable@vger.kernel.org
Reviewed-by: Junaid Shahid <junaids@google.com>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Tue, 16 Jan 2018 07:29:50 +0000 (08:29 +0100)]
gpio: No NULL owner
commit
7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 upstream.
Sometimes a GPIO is fetched with NULL as parent device, and
that is just fine. So under these circumstances, avoid using
dev_name() to provide a name for the GPIO line.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Easton [Sat, 7 Apr 2018 15:40:33 +0000 (11:40 -0400)]
af_key: Always verify length of provided sadb_key
commit
4b66af2d6356a00e94bcdea3e7fea324e8b5c6f4 upstream.
Key extensions (struct sadb_key) include a user-specified number of key
bits. The kernel uses that number to determine how much key data to copy
out of the message in pfkey_msg2xfrm_state().
The length of the sadb_key message must be verified to be long enough,
even in the case of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value
must be long enough to include both the key data and the struct sadb_key
itself.
Introduce a helper function verify_key_len(), and call it from
parse_exthdrs() where other exthdr types are similarly checked for
correctness.
Signed-off-by: Kevin Easton <kevin@guarana.org>
Reported-by: syzbot+5022a34ca5a3d49b84223653fab632dfb7b4cf37@syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Zubin Mithra <zsm@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Tue, 22 May 2018 15:27:22 +0000 (08:27 -0700)]
blkdev_report_zones_ioctl(): Use vmalloc() to allocate large buffers
commit
327ea4adcfa37194739f1ec7c70568944d292281 upstream.
Avoid that complaints similar to the following appear in the kernel log
if the number of zones is sufficiently large:
fio: page allocation failure: order:9, mode:0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
Call Trace:
dump_stack+0x63/0x88
warn_alloc+0xf5/0x190
__alloc_pages_slowpath+0x8f0/0xb0d
__alloc_pages_nodemask+0x242/0x260
alloc_pages_current+0x6a/0xb0
kmalloc_order+0x18/0x50
kmalloc_order_trace+0x26/0xb0
__kmalloc+0x20e/0x220
blkdev_report_zones_ioctl+0xa5/0x1a0
blkdev_ioctl+0x1ba/0x930
block_ioctl+0x41/0x50
do_vfs_ioctl+0xaa/0x610
SyS_ioctl+0x79/0x90
do_syscall_64+0x79/0x1b0
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes:
3ed05a987e0f ("blk-zoned: implement ioctls")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Shaun Tancheff <shaun.tancheff@seagate.com>
Cc: Damien Le Moal <damien.lemoal@hgst.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Taehee Yoo [Wed, 16 May 2018 13:10:37 +0000 (22:10 +0900)]
netfilter: nf_tables: fix NULL pointer dereference on nft_ct_helper_obj_dump()
commit
b71534583f22d08c3e3563bf5100aeb5f5c9fbe5 upstream.
In the nft_ct_helper_obj_dump(), always priv->helper4 is dereferenced.
But if family is ipv6, priv->helper6 should be dereferenced.
Steps to reproduces:
#test.nft
table ip6 filter {
ct helper ftp {
type "ftp" protocol tcp
}
chain input {
type filter hook input priority 4;
ct helper set "ftp"
}
}
%nft -f test.nft
%nft list ruleset
we can see the below messages:
[ 916.286233] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 916.294777] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 916.302613] Modules linked in: nft_objref nf_conntrack_sip nf_conntrack_snmp nf_conntrack_broadcast nf_conntrack_ftp nft_ct nf_conntrack nf_tables nfnetlink [last unloaded: nfnetlink]
[ 916.318758] CPU: 1 PID: 2093 Comm: nft Not tainted 4.17.0-rc4+ #181
[ 916.326772] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[ 916.338773] RIP: 0010:strlen+0x1a/0x90
[ 916.342781] RSP: 0018:
ffff88010ff0f2f8 EFLAGS:
00010292
[ 916.346773] RAX:
dffffc0000000000 RBX:
ffff880119b26ee8 RCX:
ffff88010c150038
[ 916.354777] RDX:
0000000000000002 RSI:
ffff880119b26ee8 RDI:
0000000000000010
[ 916.362773] RBP:
0000000000000010 R08:
0000000000007e88 R09:
ffff88010c15003c
[ 916.370773] R10:
ffff88010c150037 R11:
ffffed002182a007 R12:
ffff88010ff04040
[ 916.378779] R13:
0000000000000010 R14:
ffff880119b26f30 R15:
ffff88010ff04110
[ 916.387265] FS:
00007f57a1997700(0000) GS:
ffff88011b800000(0000) knlGS:
0000000000000000
[ 916.394785] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 916.402778] CR2:
00007f57a0ac80f0 CR3:
000000010ff02000 CR4:
00000000001006e0
[ 916.410772] Call Trace:
[ 916.414787] nft_ct_helper_obj_dump+0x94/0x200 [nft_ct]
[ 916.418779] ? nft_ct_set_eval+0x560/0x560 [nft_ct]
[ 916.426771] ? memset+0x1f/0x40
[ 916.426771] ? __nla_reserve+0x92/0xb0
[ 916.434774] ? memcpy+0x34/0x50
[ 916.434774] nf_tables_fill_obj_info+0x484/0x860 [nf_tables]
[ 916.442773] ? __nft_release_basechain+0x600/0x600 [nf_tables]
[ 916.450779] ? lock_acquire+0x193/0x380
[ 916.454771] ? lock_acquire+0x193/0x380
[ 916.458789] ? nf_tables_dump_obj+0x148/0xcb0 [nf_tables]
[ 916.462777] nf_tables_dump_obj+0x5f0/0xcb0 [nf_tables]
[ 916.470769] ? __alloc_skb+0x30b/0x500
[ 916.474779] netlink_dump+0x752/0xb50
[ 916.478775] __netlink_dump_start+0x4d3/0x750
[ 916.482784] nf_tables_getobj+0x27a/0x930 [nf_tables]
[ 916.490774] ? nft_obj_notify+0x100/0x100 [nf_tables]
[ 916.494772] ? nf_tables_getobj+0x930/0x930 [nf_tables]
[ 916.502579] ? nf_tables_dump_flowtable_done+0x70/0x70 [nf_tables]
[ 916.506774] ? nft_obj_notify+0x100/0x100 [nf_tables]
[ 916.514808] nfnetlink_rcv_msg+0x8ab/0xa86 [nfnetlink]
[ 916.518771] ? nfnetlink_rcv_msg+0x550/0xa86 [nfnetlink]
[ 916.526782] netlink_rcv_skb+0x23e/0x360
[ 916.530773] ? nfnetlink_bind+0x200/0x200 [nfnetlink]
[ 916.534778] ? debug_check_no_locks_freed+0x280/0x280
[ 916.542770] ? netlink_ack+0x870/0x870
[ 916.546786] ? ns_capable_common+0xf4/0x130
[ 916.550765] nfnetlink_rcv+0x172/0x16c0 [nfnetlink]
[ 916.554771] ? sched_clock_local+0xe2/0x150
[ 916.558774] ? sched_clock_cpu+0x144/0x180
[ 916.566575] ? lock_acquire+0x380/0x380
[ 916.570775] ? sched_clock_local+0xe2/0x150
[ 916.574765] ? nfnetlink_net_init+0x130/0x130 [nfnetlink]
[ 916.578763] ? sched_clock_cpu+0x144/0x180
[ 916.582770] ? lock_acquire+0x193/0x380
[ 916.590771] ? lock_acquire+0x193/0x380
[ 916.594766] ? lock_acquire+0x380/0x380
[ 916.598760] ? netlink_deliver_tap+0x262/0xa60
[ 916.602766] ? lock_acquire+0x193/0x380
[ 916.606766] netlink_unicast+0x3ef/0x5a0
[ 916.610771] ? netlink_attachskb+0x630/0x630
[ 916.614763] netlink_sendmsg+0x72a/0xb00
[ 916.618769] ? netlink_unicast+0x5a0/0x5a0
[ 916.626766] ? _copy_from_user+0x92/0xc0
[ 916.630773] __sys_sendto+0x202/0x300
[ 916.634772] ? __ia32_sys_getpeername+0xb0/0xb0
[ 916.638759] ? lock_acquire+0x380/0x380
[ 916.642769] ? lock_acquire+0x193/0x380
[ 916.646761] ? finish_task_switch+0xf4/0x560
[ 916.650763] ? __schedule+0x582/0x19a0
[ 916.655301] ? __sched_text_start+0x8/0x8
[ 916.655301] ? up_read+0x1c/0x110
[ 916.655301] ? __do_page_fault+0x48b/0xaa0
[ 916.655301] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 916.655301] __x64_sys_sendto+0xdd/0x1b0
[ 916.655301] do_syscall_64+0x96/0x3d0
[ 916.655301] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 916.655301] RIP: 0033:0x7f57a0ff5e03
[ 916.655301] RSP: 002b:
00007fff6367e0a8 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
[ 916.655301] RAX:
ffffffffffffffda RBX:
00007fff6367f1e0 RCX:
00007f57a0ff5e03
[ 916.655301] RDX:
0000000000000020 RSI:
00007fff6367e110 RDI:
0000000000000003
[ 916.655301] RBP:
00007fff6367e100 R08:
00007f57a0ce9160 R09:
000000000000000c
[ 916.655301] R10:
0000000000000000 R11:
0000000000000246 R12:
00007fff6367e110
[ 916.655301] R13:
0000000000000020 R14:
00007f57a153c610 R15:
0000562417258de0
[ 916.655301] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fa 53 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df 48 89 fd 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f
[ 916.655301] RIP: strlen+0x1a/0x90 RSP:
ffff88010ff0f2f8
[ 916.771929] ---[ end trace
1065e048e72479fe ]---
[ 916.777204] Kernel panic - not syncing: Fatal exception
[ 916.778158] Kernel Offset: 0x14000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 11 Jun 2018 20:49:22 +0000 (22:49 +0200)]
Linux 4.14.49
Dave Airlie [Tue, 15 May 2018 03:38:15 +0000 (13:38 +1000)]
drm: set FMODE_UNSIGNED_OFFSET for drm files
commit
76ef6b28ea4f81c3d511866a9b31392caa833126 upstream.
Since we have the ttm and gem vma managers using a subset
of the file address space for objects, and these start at
0x100000000 they will overflow the new mmap checks.
I've checked all the mmap routines I could see for any
bad behaviour but overall most people use GEM/TTM VMA
managers even the legacy drivers have a hashtable.
Reported-and-Tested-by: Arthur Marsh (amarsh04 on #radeon)
Fixes:
be83bbf8068 (mmap: introduce sane default mmap limits)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dexuan Cui [Wed, 23 May 2018 21:12:01 +0000 (21:12 +0000)]
PCI: hv: Do not wait forever on a device that has disappeared
commit
c3635da2a336441253c33298b87b3042db100725 upstream.
Before the guest finishes the device initialization, the device can be
removed anytime by the host, and after that the host won't respond to
the guest's request, so the guest should be prepared to handle this
case.
Add a polling mechanism to detect device presence.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
[lorenzo.pieralisi@arm.com: edited commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Blakey [Wed, 30 May 2018 08:29:15 +0000 (11:29 +0300)]
cls_flower: Fix incorrect idr release when failing to modify rule
[ Upstream commit
8258d2da9f9f521dce7019e018360c28d116354e ]
When we fail to modify a rule, we incorrectly release the idr handle
of the unmodified old rule.
Fix that by checking if we need to release it.
Fixes:
fe2502e49b58 ("net_sched: remove cls_flower idr on failure")
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 5 Jun 2018 16:25:19 +0000 (09:25 -0700)]
rtnetlink: validate attributes in do_setlink()
[ Upstream commit
644c7eebbfd59e72982d11ec6cc7d39af12450ae ]
It seems that rtnl_group_changelink() can call do_setlink
while a prior call to validate_linkmsg(dev = NULL, ...) could
not validate IFLA_ADDRESS / IFLA_BROADCAST
Make sure do_setlink() calls validate_linkmsg() instead
of letting its callers having this responsibility.
With help from Dmitry Vyukov, thanks a lot !
BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:199 [inline]
BUG: KMSAN: uninit-value in eth_prepare_mac_addr_change net/ethernet/eth.c:275 [inline]
BUG: KMSAN: uninit-value in eth_mac_addr+0x203/0x2b0 net/ethernet/eth.c:308
CPU: 1 PID: 8695 Comm: syz-executor3 Not tainted 4.17.0-rc5+ #103
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x149/0x260 mm/kmsan/kmsan.c:1084
__msan_warning_32+0x6e/0xc0 mm/kmsan/kmsan_instr.c:686
is_valid_ether_addr include/linux/etherdevice.h:199 [inline]
eth_prepare_mac_addr_change net/ethernet/eth.c:275 [inline]
eth_mac_addr+0x203/0x2b0 net/ethernet/eth.c:308
dev_set_mac_address+0x261/0x530 net/core/dev.c:7157
do_setlink+0xbc3/0x5fc0 net/core/rtnetlink.c:2317
rtnl_group_changelink net/core/rtnetlink.c:2824 [inline]
rtnl_newlink+0x1fe9/0x37a0 net/core/rtnetlink.c:2976
rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x455a09
RSP: 002b:
00007fc07480ec68 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
00007fc07480f6d4 RCX:
0000000000455a09
RDX:
0000000000000000 RSI:
00000000200003c0 RDI:
0000000000000014
RBP:
000000000072bea0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00000000ffffffff
R13:
00000000000005d0 R14:
00000000006fdc20 R15:
0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
__msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:478
do_setlink+0xb84/0x5fc0 net/core/rtnetlink.c:2315
rtnl_group_changelink net/core/rtnetlink.c:2824 [inline]
rtnl_newlink+0x1fe9/0x37a0 net/core/rtnetlink.c:2976
rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb32/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
netlink_sendmsg+0x76e/0x1350 net/netlink/af_netlink.c:1876
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
e7ed828f10bd ("netlink: support setting devgroup parameters")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Tue, 22 May 2018 03:44:31 +0000 (11:44 +0800)]
virtio-net: fix leaking page for gso packet during mergeable XDP
[ Upstream commit
3d62b2a0db505bbf9ed0755f254e45d775f9807f ]
We need to drop refcnt to xdp_page if we see a gso packet. Otherwise
it will be leaked. Fixing this by moving the check of gso packet above
the linearizing logic. While at it, remove useless comment as well.
Cc: John Fastabend <john.fastabend@gmail.com>
Fixes:
72979a6c3590 ("virtio_net: xdp, add slowpath case for non contiguous buffers")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eran Ben Elisha [Tue, 1 May 2018 13:25:07 +0000 (16:25 +0300)]
net/mlx5e: When RXFCS is set, add FCS data into checksum calculation
[ Upstream commit
902a545904c71d719ed144234d67df75f31db63b ]
When RXFCS feature is enabled, the HW do not strip the FCS data,
however it is not present in the checksum calculated by the HW.
Fix that by manually calculating the FCS checksum and adding it to the SKB
checksum field.
Add helper function to find the FCS data for all SKB forms (linear,
one fragment or more).
Fixes:
102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Tue, 22 May 2018 03:44:30 +0000 (11:44 +0800)]
virtio-net: correctly check num_buf during err path
[ Upstream commit
850e088d5bbb333342fd4def08d0a4035f2b7126 ]
If we successfully linearize the packet, num_buf will be set to zero
which may confuse error handling path which assumes num_buf is at
least 1 and this can lead the code tries to pop the descriptor of next
buffer. Fixing this by checking num_buf against 1 before decreasing.
Fixes:
4941d472bf95 ("virtio-net: do not reset during XDP set")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Toshiaki Makita [Mon, 28 May 2018 10:37:49 +0000 (19:37 +0900)]
tun: Fix NULL pointer dereference in XDP redirect
[ Upstream commit
6547e387d7f52f2ba681a229de3c13e5b9e01ee1 ]
Calling XDP redirection requires bh disabled. Softirq can call another
XDP function and redirection functions, then the percpu static variable
ri->map can be overwritten to NULL.
This is a generic XDP case called from tun.
[ 3535.736058] BUG: unable to handle kernel NULL pointer dereference at
0000000000000018
[ 3535.743974] PGD 0 P4D 0
[ 3535.746530] Oops: 0000 [#1] SMP PTI
[ 3535.750049] Modules linked in: vhost_net vhost tap tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat ext4 mbcache jbd2 intel_rapl skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ipmi_ssif irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ses aesni_intel crypto_simd cryptd enclosure hpwdt hpilo glue_helper ipmi_si pcspkr wmi mei_me ioatdma mei ipmi_devintf shpchp dca ipmi_msghandler lpc_ich acpi_power_meter sch_fq_codel ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm smartpqi i40e crc32c_intel scsi_transport_sas tg3 i2c_core ptp pps_core
[ 3535.813456] CPU: 5 PID: 1630 Comm: vhost-1614 Not tainted 4.17.0-rc4 #2
[ 3535.820127] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/14/2017
[ 3535.828732] RIP: 0010:__xdp_map_lookup_elem+0x5/0x30
[ 3535.833740] RSP: 0018:
ffffb4bc47bf7c58 EFLAGS:
00010246
[ 3535.839009] RAX:
ffff9fdfcfea1c40 RBX:
0000000000000000 RCX:
ffff9fdf27fe3100
[ 3535.846205] RDX:
ffff9fdfca769200 RSI:
0000000000000000 RDI:
0000000000000000
[ 3535.853402] RBP:
ffffb4bc491d9000 R08:
00000000000045ad R09:
0000000000000ec0
[ 3535.860597] R10:
0000000000000001 R11:
ffff9fdf26c3ce4e R12:
ffff9fdf9e72c000
[ 3535.867794] R13:
0000000000000000 R14:
fffffffffffffff2 R15:
ffff9fdfc82cdd00
[ 3535.874990] FS:
0000000000000000(0000) GS:
ffff9fdfcfe80000(0000) knlGS:
0000000000000000
[ 3535.883152] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 3535.888948] CR2:
0000000000000018 CR3:
0000000bde724004 CR4:
00000000007626e0
[ 3535.896145] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 3535.903342] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 3535.910538] PKRU:
55555554
[ 3535.913267] Call Trace:
[ 3535.915736] xdp_do_generic_redirect+0x7a/0x310
[ 3535.920310] do_xdp_generic.part.117+0x285/0x370
[ 3535.924970] tun_get_user+0x5b9/0x1260 [tun]
[ 3535.929279] tun_sendmsg+0x52/0x70 [tun]
[ 3535.933237] handle_tx+0x2ad/0x5f0 [vhost_net]
[ 3535.937721] vhost_worker+0xa5/0x100 [vhost]
[ 3535.942030] kthread+0xf5/0x130
[ 3535.945198] ? vhost_dev_ioctl+0x3b0/0x3b0 [vhost]
[ 3535.950031] ? kthread_bind+0x10/0x10
[ 3535.953727] ret_from_fork+0x35/0x40
[ 3535.957334] Code: 0e 74 15 83 f8 10 75 05 e9 49 aa b3 ff f3 c3 0f 1f 80 00 00 00 00 f3 c3 e9 29 9d b3 ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <8b> 47 18 83 f8 0e 74 0d 83 f8 10 75 05 e9 49 a9 b3 ff 31 c0 c3
[ 3535.976387] RIP: __xdp_map_lookup_elem+0x5/0x30 RSP:
ffffb4bc47bf7c58
[ 3535.982883] CR2:
0000000000000018
[ 3535.987096] ---[ end trace
383b299dd1430240 ]---
[ 3536.131325] Kernel panic - not syncing: Fatal exception
[ 3536.137484] Kernel Offset: 0x26a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 3536.281406] ---[ end Kernel panic - not syncing: Fatal exception ]---
And a kernel with generic case fixed still panics in tun driver XDP
redirect, because it disabled only preemption, but not bh.
[ 2055.128746] BUG: unable to handle kernel NULL pointer dereference at
0000000000000018
[ 2055.136662] PGD 0 P4D 0
[ 2055.139219] Oops: 0000 [#1] SMP PTI
[ 2055.142736] Modules linked in: vhost_net vhost tap tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat ext4 mbcache jbd2 intel_rapl skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ses aesni_intel ipmi_ssif crypto_simd enclosure cryptd hpwdt glue_helper ioatdma hpilo wmi dca pcspkr ipmi_si acpi_power_meter ipmi_devintf shpchp mei_me ipmi_msghandler mei lpc_ich sch_fq_codel ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i40e smartpqi tg3 scsi_transport_sas crc32c_intel i2c_core ptp pps_core
[ 2055.206142] CPU: 6 PID: 1693 Comm: vhost-1683 Tainted: G W 4.17.0-rc5-fix-tun+ #1
[ 2055.215011] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/14/2017
[ 2055.223617] RIP: 0010:__xdp_map_lookup_elem+0x5/0x30
[ 2055.228624] RSP: 0018:
ffff998b07607cc0 EFLAGS:
00010246
[ 2055.233892] RAX:
ffff8dbd8e235700 RBX:
ffff8dbd8ff21c40 RCX:
0000000000000004
[ 2055.241089] RDX:
ffff998b097a9000 RSI:
0000000000000000 RDI:
0000000000000000
[ 2055.248286] RBP:
0000000000000000 R08:
00000000000065a8 R09:
0000000000005d80
[ 2055.255483] R10:
0000000000000040 R11:
ffff8dbcf0100000 R12:
ffff998b097a9000
[ 2055.262681] R13:
ffff8dbd8c98c000 R14:
0000000000000000 R15:
ffff998b07607d78
[ 2055.269879] FS:
0000000000000000(0000) GS:
ffff8dbd8ff00000(0000) knlGS:
0000000000000000
[ 2055.278039] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 2055.283834] CR2:
0000000000000018 CR3:
0000000c0c8cc005 CR4:
00000000007626e0
[ 2055.291030] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 2055.298227] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 2055.305424] PKRU:
55555554
[ 2055.308153] Call Trace:
[ 2055.310624] xdp_do_redirect+0x7b/0x380
[ 2055.314499] tun_get_user+0x10fe/0x12a0 [tun]
[ 2055.318895] tun_sendmsg+0x52/0x70 [tun]
[ 2055.322852] handle_tx+0x2ad/0x5f0 [vhost_net]
[ 2055.327337] vhost_worker+0xa5/0x100 [vhost]
[ 2055.331646] kthread+0xf5/0x130
[ 2055.334813] ? vhost_dev_ioctl+0x3b0/0x3b0 [vhost]
[ 2055.339646] ? kthread_bind+0x10/0x10
[ 2055.343343] ret_from_fork+0x35/0x40
[ 2055.346950] Code: 0e 74 15 83 f8 10 75 05 e9 e9 aa b3 ff f3 c3 0f 1f 80 00 00 00 00 f3 c3 e9 c9 9d b3 ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <8b> 47 18 83 f8 0e 74 0d 83 f8 10 75 05 e9 e9 a9 b3 ff 31 c0 c3
[ 2055.366004] RIP: __xdp_map_lookup_elem+0x5/0x30 RSP:
ffff998b07607cc0
[ 2055.372500] CR2:
0000000000000018
[ 2055.375856] ---[ end trace
2a2dcc5e9e174268 ]---
[ 2055.523626] Kernel panic - not syncing: Fatal exception
[ 2055.529796] Kernel Offset: 0x2e000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 2055.677539] ---[ end Kernel panic - not syncing: Fatal exception ]---
v2:
- Removed preempt_disable/enable since local_bh_disable will prevent
preemption as well, feedback from Jason Wang.
Fixes:
761876c857cb ("tap: XDP support")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jack Morgenstein [Wed, 23 May 2018 07:41:59 +0000 (10:41 +0300)]
net/mlx4: Fix irq-unsafe spinlock usage
[ Upstream commit
d546b67cda015fb92bfee93d5dc0ceadb91deaee ]
spin_lock/unlock was used instead of spin_un/lock_irq
in a procedure used in process space, on a spinlock
which can be grabbed in an interrupt.
This caused the stack trace below to be displayed (on kernel
4.17.0-rc1 compiled with Lock Debugging enabled):
[ 154.661474] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
[ 154.668909] 4.17.0-rc1-rdma_rc_mlx+ #3 Tainted: G I
[ 154.675856] -----------------------------------------------------
[ 154.682706] modprobe/10159 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 154.690254]
00000000f3b0e495 (&(&qp_table->lock)->rlock){+.+.}, at: mlx4_qp_remove+0x20/0x50 [mlx4_core]
[ 154.700927]
and this task is already holding:
[ 154.707461]
0000000094373b5d (&(&cq->lock)->rlock/1){....}, at: destroy_qp_common+0x111/0x560 [mlx4_ib]
[ 154.718028] which would create a new lock dependency:
[ 154.723705] (&(&cq->lock)->rlock/1){....} -> (&(&qp_table->lock)->rlock){+.+.}
[ 154.731922]
but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 154.740798] (&(&cq->lock)->rlock){..-.}
[ 154.740800]
... which became SOFTIRQ-irq-safe at:
[ 154.752163] _raw_spin_lock_irqsave+0x3e/0x50
[ 154.757163] mlx4_ib_poll_cq+0x36/0x900 [mlx4_ib]
[ 154.762554] ipoib_tx_poll+0x4a/0xf0 [ib_ipoib]
...
to a SOFTIRQ-irq-unsafe lock:
[ 154.815603] (&(&qp_table->lock)->rlock){+.+.}
[ 154.815604]
... which became SOFTIRQ-irq-unsafe at:
[ 154.827718] ...
[ 154.827720] _raw_spin_lock+0x35/0x50
[ 154.833912] mlx4_qp_lookup+0x1e/0x50 [mlx4_core]
[ 154.839302] mlx4_flow_attach+0x3f/0x3d0 [mlx4_core]
Since mlx4_qp_lookup() is called only in process space, we can
simply replace the spin_un/lock calls with spin_un/lock_irq calls.
Fixes:
6dc06c08bef1 ("net/mlx4: Fix the check in attaching steering rules")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Tue, 22 May 2018 03:44:29 +0000 (11:44 +0800)]
virtio-net: correctly transmit XDP buff after linearizing
[ Upstream commit
5d458a13dd59d04b4d6658a6d5b94d42732b15ae ]
We should not go for the error path after successfully transmitting a
XDP buffer after linearizing. Since the error path may try to pop and
drop next packet and increase the drop counters. Fixing this by simply
drop the refcnt of original page and go for xmit path.
Fixes:
72979a6c3590 ("virtio_net: xdp, add slowpath case for non contiguous buffers")
Cc: John Fastabend <john.fastabend@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Duyck [Thu, 31 May 2018 19:59:46 +0000 (15:59 -0400)]
net-sysfs: Fix memory leak in XPS configuration
[ Upstream commit
664088f8d68178809b848ca450f2797efb34e8e7 ]
This patch reorders the error cases in showing the XPS configuration so
that we hold off on memory allocation until after we have verified that we
can support XPS on a given ring.
Fixes:
184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Tue, 22 May 2018 23:22:26 +0000 (16:22 -0700)]
net: phy: broadcom: Fix auxiliary control register reads
[ Upstream commit
733a969a7ed14fc5786bcc59c1bdda83c7ddb46e ]
We are currently doing auxiliary control register reads with the shadow
register value 0b111 (0x7) which incidentally is also the selector value
that should be present in bits [2:0]. Fix this by using the appropriate
selector mask which is defined (MII_BCM54XX_AUXCTL_SHDWSEL_MASK).
This does not have a functional impact yet because we always access the
MII_BCM54XX_AUXCTL_SHDWSEL_MISC (0x7) register in the current code.
This might change at some point though.
Fixes:
5b4e29005123 ("net: phy: broadcom: add bcm54xx_auxctl_read")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathieu Xhonneux [Fri, 25 May 2018 12:29:41 +0000 (13:29 +0100)]
ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline
[ Upstream commit
bbb40a0b75209734ff9286f3326171638c9f6569 ]
seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
out-of-bounds access when adding the SRH to the packet. This no longer
happen when expanding the skb not only by the size of the SRH (+
outer IPv6 header), but also by skb->mac_len.
[ 53.793056] BUG: KASAN: use-after-free in seg6_do_srh_encap+0x284/0x620
[ 53.794564] Write of size 14 at addr
ffff88011975ecfa by task ping/674
[ 53.796665] CPU: 0 PID: 674 Comm: ping Not tainted 4.17.0-rc3-ARCH+ #90
[ 53.796670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[ 53.796673] Call Trace:
[ 53.796679] <IRQ>
[ 53.796689] dump_stack+0x71/0xab
[ 53.796700] print_address_description+0x6a/0x270
[ 53.796707] kasan_report+0x258/0x380
[ 53.796715] ? seg6_do_srh_encap+0x284/0x620
[ 53.796722] memmove+0x34/0x50
[ 53.796730] seg6_do_srh_encap+0x284/0x620
[ 53.796741] ? seg6_do_srh+0x29b/0x360
[ 53.796747] seg6_do_srh+0x29b/0x360
[ 53.796756] seg6_input+0x2e/0x2e0
[ 53.796765] lwtunnel_input+0x93/0xd0
[ 53.796774] ipv6_rcv+0x690/0x920
[ 53.796783] ? ip6_input+0x170/0x170
[ 53.796791] ? eth_gro_receive+0x2d0/0x2d0
[ 53.796800] ? ip6_input+0x170/0x170
[ 53.796809] __netif_receive_skb_core+0xcc0/0x13f0
[ 53.796820] ? netdev_info+0x110/0x110
[ 53.796827] ? napi_complete_done+0xb6/0x170
[ 53.796834] ? e1000_clean+0x6da/0xf70
[ 53.796845] ? process_backlog+0x129/0x2a0
[ 53.796853] process_backlog+0x129/0x2a0
[ 53.796862] net_rx_action+0x211/0x5c0
[ 53.796870] ? napi_complete_done+0x170/0x170
[ 53.796887] ? run_rebalance_domains+0x11f/0x150
[ 53.796891] __do_softirq+0x10e/0x39e
[ 53.796894] do_softirq_own_stack+0x2a/0x40
[ 53.796895] </IRQ>
[ 53.796898] do_softirq.part.16+0x54/0x60
[ 53.796900] __local_bh_enable_ip+0x5b/0x60
[ 53.796903] ip6_finish_output2+0x416/0x9f0
[ 53.796906] ? ip6_dst_lookup_flow+0x110/0x110
[ 53.796909] ? ip6_sk_dst_lookup_flow+0x390/0x390
[ 53.796911] ? __rcu_read_unlock+0x66/0x80
[ 53.796913] ? ip6_mtu+0x44/0xf0
[ 53.796916] ? ip6_output+0xfc/0x220
[ 53.796918] ip6_output+0xfc/0x220
[ 53.796921] ? ip6_finish_output+0x2b0/0x2b0
[ 53.796923] ? memcpy+0x34/0x50
[ 53.796926] ip6_send_skb+0x43/0xc0
[ 53.796929] rawv6_sendmsg+0x1216/0x1530
[ 53.796932] ? __orc_find+0x6b/0xc0
[ 53.796934] ? rawv6_rcv_skb+0x160/0x160
[ 53.796937] ? __rcu_read_unlock+0x66/0x80
[ 53.796939] ? __rcu_read_unlock+0x66/0x80
[ 53.796942] ? is_bpf_text_address+0x1e/0x30
[ 53.796944] ? kernel_text_address+0xec/0x100
[ 53.796946] ? __kernel_text_address+0xe/0x30
[ 53.796948] ? unwind_get_return_address+0x2f/0x50
[ 53.796950] ? __save_stack_trace+0x92/0x100
[ 53.796954] ? save_stack+0x89/0xb0
[ 53.796956] ? kasan_kmalloc+0xa0/0xd0
[ 53.796958] ? kmem_cache_alloc+0xd2/0x1f0
[ 53.796961] ? prepare_creds+0x23/0x160
[ 53.796963] ? __x64_sys_capset+0x252/0x3e0
[ 53.796966] ? do_syscall_64+0x69/0x160
[ 53.796968] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.796971] ? __alloc_pages_nodemask+0x170/0x380
[ 53.796973] ? __alloc_pages_slowpath+0x12c0/0x12c0
[ 53.796977] ? tty_vhangup+0x20/0x20
[ 53.796979] ? policy_nodemask+0x1a/0x90
[ 53.796982] ? __mod_node_page_state+0x8d/0xa0
[ 53.796986] ? __check_object_size+0xe7/0x240
[ 53.796989] ? __sys_sendto+0x229/0x290
[ 53.796991] ? rawv6_rcv_skb+0x160/0x160
[ 53.796993] __sys_sendto+0x229/0x290
[ 53.796996] ? __ia32_sys_getpeername+0x50/0x50
[ 53.796999] ? commit_creds+0x2de/0x520
[ 53.797002] ? security_capset+0x57/0x70
[ 53.797004] ? __x64_sys_capset+0x29f/0x3e0
[ 53.797007] ? __x64_sys_rt_sigsuspend+0xe0/0xe0
[ 53.797011] ? __do_page_fault+0x664/0x770
[ 53.797014] __x64_sys_sendto+0x74/0x90
[ 53.797017] do_syscall_64+0x69/0x160
[ 53.797019] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.797022] RIP: 0033:0x7f43b7a6714a
[ 53.797023] RSP: 002b:
00007ffd891bd368 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
[ 53.797026] RAX:
ffffffffffffffda RBX:
00000000006129c0 RCX:
00007f43b7a6714a
[ 53.797028] RDX:
0000000000000040 RSI:
00000000006129c0 RDI:
0000000000000004
[ 53.797029] RBP:
00007ffd891be640 R08:
0000000000610940 R09:
000000000000001c
[ 53.797030] R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000040
[ 53.797032] R13:
000000000060e6a0 R14:
0000000000008004 R15:
000000000040b661
[ 53.797171] Allocated by task 642:
[ 53.797460] kasan_kmalloc+0xa0/0xd0
[ 53.797463] kmem_cache_alloc+0xd2/0x1f0
[ 53.797465] getname_flags+0x40/0x210
[ 53.797467] user_path_at_empty+0x1d/0x40
[ 53.797469] do_faccessat+0x12a/0x320
[ 53.797471] do_syscall_64+0x69/0x160
[ 53.797473] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.797607] Freed by task 642:
[ 53.797869] __kasan_slab_free+0x130/0x180
[ 53.797871] kmem_cache_free+0xa8/0x230
[ 53.797872] filename_lookup+0x15b/0x230
[ 53.797874] do_faccessat+0x12a/0x320
[ 53.797876] do_syscall_64+0x69/0x160
[ 53.797878] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.798014] The buggy address belongs to the object at
ffff88011975e600
which belongs to the cache names_cache of size 4096
[ 53.799043] The buggy address is located 1786 bytes inside of
4096-byte region [
ffff88011975e600,
ffff88011975f600)
[ 53.800013] The buggy address belongs to the page:
[ 53.800414] page:
ffffea000465d600 count:1 mapcount:0
mapping:
0000000000000000 index:0x0 compound_mapcount: 0
[ 53.801259] flags: 0x17fff0000008100(slab|head)
[ 53.801640] raw:
017fff0000008100 0000000000000000 0000000000000000
0000000100070007
[ 53.803147] raw:
dead000000000100 dead000000000200 ffff88011b185a40
0000000000000000
[ 53.803787] page dumped because: kasan: bad access detected
[ 53.804384] Memory state around the buggy address:
[ 53.804788]
ffff88011975eb80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.805384]
ffff88011975ec00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.805979] >
ffff88011975ec80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.806577] ^
[ 53.807165]
ffff88011975ed00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.807762]
ffff88011975ed80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.808356] ==================================================================
[ 53.808949] Disabling lock debugging due to kernel taint
Fixes:
6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <dlebrun@google.com>
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Suryaputra [Fri, 1 Jun 2018 04:05:21 +0000 (00:05 -0400)]
vrf: check the original netdevice for generating redirect
[ Upstream commit
2f17becfbea5e9a0529b51da7345783e96e69516 ]
Use the right device to determine if redirect should be sent especially
when using vrf. Same as well as when sending the redirect.
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Tue, 22 May 2018 11:58:57 +0000 (19:58 +0800)]
vhost: synchronize IOTLB message with dev cleanup
[ Upstream commit
1b15ad683ab42a203f98b67045b40720e99d0e9a ]
DaeRyong Jeong reports a race between vhost_dev_cleanup() and
vhost_process_iotlb_msg():
Thread interleaving:
CPU0 (vhost_process_iotlb_msg) CPU1 (vhost_dev_cleanup)
(In the case of both VHOST_IOTLB_UPDATE and
VHOST_IOTLB_INVALIDATE)
===== =====
vhost_umem_clean(dev->iotlb);
if (!dev->iotlb) {
ret = -EFAULT;
break;
}
dev->iotlb = NULL;
The reason is we don't synchronize between them, fixing by protecting
vhost_process_iotlb_msg() with dev mutex.
Reported-by: DaeRyong Jeong <threeearcat@gmail.com>
Fixes:
6b1e6cc7855b0 ("vhost: new device IOTLB API")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 4 Jun 2018 14:46:01 +0000 (17:46 +0300)]
team: use netdev_features_t instead of u32
[ Upstream commit
25ea66544bfd1d9df1b7e1502f8717e85fa1e6e6 ]
This code was introduced in 2011 around the same time that we made
netdev_features_t a u64 type. These days a u32 is not big enough to
hold all the potential features.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Tue, 5 Jun 2018 04:16:58 +0000 (12:16 +0800)]
sctp: not allow transport timeout value less than HZ/5 for hb_timer
[ Upstream commit
1d88ba1ebb2763aa86172cd7ca05dedbeccc0d35 ]
syzbot reported a rcu_sched self-detected stall on CPU which is caused
by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
value, hb_timer will get stuck there, as in its timer handler it starts
this timer again with this value, then goes to the timer handler again.
This problem is there since very beginning, and thanks to Eric for the
reproducer shared from a syzbot mail.
This patch fixes it by not allowing sctp_transport_timeout to return a
smaller value than HZ/5 for hb_timer, which is based on TCP's min rto.
Note that it doesn't fix this issue by limiting rto_min, as some users
are still using small rto and no proper value was found for it yet.
Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shahed Shaikh [Mon, 21 May 2018 19:31:47 +0000 (12:31 -0700)]
qed: Fix mask for physical address in ILT entry
[ Upstream commit
fdd13dd350dda1826579eb5c333d76b14513b812 ]
ILT entry requires 12 bit right shifted physical address.
Existing mask for ILT entry of physical address i.e.
ILT_ENTRY_PHY_ADDR_MASK is not sufficient to handle 64bit
address because upper 8 bits of 64 bit address were getting
masked which resulted in completer abort error on
PCIe bus due to invalid address.
Fix that mask to handle 64bit physical address.
Fixes:
fe56b9e6a8d9 ("qed: Add module with basic common support")
Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willem de Bruijn [Thu, 24 May 2018 22:10:30 +0000 (18:10 -0400)]
packet: fix reserve calculation
[ Upstream commit
9aad13b087ab0a588cd68259de618f100053360e ]
Commit
b84bbaf7a6c8 ("packet: in packet_snd start writing at link
layer allocation") ensures that packet_snd always starts writing
the link layer header in reserved headroom allocated for this
purpose.
This is needed because packets may be shorter than hard_header_len,
in which case the space up to hard_header_len may be zeroed. But
that necessary padding is not accounted for in skb->len.
The fix, however, is buggy. It calls skb_push, which grows skb->len
when moving skb->data back. But in this case packet length should not
change.
Instead, call skb_reserve, which moves both skb->data and skb->tail
back, without changing length.
Fixes:
b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
Reported-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Palmas [Thu, 31 May 2018 09:18:29 +0000 (11:18 +0200)]
net: usb: cdc_mbim: add flag FLAG_SEND_ZLP
[ Upstream commit
9f7c728332e8966084242fcd951aa46583bc308c ]
Testing Telit LM940 with ICMP packets > 14552 bytes revealed that
the modem needs FLAG_SEND_ZLP to properly work, otherwise the cdc
mbim data interface won't be anymore responsive.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Wed, 23 May 2018 00:04:49 +0000 (17:04 -0700)]
net: phy: broadcom: Fix bcm_write_exp()
[ Upstream commit
79fb218d97980d4fee9a64f4c8ff05289364ba25 ]
On newer PHYs, we need to select the expansion register to write with
setting bits [11:8] to 0xf. This was done correctly by bcm7xxx.c prior
to being migrated to generic code under bcm-phy-lib.c which
unfortunately used the older implementation from the BCM54xx days.
Fix this by creating an inline stub: bcm_write_exp_sel() which adds the
correct value (MII_BCM54XX_EXP_SEL_ER) and update both the Cygnus PHY
and BCM7xxx PHY drivers which require setting these bits.
broadcom.c is unchanged because some PHYs even use a different selector
method, so let them specify it directly (e.g: SerDes secondary selector).
Fixes:
a1cba5613edf ("net: phy: Add Broadcom phy library for common interfaces")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 1 Jun 2018 16:23:02 +0000 (09:23 -0700)]
net/packet: refine check for priv area size
[ Upstream commit
eb73190f4fbeedf762394e92d6a4ec9ace684c88 ]
syzbot was able to trick af_packet again [1]
Various commits tried to address the problem in the past,
but failed to take into account V3 header size.
[1]
tpacket_rcv: packet too big, clamped from 72 to
4294967224. macoff=96
BUG: KASAN: use-after-free in prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]
BUG: KASAN: use-after-free in prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039
Write of size 2 at addr
ffff8801cb62000e by task kworker/1:2/2106
CPU: 1 PID: 2106 Comm: kworker/1:2 Not tainted 4.17.0-rc7+ #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_store2_noabort+0x17/0x20 mm/kasan/report.c:436
prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]
prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039
__packet_lookup_frame_in_block net/packet/af_packet.c:1094 [inline]
packet_current_rx_frame net/packet/af_packet.c:1117 [inline]
tpacket_rcv+0x1866/0x3340 net/packet/af_packet.c:2282
dev_queue_xmit_nit+0x891/0xb90 net/core/dev.c:2018
xmit_one net/core/dev.c:3049 [inline]
dev_hard_start_xmit+0x16b/0xc10 net/core/dev.c:3069
__dev_queue_xmit+0x2724/0x34c0 net/core/dev.c:3584
dev_queue_xmit+0x17/0x20 net/core/dev.c:3617
neigh_resolve_output+0x679/0xad0 net/core/neighbour.c:1358
neigh_output include/net/neighbour.h:482 [inline]
ip6_finish_output2+0xc9c/0x2810 net/ipv6/ip6_output.c:120
ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip6_output+0x227/0x9b0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:288 [inline]
ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491
ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633
addrconf_dad_work+0xbef/0x1340 net/ipv6/addrconf.c:4033
process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the page:
page:
ffffea00072d8800 count:0 mapcount:-127 mapping:
0000000000000000 index:0xffff8801cb620e80
flags: 0x2fffc0000000000()
raw:
02fffc0000000000 0000000000000000 ffff8801cb620e80 00000000ffffff80
raw:
ffffea00072e3820 ffffea0007132d20 0000000000000002 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801cb61ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801cb61ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
ffff8801cb620000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff8801cb620080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8801cb620100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Fixes:
2b6867c2ce76 ("net/packet: fix overflow in check for priv area size")
Fixes:
dc808110bb62 ("packet: handle too big packets for PACKET_V3")
Fixes:
f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 5 Jun 2018 13:06:19 +0000 (06:06 -0700)]
net: metrics: add proper netlink validation
[ Upstream commit
5b5e7a0de2bbf2a1afcd9f49e940010e9fb80d53 ]
Before using nla_get_u32(), better make sure the attribute
is of the proper size.
Code recently was changed, but bug has been there from beginning
of git.
BUG: KMSAN: uninit-value in rtnetlink_put_metrics+0x553/0x960 net/core/rtnetlink.c:746
CPU: 1 PID: 14139 Comm: syz-executor6 Not tainted 4.17.0-rc5+ #103
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x149/0x260 mm/kmsan/kmsan.c:1084
__msan_warning_32+0x6e/0xc0 mm/kmsan/kmsan_instr.c:686
rtnetlink_put_metrics+0x553/0x960 net/core/rtnetlink.c:746
fib_dump_info+0xc42/0x2190 net/ipv4/fib_semantics.c:1361
rtmsg_fib+0x65f/0x8c0 net/ipv4/fib_semantics.c:419
fib_table_insert+0x2314/0x2b50 net/ipv4/fib_trie.c:1287
inet_rtm_newroute+0x210/0x340 net/ipv4/fib_frontend.c:779
rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x455a09
RSP: 002b:
00007faae5fd8c68 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
00007faae5fd96d4 RCX:
0000000000455a09
RDX:
0000000000000000 RSI:
0000000020000000 RDI:
0000000000000013
RBP:
000000000072bea0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00000000ffffffff
R13:
00000000000005d0 R14:
00000000006fdc20 R15:
0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:529
fib_convert_metrics net/ipv4/fib_semantics.c:1056 [inline]
fib_create_info+0x2d46/0x9dc0 net/ipv4/fib_semantics.c:1150
fib_table_insert+0x3e4/0x2b50 net/ipv4/fib_trie.c:1146
inet_rtm_newroute+0x210/0x340 net/ipv4/fib_frontend.c:779
rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb32/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
netlink_sendmsg+0x76e/0x1350 net/netlink/af_netlink.c:1876
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
a919525ad832 ("net: Move fib_convert_metrics to metrics file")
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roopa Prabhu [Tue, 22 May 2018 20:44:51 +0000 (13:44 -0700)]
net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy
[ Upstream commit
2eabd764cb5512f1338d06ffc054c8bc9fbe9104 ]
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Wang [Tue, 5 Jun 2018 16:48:13 +0000 (09:48 -0700)]
netdev-FAQ: clarify DaveM's position for stable backports
[ Upstream commit
75d4e704fa8d2cf33ff295e5b441317603d7f9fd ]
Per discussion with David at netconf 2018, let's clarify
DaveM's position of handling stable backports in netdev-FAQ.
This is important for people relying on upstream -stable
releases.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Fri, 1 Jun 2018 11:30:38 +0000 (14:30 +0300)]
kcm: Fix use-after-free caused by clonned sockets
[ Upstream commit
eb7f54b90bd8f469834c5e86dcf72ebf9a629811 ]
(resend for properly queueing in patchwork)
kcm_clone() creates kernel socket, which does not take net counter.
Thus, the net may die before the socket is completely destructed,
i.e. kcm_exit_net() is executed before kcm_done().
Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wenwen Wang [Mon, 21 May 2018 06:58:07 +0000 (01:58 -0500)]
isdn: eicon: fix a missing-check bug
[ Upstream commit
6009d1fe6ba3bb2dab55921da60465329cc1cd89 ]
In divasmain.c, the function divas_write() firstly invokes the function
diva_xdi_open_adapter() to open the adapter that matches with the adapter
number provided by the user, and then invokes the function diva_xdi_write()
to perform the write operation using the matched adapter. The two functions
diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
from the userspace pointer 'src' through the function pointer 'cp_fn',
which eventually calls copy_from_user() to do the copy. Then, the adapter
number 'msg.adapter' is used to find out a matched adapter from the
'adapter_queue'. A matched adapter will be returned if it is found.
Otherwise, NULL is returned to indicate the failure of the verification on
the adapter number.
As mentioned above, if a matched adapter is returned, the function
diva_xdi_write() is invoked to perform the write operation. In this
function, the user command is copied once again from the userspace pointer
'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
both of them are from the 'buf' pointer in divas_write(). Similarly, the
copy is achieved through the function pointer 'cp_fn', which finally calls
copy_from_user(). After the successful copy, the corresponding command
processing handler of the matched adapter is invoked to perform the write
operation.
It is obvious that there are two copies here from userspace, one is in
diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
these two copies share the same source userspace pointer, i.e., the 'buf'
pointer in divas_write(). Given that a malicious userspace process can race
to change the content pointed by the 'buf' pointer, this can pose potential
security issues. For example, in the first copy, the user provides a valid
adapter number to pass the verification process and a valid adapter can be
found. Then the user can modify the adapter number to an invalid number.
This way, the user can bypass the verification process of the adapter
number and inject inconsistent data.
This patch reuses the data copied in
diva_xdi_open_adapter() and passes it to diva_xdi_write(). This way, the
above issues can be avoided.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Kubecek [Mon, 4 Jun 2018 09:36:05 +0000 (11:36 +0200)]
ipv6: omit traffic class when calculating flow hash
[ Upstream commit
fa1be7e01ea863e911349e30456706749518eeab ]
Some of the code paths calculating flow hash for IPv6 use flowlabel member
of struct flowi6 which, despite its name, encodes both flow label and
traffic class. If traffic class changes within a TCP connection (as e.g.
ssh does), ECMP route can switch between path. It's also inconsistent with
other code paths where ip6_flowlabel() (returning only flow label) is used
to feed the key.
Use only flow label everywhere, including one place where hash key is set
using ip6_flowinfo().
Fixes:
51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
Fixes:
f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willem de Bruijn [Wed, 23 May 2018 18:29:52 +0000 (14:29 -0400)]
ipv4: remove warning in ip_recv_error
[ Upstream commit
730c54d59403658a62af6517338fa8d4922c1b28 ]
A precondition check in ip_recv_error triggered on an otherwise benign
race. Remove the warning.
The warning triggers when passing an ipv6 socket to this ipv4 error
handling function. RaceFuzzer was able to trigger it due to a race
in setsockopt IPV6_ADDRFORM.
---
CPU0
do_ipv6_setsockopt
sk->sk_socket->ops = &inet_dgram_ops;
---
CPU1
sk->sk_prot->recvmsg
udp_recvmsg
ip_recv_error
WARN_ON_ONCE(sk->sk_family == AF_INET6);
---
CPU0
do_ipv6_setsockopt
sk->sk_family = PF_INET;
This socket option converts a v6 socket that is connected to a v4 peer
to an v4 socket. It updates the socket on the fly, changing fields in
sk as well as other structs. This is inherently non-atomic. It races
with the lockless udp_recvmsg path.
No other code makes an assumption that these fields are updated
atomically. It is benign here, too, as ip_recv_error cares only about
the protocol of the skbs enqueued on the error queue, for which
sk_family is not a precise predictor (thanks to another isue with
IPV6_ADDRFORM).
Link: http://lkml.kernel.org/r/20180518120826.GA19515@dragonet.kaist.ac.kr
Fixes:
7ce875e5ecb8 ("ipv4: warn once on passing AF_INET6 socket to ip_recv_error")
Reported-by: DaeRyong Jeong <threeearcat@gmail.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Mon, 21 May 2018 17:51:53 +0000 (10:51 -0700)]
ipmr: properly check rhltable_init() return value
[ Upstream commit
66fb33254f45df4b049f487aff1cbde1ef919390 ]
commit
8fb472c09b9d ("ipmr: improve hash scalability")
added a call to rhltable_init() without checking its return value.
This problem was then later copied to IPv6 and factorized in commit
0bbbf0e7d0e7 ("ipmr, ip6mr: Unite creation of new mr_table")
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 31552 Comm: syz-executor7 Not tainted 4.17.0-rc5+ #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:rht_key_hashfn include/linux/rhashtable.h:277 [inline]
RIP: 0010:__rhashtable_lookup include/linux/rhashtable.h:630 [inline]
RIP: 0010:rhltable_lookup include/linux/rhashtable.h:716 [inline]
RIP: 0010:mr_mfc_find_parent+0x2ad/0xbb0 net/ipv4/ipmr_base.c:63
RSP: 0018:
ffff8801826aef70 EFLAGS:
00010203
RAX:
0000000000000001 RBX:
0000000000000001 RCX:
ffffc90001ea0000
RDX:
0000000000000079 RSI:
ffffffff8661e859 RDI:
000000000000000c
RBP:
ffff8801826af1c0 R08:
ffff8801b2212000 R09:
ffffed003b5e46c2
R10:
ffffed003b5e46c2 R11:
ffff8801daf23613 R12:
dffffc0000000000
R13:
ffff8801826af198 R14:
ffff8801cf8225c0 R15:
ffff8801826af658
FS:
00007ff7fa732700(0000) GS:
ffff8801daf00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000003ffffff9c CR3:
00000001b0210000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
ip6mr_cache_find_parent net/ipv6/ip6mr.c:981 [inline]
ip6mr_mfc_delete+0x1fe/0x6b0 net/ipv6/ip6mr.c:1221
ip6_mroute_setsockopt+0x15c6/0x1d70 net/ipv6/ip6mr.c:1698
do_ipv6_setsockopt.isra.9+0x422/0x4660 net/ipv6/ipv6_sockglue.c:163
ipv6_setsockopt+0xbd/0x170 net/ipv6/ipv6_sockglue.c:922
rawv6_setsockopt+0x59/0x140 net/ipv6/raw.c:1060
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3039
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes:
8fb472c09b9d ("ipmr: improve hash scalability")
Fixes:
0bbbf0e7d0e7 ("ipmr, ip6mr: Unite creation of new mr_table")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: Yuval Mintz <yuvalm@mellanox.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Dichtel [Thu, 31 May 2018 08:59:33 +0000 (10:59 +0200)]
ip6_tunnel: remove magic mtu value 0xFFF8
[ Upstream commit
f7ff1fde9441b4fcc8ffb6e66e6e5a00d008937e ]
I don't know where this value comes from (probably a copy and paste and
paste and paste ...).
Let's use standard values which are a bit greater.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sabrina Dubroca [Tue, 5 Jun 2018 13:01:59 +0000 (15:01 +0200)]
ip6mr: only set ip6mr_table from setsockopt when ip6mr_new_table succeeds
[ Upstream commit
848235edb5c93ed086700584c8ff64f6d7fc778d ]
Currently, raw6_sk(sk)->ip6mr_table is set unconditionally during
ip6_mroute_setsockopt(MRT6_TABLE). A subsequent attempt at the same
setsockopt will fail with -ENOENT, since we haven't actually created
that table.
A similar fix for ipv4 was included in commit
5e1859fbcc3c ("ipv4: ipmr:
various fixes and cleanups").
Fixes:
d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Govindarajulu Varadarajan [Wed, 23 May 2018 18:17:39 +0000 (11:17 -0700)]
enic: set DMA mask to 47 bit
[ Upstream commit
322eaa06d55ebc1402a4a8d140945cff536638b4 ]
In commit
624dbf55a359b ("driver/net: enic: Try DMA 64 first, then
failover to DMA") DMA mask was changed from 40 bits to 64 bits.
Hardware actually supports only 47 bits.
Fixes:
624dbf55a359b ("driver/net: enic: Try DMA 64 first, then failover to DMA")
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Kodanev [Mon, 21 May 2018 16:28:44 +0000 (19:28 +0300)]
dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()
[ Upstream commit
2677d20677314101293e6da0094ede7b5526d2b1 ]
Syzbot reported the use-after-free in timer_is_static_object() [1].
This can happen because the structure for the rto timer (ccid2_hc_tx_sock)
is removed in dccp_disconnect(), and ccid2_hc_tx_rto_expire() can be
called after that.
The report [1] is similar to the one in commit
120e9dabaf55 ("dccp:
defer ccid_hc_tx_delete() at dismantle time"). And the fix is the same,
delay freeing ccid2_hc_tx_sock structure, so that it is freed in
dccp_sk_destruct().
[1]
==================================================================
BUG: KASAN: use-after-free in timer_is_static_object+0x80/0x90
kernel/time/timer.c:607
Read of size 8 at addr
ffff8801bebb5118 by task syz-executor2/25299
CPU: 1 PID: 25299 Comm: syz-executor2 Not tainted 4.17.0-rc5+ #54
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
timer_is_static_object+0x80/0x90 kernel/time/timer.c:607
debug_object_activate+0x2d9/0x670 lib/debugobjects.c:508
debug_timer_activate kernel/time/timer.c:709 [inline]
debug_activate kernel/time/timer.c:764 [inline]
__mod_timer kernel/time/timer.c:1041 [inline]
mod_timer+0x4d3/0x13b0 kernel/time/timer.c:1102
sk_reset_timer+0x22/0x60 net/core/sock.c:2742
ccid2_hc_tx_rto_expire+0x587/0x680 net/dccp/ccids/ccid2.c:147
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
...
Allocated by task 25374:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
ccid_new+0x25b/0x3e0 net/dccp/ccid.c:151
dccp_hdlr_ccid+0x27/0x150 net/dccp/feat.c:44
__dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
dccp_feat_activate_values+0x3a7/0x819 net/dccp/feat.c:1538
dccp_create_openreq_child+0x472/0x610 net/dccp/minisocks.c:128
dccp_v4_request_recv_sock+0x12c/0xca0 net/dccp/ipv4.c:408
dccp_v6_request_recv_sock+0x125d/0x1f10 net/dccp/ipv6.c:415
dccp_check_req+0x455/0x6a0 net/dccp/minisocks.c:197
dccp_v4_rcv+0x7b8/0x1f3f net/dccp/ipv4.c:841
ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
__netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
process_backlog+0x219/0x760 net/core/dev.c:5337
napi_poll net/core/dev.c:5735 [inline]
net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
Freed by task 25374:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
ccid_hc_tx_delete+0xc3/0x100 net/dccp/ccid.c:190
dccp_disconnect+0x130/0xc66 net/dccp/proto.c:286
dccp_close+0x3bc/0xe60 net/dccp/proto.c:1045
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:460
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:191 [inline]
exit_to_usermode_loop+0x2bd/0x310 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at
ffff8801bebb4cc0
which belongs to the cache ccid2_hc_tx_sock of size 1240
The buggy address is located 1112 bytes inside of
1240-byte region [
ffff8801bebb4cc0,
ffff8801bebb5198)
The buggy address belongs to the page:
page:
ffffea0006faed00 count:1 mapcount:0 mapping:
ffff8801bebb41c0
index:0xffff8801bebb5240 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw:
02fffc0000008100 ffff8801bebb41c0 ffff8801bebb5240 0000000100000003
raw:
ffff8801cdba3138 ffffea0007634120 ffff8801cdbaab40 0000000000000000
page dumped because: kasan: bad access detected
...
==================================================================
Reported-by: syzbot+5d47e9ec91a6f15dbd6f@syzkaller.appspotmail.com
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julia Lawall [Wed, 6 Jun 2018 13:03:22 +0000 (15:03 +0200)]
bnx2x: use the right constant
[ Upstream commit
dd612f18a49b63af8b3a5f572d999bdb197385bc ]
Nearby code that also tests port suggests that the P0 constant should be
used when port is zero.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e,e1;
@@
* e ? e1 : e1
// </smpl>
Fixes:
6c3218c6f7e5 ("bnx2x: Adjust ETS to 578xx")
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suresh Reddy [Mon, 28 May 2018 05:26:06 +0000 (01:26 -0400)]
be2net: Fix error detection logic for BE3
[ Upstream commit
d2c2725c2cdbcc108a191f50953d31c7b6556761 ]
Check for 0xE00 (RECOVERABLE_ERR) along with ARMFW UE (0x0)
in be_detect_error() to know whether the error is valid error or not
Fixes:
673c96e5a ("be2net: Fix UE detection logic for BE3")
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nathan Chancellor [Sat, 2 Jun 2018 16:02:09 +0000 (09:02 -0700)]
kconfig: Avoid format overflow warning from GCC 8.1
commit
2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream.
In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
sprintf(newname, "%s%s", dirname, basename);
^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
sprintf(newname, "%s%s", dirname, basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Increase the size of tmpname and newname to make GCC happy.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anand Jain [Tue, 9 Jan 2018 01:05:41 +0000 (09:05 +0800)]
btrfs: define SUPER_FLAG_METADUMP_V2
commit
e2731e55884f2138a252b0a3d7b24d57e49c3c59 upstream.
btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34).
So just define that in kernel so that we know its been used.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Sat, 19 May 2018 16:29:11 +0000 (09:29 -0700)]
mmap: relax file size limit for regular files
commit
423913ad4ae5b3e8fb8983f70969fb522261ba26 upstream.
Commit
be83bbf80682 ("mmap: introduce sane default mmap limits") was
introduced to catch problems in various ad-hoc character device drivers
doing mmap and getting the size limits wrong. In the process, it used
"known good" limits for the normal cases of mapping regular files and
block device drivers.
It turns out that the "s_maxbytes" limit was less "known good" than I
thought. In particular, /proc doesn't set it, but exposes one regular
file to mmap: /proc/vmcore. As a result, that file got limited to the
default MAX_INT s_maxbytes value.
This went unnoticed for a while, because apparently the only thing that
needs it is the s390 kernel zfcpdump, but there might be other tools
that use this too.
Vasily suggested just changing s_maxbytes for all of /proc, which isn't
wrong, but makes me nervous at this stage. So instead, just make the
new mmap limit always be MAX_LFS_FILESIZE for regular files, which won't
affect anything else. It wasn't the regular file case I was worried
about.
I'd really prefer for maxsize to have been per-inode, but that is not
how things are today.
Fixes:
be83bbf80682 ("mmap: introduce sane default mmap limits")
Reported-by: Vasily Gorbik <gor@linux.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>