Sasha Levin [Sun, 14 Aug 2016 22:08:43 +0000 (18:08 -0400)]
iwlwifi: add new 8260 PCI IDs
[ Upstream commit
4b79deece5d45396422d469afa11f9d69ccb3d8b ]
Add 3 new 8260 series PCI IDs:
- (0x24F3, 0x10B0)
- (0x24F3, 0xD0B0)
- (0x24F3, 0xB0B0)
CC: <stable@vger.kernel.org> [4.1+]
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Hans de Goede [Sat, 4 Jun 2016 10:58:39 +0000 (12:58 +0200)]
ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys
[ Upstream commit
fc51b632c7b047c25807023b76f3877aed19c770 ]
It seems that recent kernels have a shorter timeout when scanning for
ethernet phys causing us to hit a timeout on boards where the phy's
regulator gets enabled just before scanning, which leads to non working
ethernet.
A 10ms startup delay seems to be enough to fix it, this commit adds a
20ms startup delay just to be safe.
This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board,
both of which have non-working ethernet on recent kernels without this
fix.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Vegard Nossum [Mon, 4 Jul 2016 15:03:00 +0000 (11:03 -0400)]
ext4: don't call ext4_should_journal_data() on the journal inode
[ Upstream commit
6a7fd522a7c94cdef0a3b08acf8e6702056e635c ]
If ext4_fill_super() fails early, it's possible for ext4_evict_inode()
to call ext4_should_journal_data() before superblock options and flags
are fully set up. In that case, the iput() on the journal inode can
end up causing a BUG().
Work around this problem by reordering the tests so we only call
ext4_should_journal_data() after we know it's not the journal inode.
Fixes:
2d859db3e4 ("ext4: fix data corruption in inodes with journalled data")
Fixes:
2b405bfa84 ("ext4: fix data=journal fast mount/umount hang")
Cc: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jan Kara [Mon, 4 Jul 2016 14:14:01 +0000 (10:14 -0400)]
ext4: fix deadlock during page writeback
[ Upstream commit
646caa9c8e196880b41cd3e3d33a2ebc752bdb85 ]
Commit
06bd3c36a733 (ext4: fix data exposure after a crash) uncovered a
deadlock in ext4_writepages() which was previously much harder to hit.
After this commit xfstest generic/130 reproduces the deadlock on small
filesystems.
The problem happens when ext4_do_update_inode() sets LARGE_FILE feature
and marks current inode handle as synchronous. That subsequently results
in ext4_journal_stop() called from ext4_writepages() to block waiting for
transaction commit while still holding page locks, reference to io_end,
and some prepared bio in mpd structure each of which can possibly block
transaction commit from completing and thus results in deadlock.
Fix the problem by releasing page locks, io_end reference, and
submitting prepared bio before calling ext4_journal_stop().
[ Changed to defer the call to ext4_journal_stop() only if the handle
is synchronous. --tytso ]
Reported-and-tested-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Trond Myklebust [Fri, 24 Jun 2016 14:55:44 +0000 (10:55 -0400)]
SUNRPC: Don't allocate a full sockaddr_storage for tracing
[ Upstream commit
db1bb44c4c7e8d49ed674dc59e5222d99c698088 ]
We're always tracing IPv4 or IPv6 addresses, so we can save a lot
of space on the ringbuffer by allocating the correct sockaddr size.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: stable@vger.kernel.org
Fixes:
83a712e0afef "sunrpc: add some tracepoints around ..."
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Vegard Nossum [Thu, 30 Jun 2016 15:53:46 +0000 (11:53 -0400)]
ext4: check for extents that wrap around
[ Upstream commit
f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 ]
An extent with lblock =
4294967295 and len = 1 will pass the
ext4_valid_extent() test:
ext4_lblk_t last = lblock + len - 1;
if (len == 0 || lblock > last)
return 0;
since last =
4294967295 + 1 - 1 =
4294967295. This would later trigger
the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end().
We can simplify it by removing the - 1 altogether and changing the test
to use lblock + len <= lblock, since now if len = 0, then lblock + 0 ==
lblock and it fails, and if len > 0 then lblock + len > lblock in order
to pass (i.e. it doesn't overflow).
Fixes:
5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
Fixes:
2f974865f ("ext4: check for zero length extent explicitly")
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Linus Walleij [Wed, 22 Jun 2016 06:27:17 +0000 (08:27 +0200)]
mfd: qcom_rpm: Parametrize also ack selector size
[ Upstream commit
f37be01e6dc606f2fcc5e95c9933d948ce19bd35 ]
The RPM has two sets of selectors (IPC bit fields): request and
acknowledge. Apparently, some models use 4*32 bit words for select
and some use 7*32 bit words for request, but all use 7*32 words
for acknowledge bits.
So apparently you can on the models with requests of 4*32 select
bits send 4*32 messages and get 7*32 different replies, so on ACK
interrupt, 7*32 bit words need to be read. This is how the vendor
code apparently works.
Cc: stable@vger.kernel.org
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Linus Walleij [Tue, 14 Jun 2016 23:02:26 +0000 (01:02 +0200)]
mfd: qcom_rpm: Fix offset error for msm8660
[ Upstream commit
9835f1b70bb3890d38308b9be4fb9d7451ba67f1 ]
The RPM in MSM8660/APQ8060 has different offsets to the selector
ACK and request context ACK registers. Make all these register
offsets part of the per-SoC data and assign the right values.
The bug was found by verifying backwards to the vendor tree in
the out-of-tree files <mach/rpm-[8660|8064|8960]>: all were using
offsets 3,11,15,23 and a select size of 4, except the MSM8660/APQ8060
which was using offsets 3,11,19,27 and a select size of 7.
All other platforms apart from msm8660 were affected by reading
excess registers, since 7 was hardcoded as the number of select
words, this patch makes also this part dynamic so we only write/read
as many select words as the platform actually use.
Symptoms of this bug when using msm8660: the first RPM transaction
would work, but the next would stall or raise an error since the
previous transaction was not properly ACKed as the ACK words were
read at the wrong offset.
Cc: stable@vger.kernel.org
Fixes:
58e214382bdd ("mfd: qcom-rpm: Driver for the Qualcomm RPM")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Björn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Yoshihiro Shimoda [Wed, 8 Jun 2016 07:32:50 +0000 (16:32 +0900)]
usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()
[ Upstream commit
15e4292a2d21e9997fdb2b8c014cc461b3f268f0 ]
This patch fixes an issue that the CFIFOSEL register value is possible
to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer
using CFIFO may not work correctly.
For example:
# modprobe g_multi file=usb-storage.bin
# ifconfig usb0 192.168.1.1 up
(During the USB host is sending file to the mass storage)
# ifconfig usb0 down
In this case, since the u_ether.c may call usb_ep_enable() in
eth_stop(), if the renesas_usbhs driver is also using CFIFO for
mass storage, the mass storage may not work correctly.
So, this patch adds usbhs_lock() and usbhs_unlock() calling in
usbhsg_ep_enable() to protect CFIFOSEL register. This is because:
- CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration
- The CFIFOSEL (fifo->sel) is already protected by usbhs_lock()
Fixes:
97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Yoshihiro Shimoda [Wed, 8 Jun 2016 07:32:49 +0000 (16:32 +0900)]
usb: renesas_usbhs: fix NULL pointer dereference in xfer_work()
[ Upstream commit
4fdef698383db07d829da567e0e405fc41ff3a89 ]
This patch fixes an issue that the xfer_work() is possible to cause
NULL pointer dereference if the usb cable is disconnected while data
transfer is running.
In such case, a gadget driver may call usb_ep_disable()) before
xfer_work() is actually called. In this case, the usbhs_pkt_pop()
will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo()
in xfer_work() will return NULL.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Alex Hung [Mon, 13 Jun 2016 11:44:00 +0000 (19:44 +0800)]
hp-wmi: Fix wifi cannot be hard-unblocked
[ Upstream commit
fc8a601e1175ae351f662506030f9939cb7fdbfe ]
Several users reported wifi cannot be unblocked as discussed in [1].
This patch removes the use of the 2009 flag by BIOS but uses the actual
WMI function calls - it will be skipped if WMI reports unsupported.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=69131
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Tested-by: Evgenii Shatokhin <eugene.shatokhin@yandex.ru>
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Krzysztof Kozlowski [Thu, 16 Jun 2016 06:27:35 +0000 (08:27 +0200)]
serial: samsung: Fix ERR pointer dereference on deferred probe
[ Upstream commit
e51e4d8a185de90424b03f30181b35f29c46a25a ]
When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe
finishes with success but uses invalid (ERR_PTR) values. This leads to
dereferencing of ERR_PTR stored under ourport->clk:
12c30000.serial: Controller clock not found
(...)
12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10
Unable to handle kernel paging request at virtual address
fffffdfb
(clk_prepare) from [<
c039f7d0>] (s3c24xx_serial_pm+0x20/0x128)
(s3c24xx_serial_pm) from [<
c0395414>] (uart_change_pm+0x38/0x40)
(uart_change_pm) from [<
c039689c>] (uart_add_one_port+0x31c/0x44c)
(uart_add_one_port) from [<
c03a035c>] (s3c24xx_serial_probe+0x2a8/0x418)
(s3c24xx_serial_probe) from [<
c03ee110>] (platform_drv_probe+0x50/0xb0)
(platform_drv_probe) from [<
c03ecb44>] (driver_probe_device+0x1f4/0x2b0)
(driver_probe_device) from [<
c03eb0c0>] (bus_for_each_drv+0x44/0x8c)
(bus_for_each_drv) from [<
c03ec8c8>] (__device_attach+0x9c/0x100)
(__device_attach) from [<
c03ebf54>] (bus_probe_device+0x84/0x8c)
(bus_probe_device) from [<
c03ec388>] (deferred_probe_work_func+0x60/0x8c)
(deferred_probe_work_func) from [<
c012fee4>] (process_one_work+0x120/0x328)
(process_one_work) from [<
c0130150>] (worker_thread+0x2c/0x4ac)
(worker_thread) from [<
c0135320>] (kthread+0xd8/0xf4)
(kthread) from [<
c0107978>] (ret_from_fork+0x14/0x3c)
The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to
exit with failure but the s3c24xx_uart_port is left half-configured
(e.g. port->mapbase is set, clk contains ERR_PTR). On next re-probe,
the function s3c24xx_serial_init_port() will exit early with success
because of configured port->mapbase and driver will use old values,
including the ERR_PTR as clock.
Fix this by cleaning the port->mapbase on error path so each re-probe
will initialize all of the port settings.
Fixes:
60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Alexandre Belloni [Fri, 27 May 2016 22:54:08 +0000 (00:54 +0200)]
tty/serial: atmel: fix RS485 half duplex with DMA
[ Upstream commit
0058f0871efe7b01c6f2b3046c68196ab73e96da ]
When using DMA, half duplex doesn't work properly because rx is not stopped
before starting tx. Ensure we call atmel_stop_rx() in the DMA case.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Cyrille Pitchen [Thu, 2 Jul 2015 13:18:11 +0000 (15:18 +0200)]
tty/serial: at91: remove bunch of macros to access UART registers
[ Upstream commit
4e7decdaaa67b287d6a13de8dedced68f1d7d716 ]
This patch replaces the UART_PUT_*, resp. UART_GET_*, macros by
atmel_uart_writel(), resp. atmel_uart_readl(), inline function calls.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Frank Rowand [Thu, 16 Jun 2016 17:51:46 +0000 (10:51 -0700)]
of: fix memory leak related to safe_name()
[ Upstream commit
d9fc880723321dbf16b2981e3f3e916b73942210 ]
Fix a memory leak resulting from memory allocation in safe_name().
This patch fixes all call sites of safe_name().
Mathieu Malaterre reported the memory leak on boot:
On my PowerMac device-tree would generate a duplicate name:
[ 0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1"
in this case a newly allocated name is generated by `safe_name`. However
in this case it is never deallocated.
The bug was found using kmemleak reported as:
unreferenced object 0xdf532e60 (size 32):
comm "swapper", pid 1, jiffies
4294892300 (age 1993.532s)
hex dump (first 32 bytes):
6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2 l2-cache#1......
ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e ................
backtrace:
[<
c02d3350>] kvasprintf+0x64/0xc8
[<
c02d3400>] kasprintf+0x4c/0x5c
[<
c0453814>] safe_name.isra.1+0x80/0xc4
[<
c04545d8>] __of_attach_node_sysfs+0x6c/0x11c
[<
c075f21c>] of_core_init+0x8c/0xf8
[<
c0729594>] kernel_init_freeable+0xd4/0x208
[<
c00047e8>] kernel_init+0x24/0x11c
[<
c00158ec>] ret_from_kernel_thread+0x5c/0x64
Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
Reported-by: mathieu.malaterre@gmail.com
Tested-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Herbert Xu [Wed, 15 Jun 2016 14:27:05 +0000 (22:27 +0800)]
crypto: gcm - Filter out async ghash if necessary
[ Upstream commit
b30bdfa86431afbafe15284a3ad5ac19b49b88e3 ]
As it is if you ask for a sync gcm you may actually end up with
an async one because it does not filter out async implementations
of ghash.
This patch fixes this by adding the necessary filter when looking
for ghash.
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Konrad Leszczynski [Mon, 8 Feb 2016 15:13:12 +0000 (16:13 +0100)]
usb: dwc3: fix for the isoc transfer EP_BUSY flag
[ Upstream commit
9cad39fe4e4a4fe95d8ea5a7b0692b0a6e89e38b ]
commit
f3af36511e60 ("usb: dwc3: gadget: always
enable IOC on bulk/interrupt transfers") ended up
regressing Isochronous endpoints by clearing
DWC3_EP_BUSY flag too early, which resulted in
choppy audio playback over USB.
Fix that by partially reverting original commit and
making sure that we check for isochronous endpoints.
Fixes:
f3af36511e60 ("usb: dwc3: gadget: always enable IOC
on bulk/interrupt transfers")
Cc: <stable@vger.kernel.org>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Dan O'Donovan [Fri, 10 Jun 2016 12:23:34 +0000 (13:23 +0100)]
pinctrl: cherryview: prevent concurrent access to GPIO controllers
[ Upstream commit
0bd50d719b004110e791800450ad204399100a86 ]
Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor
series, a common lock must be used to prevent concurrent accesses
across the 4 GPIO controllers managed by this driver.
See Intel Atom Z8000 Processor Series Specification Update
(Rev. 005), errata #CHT34, for further information.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dan O'Donovan <dan@emutex.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Mika Westerberg [Mon, 17 Aug 2015 13:13:30 +0000 (16:13 +0300)]
pinctrl: cherryview: Use raw_spinlock for locking
[ Upstream commit
109fdf1572be86aaf681e69b30dc5ada90ce6f35 ]
When running -rt kernel and an interrupt happens on a GPIO line controlled by
Intel Cherryview/Braswell pinctrl driver we get:
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
Preemption disabled at:[<
ffffffff81092e9f>] cpu_startup_entry+0x17f/0x480
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16
...
Call Trace:
<IRQ> [<
ffffffff816283c6>] dump_stack+0x4a/0x61
[<
ffffffff81077e17>] ___might_sleep+0xe7/0x170
[<
ffffffff8162d6cf>] rt_spin_lock+0x1f/0x50
[<
ffffffff812e52ed>] chv_gpio_irq_ack+0x3d/0xa0
[<
ffffffff810a72f5>] handle_edge_irq+0x75/0x180
[<
ffffffff810a3457>] generic_handle_irq+0x27/0x40
[<
ffffffff812e57de>] chv_gpio_irq_handler+0x7e/0x110
[<
ffffffff810050aa>] handle_irq+0xaa/0x190
...
This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack()
is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock
which in -rt is an rt-mutex causing might_sleep() rightfully to complain about
sleeping function called from invalid context.
In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Mika Westerberg [Mon, 3 Aug 2015 09:46:38 +0000 (12:46 +0300)]
pinctrl: cherryview: Serialize all register access
[ Upstream commit
4585b000ace6438d0b142746baab658056b223d9 ]
There is a hardware issue in Intel Braswell/Cherryview where concurrent
GPIO register access might results reads of 0xffffffff and writes might get
dropped.
Prevent this from happening by taking the serializing lock for all places
where it is possible that more than one thread might be accessing the
hardware concurrently.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Mauro Carvalho Chehab [Tue, 14 Jun 2016 17:48:50 +0000 (14:48 -0300)]
Update my main e-mails at the Kernel tree
[ Upstream commit
dc19ed1571dd3882b35e12fdaf50acbcc9b69714 ]
For the third time in three years, I'm changing my e-mail at
Samsung. That's bad, as it may stop communications with me for
a while. So, this time, I'll also the mchehab@kernel.org e-mail,
as it remains stable since ever.
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Vignesh R [Thu, 9 Jun 2016 05:32:04 +0000 (11:02 +0530)]
gpio: pca953x: Fix NBANK calculation for PCA9536
[ Upstream commit
a246b8198f776a16d1d3a3bbfc2d437bad766b29 ]
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Chris Blake [Mon, 30 May 2016 12:26:37 +0000 (07:26 -0500)]
PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset
[ Upstream commit
9ac0108c2bac3f1d0255f64fb89fc27e71131b24 ]
Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.
Fixes:
c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.14+
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Daniel Vetter [Thu, 9 Jun 2016 16:39:07 +0000 (18:39 +0200)]
Revert "drm/i915/ilk: Don't disable SSC source if it's in use"
[ Upstream commit
8c07eb68330f3ed9a735023a0f0e7f4e873e0c63 ]
This reverts commit
f165d2834ceb3d5c29bebadadc27629bebf402ac.
It breaks one of our CI systems. Quoting from Ville:
[ 13.100979] [drm:ironlake_init_pch_refclk] has_panel 1 has_lvds 1 has_ck505 0 using_ssc_source 1
[ 13.101413] ------------[ cut here ]------------
[ 13.101429] kernel BUG at drivers/gpu/drm/i915/intel_display.c:8528!
"which is the 'BUG_ON(val != final)' at the end of ironlake_init_pch_refclk()."
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude <cpaul@redhat.com>
Cc: marius.c.vlad@intel.com
References: https://www.spinics.net/lists/dri-devel/msg109557.html
Acked-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Paul Moore [Mon, 6 Jun 2016 19:17:20 +0000 (15:17 -0400)]
netlabel: add address family checks to netlbl_{sock,req}_delattr()
[ Upstream commit
0e0e36774081534783aa8eeb9f6fbddf98d3c061 ]
It seems risky to always rely on the caller to ensure the socket's
address family is correct before passing it to the NetLabel kAPI,
especially since we see at least one LSM which didn't. Add address
family checks to the *_delattr() functions to help prevent future
problems.
Cc: <stable@vger.kernel.org>
Reported-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Javier Martinez Canillas [Tue, 3 May 2016 20:27:17 +0000 (16:27 -0400)]
s5p-mfc: Add release callback for memory region devs
[ Upstream commit
6311f1261f59ce5e51fbe5cc3b5e7737197316ac ]
When s5p_mfc_remove() calls put_device() for the reserved memory region
devs, the driver core warns that the dev doesn't have a release callback:
WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
Also, the declared DMA memory using dma_declare_coherent_memory() isn't
relased so add a dev .release that calls dma_release_declared_memory().
Cc: <stable@vger.kernel.org>
Fixes:
6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Javier Martinez Canillas [Tue, 3 May 2016 20:27:16 +0000 (16:27 -0400)]
s5p-mfc: Set device name for reserved memory region devs
[ Upstream commit
29debab0a94035a390801d1f177d171d014b7765 ]
The devices don't have a name set, so makes dev_name() returns NULL which
makes harder to identify the devices that are causing issues, for example:
WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90
Device '(null)' does not have a release() function, it is broken and must be fixed.
And after setting the device name:
WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
Cc: <stable@vger.kernel.org>
Fixes:
6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Roderick Colenbrander [Wed, 18 May 2016 20:11:09 +0000 (13:11 -0700)]
HID: uhid: fix timeout when probe races with IO
[ Upstream commit
67f8ecc550b5bda03335f845dc869b8501d25fd0 ]
Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.
The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.
Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.
We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.
[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
James Morse [Fri, 12 Aug 2016 18:11:19 +0000 (14:11 -0400)]
arm64: kernel: Save and restore addr_limit on exception entry
commit
e19a6ee2460bdd0d0055a6029383422773f9999a upstream.
If we take an exception while at EL1, the exception handler inherits
the original context's addr_limit value. To be consistent always reset
addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental
re-use of the original context's addr_limit.
Based on a similar patch for arm from Russell King.
Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[ backport to stop perf misusing inherited addr_limit.
Removed code interacting with UAO and the irqstack ]
Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822
Signed-off-by: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org> #4.1
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Kenny Keslar [Fri, 12 Aug 2016 17:27:29 +0000 (13:27 -0400)]
fs/proc/task_mmu.c: fix mm_access() mode parameter in pagemap_read()
Backport of
caaee6234d05a58c5b4d05e7bf766131b810a657 ("ptrace: use fsuid,
fsgid, effective creds for fs access checks") to v4.1 failed to update the
mode parameter in the mm_access() call in pagemap_read() to have one of the
new PTRACE_MODE_*CREDS flags.
Attempting to read any other process' pagemap results in a WARN()
WARNING: CPU: 0 PID: 883 at kernel/ptrace.c:229 __ptrace_may_access+0x14a/0x160()
denying ptrace access check without PTRACE_MODE_*CREDS
Modules linked in: loop sg e1000 i2c_piix4 ppdev virtio_balloon virtio_pci parport_pc i2c_core virtio_ring ata_generic serio_raw pata_acpi virtio parport pcspkr floppy acpi_cpufreq ip_tables ext3 mbcache jbd sd_mod ata_piix crc32c_intel libata
CPU: 0 PID: 883 Comm: cat Tainted: G W 4.1.12-51.el7uek.x86_64 #2
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
0000000000000286 00000000619f225a ffff88003b6fbc18 ffffffff81717021
ffff88003b6fbc70 ffffffff819be870 ffff88003b6fbc58 ffffffff8108477a
000000003b6fbc58 0000000000000001 ffff88003d287000 0000000000000001
Call Trace:
[<
ffffffff81717021>] dump_stack+0x63/0x81
[<
ffffffff8108477a>] warn_slowpath_common+0x8a/0xc0
[<
ffffffff81084805>] warn_slowpath_fmt+0x55/0x70
[<
ffffffff8108e57a>] __ptrace_may_access+0x14a/0x160
[<
ffffffff8108f372>] ptrace_may_access+0x32/0x50
[<
ffffffff81081bad>] mm_access+0x6d/0xb0
[<
ffffffff81278c81>] pagemap_read+0xe1/0x360
[<
ffffffff811a046b>] ? lru_cache_add_active_or_unevictable+0x2b/0xa0
[<
ffffffff8120d2e7>] __vfs_read+0x37/0x100
[<
ffffffff812b9ab4>] ? security_file_permission+0x84/0xa0
[<
ffffffff8120d8b6>] ? rw_verify_area+0x56/0xe0
[<
ffffffff8120d9c6>] vfs_read+0x86/0x140
[<
ffffffff8120e945>] SyS_read+0x55/0xd0
[<
ffffffff8171eb6e>] system_call_fastpath+0x12/0x71
Fixes:
ab88ce5feca4 (ptrace: use fsuid, fsgid, effective creds for fs access checks)
Signed-off-by: Kenny Keslar <kenny.keslar@oracle.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Munehisa Kamata [Tue, 27 Oct 2015 02:10:52 +0000 (19:10 -0700)]
netfilter: nf_nat_redirect: add missing NULL pointer check
[ Upstream commit
94f9cd81436c85d8c3a318ba92e236ede73752fc ]
Commit
8b13eddfdf04cbfa561725cfc42d6868fe896f56 ("netfilter: refactor NAT
redirect IPv4 to use it from nf_tables") has introduced a trivial logic
change which can result in the following crash.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000030
IP: [<
ffffffffa033002d>] nf_nat_redirect_ipv4+0x2d/0xa0 [nf_nat_redirect]
PGD
3ba662067 PUD
3ba661067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: ipv6(E) xt_REDIRECT(E) nf_nat_redirect(E) xt_tcpudp(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables(E) x_tables(E) binfmt_misc(E) xfs(E) libcrc32c(E) evbug(E) evdev(E) psmouse(E) i2c_piix4(E) i2c_core(E) acpi_cpufreq(E) button(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
CPU: 0 PID: 2536 Comm: ip Tainted: G E 4.1.7-15.23.amzn1.x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
task:
ffff8800eb438000 ti:
ffff8803ba664000 task.ti:
ffff8803ba664000
[...]
Call Trace:
<IRQ>
[<
ffffffffa0334065>] redirect_tg4+0x15/0x20 [xt_REDIRECT]
[<
ffffffffa02e2e99>] ipt_do_table+0x2b9/0x5e1 [ip_tables]
[<
ffffffffa0328045>] iptable_nat_do_chain+0x25/0x30 [iptable_nat]
[<
ffffffffa031777d>] nf_nat_ipv4_fn+0x13d/0x1f0 [nf_nat_ipv4]
[<
ffffffffa0328020>] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat]
[<
ffffffffa031785e>] nf_nat_ipv4_in+0x2e/0x90 [nf_nat_ipv4]
[<
ffffffffa03280a5>] iptable_nat_ipv4_in+0x15/0x20 [iptable_nat]
[<
ffffffff81449137>] nf_iterate+0x57/0x80
[<
ffffffff814491f7>] nf_hook_slow+0x97/0x100
[<
ffffffff814504d4>] ip_rcv+0x314/0x400
unsigned int
nf_nat_redirect_ipv4(struct sk_buff *skb,
...
{
...
rcu_read_lock();
indev = __in_dev_get_rcu(skb->dev);
if (indev != NULL) {
ifa = indev->ifa_list;
newdst = ifa->ifa_local; <---
}
rcu_read_unlock();
...
}
Before the commit, 'ifa' had been always checked before access. After the
commit, however, it could be accessed even if it's NULL. Interestingly,
this was once fixed in 2003.
http://marc.info/?l=netfilter-devel&m=
106668497403047&w=2
In addition to the original one, we have seen the crash when packets that
need to be redirected somehow arrive on an interface which hasn't been
yet fully configured.
This change just reverts the logic to the old behavior to avoid the crash.
Fixes:
8b13eddfdf04 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables")
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Tue, 9 Aug 2016 02:11:45 +0000 (22:11 -0400)]
Linux 4.1.30
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Reintroduce scanning of secondary buses
[ Upstream commit
850c321027c2e31d0afc71588974719a4b565550 ]
We used to scan secondary buses until the following commit that
was applied in 2009:
8659c406ade3 ("x86: only scan the root bus in early PCI quirks")
which commit constrained early quirks to the root bus only. Its
motivation was to prevent application of the nvidia_bugs quirk
on secondary buses.
We're about to add a quirk to reset the Broadcom 4331 wireless card on
2011/2012 Macs, which is located on a secondary bus behind a PCIe root
port. To facilitate that, reintroduce scanning of secondary buses.
The commit message of
8659c406ade3 notes that scanning only the root bus
"saves quite some unnecessary scanning work". The algorithm used prior
to
8659c406ade3 was particularly time consuming because it scanned
buses 0 to 31 brute force. To avoid lengthening boot time, employ a
recursive strategy which only scans buses that are actually reachable
from the root bus.
Yinghai Lu pointed out that the secondary bus number read from a
bridge's config space may be invalid, in particular a value of 0 would
cause an infinite loop. The PCI core goes beyond that and recurses to a
child bus only if its bus number is greater than the parent bus number
(see pci_scan_bridge()). Since the root bus is numbered 0, this implies
that secondary buses may not be 0. Do the same on early scanning.
If this algorithm is found to significantly impact boot time or cause
infinite loops on broken hardware, it would be possible to limit its
recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
at depth 0, so the bus need not be scanned deeper than that for now. An
alternative approach would be to revert to scanning only the root bus,
and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
and 8086:1e16. Apple always positioned the card behind either of these
three ports. The quirk would then check presence of the card in slot 0
below the root port and do its deed.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-pci@vger.kernel.org
Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Apply nvidia_bugs quirk only on root bus
[ Upstream commit
447d29d1d3aed839e74c2401ef63387780ac51ed ]
Since the following commit:
8659c406ade3 ("x86: only scan the root bus in early PCI quirks")
... early quirks are only applied to devices on the root bus.
The motivation was to prevent application of the nvidia_bugs quirk on
secondary buses.
We're about to reintroduce scanning of secondary buses for a quirk to
reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
regressions, open code the requirement to apply nvidia_bugs only on the
root bus.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Mon, 8 Aug 2016 01:35:12 +0000 (21:35 -0400)]
Revert "MIPS: Reserve nosave data for hibernation"
This reverts commit
e8ebd0cf882ba73a5c867bb7228dba1ae746c047.
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Mon, 8 Aug 2016 01:34:49 +0000 (21:34 -0400)]
Revert "sparc64: Fix numa node distance initialization"
This reverts commit
bfbe327d556707c59c5c0536d831078b41a68429.
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jiri Slaby [Wed, 20 Jul 2016 22:45:08 +0000 (15:45 -0700)]
pps: do not crash when failed to register
[ Upstream commit
368301f2fe4b07e5fb71dba3cc566bc59eb6705f ]
With this command sequence:
modprobe plip
modprobe pps_parport
rmmod pps_parport
the partport_pps modules causes this crash:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: parport_detach+0x1d/0x60 [pps_parport]
Oops: 0000 [#1] SMP
...
Call Trace:
parport_unregister_driver+0x65/0xc0 [parport]
SyS_delete_module+0x187/0x210
The sequence that builds up to this is:
1) plip is loaded and takes the parport device for exclusive use:
plip0: Parallel port at 0x378, using IRQ 7.
2) pps_parport then fails to grab the device:
pps_parport: parallel port PPS client
parport0: cannot grant exclusive access for device pps_parport
pps_parport: couldn't register with parport0
3) rmmod of pps_parport is then killed because it tries to access
pardev->name, but pardev (taken from port->cad) is NULL.
So add a check for NULL in the test there too.
Link: http://lkml.kernel.org/r/20160714115245.12651-1-jslaby@suse.cz
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Andrey Ryabinin [Wed, 20 Jul 2016 22:45:00 +0000 (15:45 -0700)]
radix-tree: fix radix_tree_iter_retry() for tagged iterators.
[ Upstream commit
3cb9185c67304b2a7ea9be73e7d13df6fb2793a1 ]
radix_tree_iter_retry() resets slot to NULL, but it doesn't reset tags.
Then NULL slot and non-zero iter.tags passed to radix_tree_next_slot()
leading to crash:
RIP: radix_tree_next_slot include/linux/radix-tree.h:473
find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
....
Call Trace:
pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
mpage_prepare_extent_to_map+0x321/0xa90 fs/ext4/inode.c:2516
ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
do_writepages+0x97/0x100 mm/page-writeback.c:2364
__filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
vfs_fsync_range+0x10a/0x250 fs/sync.c:195
vfs_fsync fs/sync.c:209
do_fsync+0x42/0x70 fs/sync.c:219
SYSC_fdatasync fs/sync.c:232
SyS_fdatasync+0x19/0x20 fs/sync.c:230
entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207
We must reset iterator's tags to bail out from radix_tree_next_slot()
and go to the slow-path in radix_tree_next_chunk().
Fixes:
46437f9a554f ("radix-tree: fix race in gang lookup")
Link: http://lkml.kernel.org/r/1468495196-10604-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Ilya Dryomov [Tue, 19 Jul 2016 01:50:28 +0000 (03:50 +0200)]
libceph: apply new_state before new_up_client on incrementals
[ Upstream commit
930c532869774ebf8af9efe9484c597f896a7d46 ]
Currently, osd_weight and osd_state fields are updated in the encoding
order. This is wrong, because an incremental map may look like e.g.
new_up_client: { osd=6, addr=... } # set osd_state and addr
new_state: { osd=6, xorstate=EXISTS } # clear osd_state
Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down). After
applying new_up_client, osd_state is changed to EXISTS | UP. Carrying
on with the new_state update, we flip EXISTS and leave osd6 in a weird
"!EXISTS but UP" state. A non-existent OSD is considered down by the
mapping code
2087 for (i = 0; i < pg->pg_temp.len; i++) {
2088 if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) {
2089 if (ceph_can_shift_osds(pi))
2090 continue;
2091
2092 temp->osds[temp->size++] = CRUSH_ITEM_NONE;
and so requests get directed to the second OSD in the set instead of
the first, resulting in OSD-side errors like:
[WRN] : client.4239 192.168.122.21:0/
2444980242 misdirected client.4239.1:2827 pg 2.
5df899f2 to osd.4 not [1,4,6] in e680/680
and hung rbds on the client:
[ 493.566367] rbd: rbd0: write 400000 at
11cc00000 (0)
[ 493.566805] rbd: rbd0: result -6 xferred 400000
[ 493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688
The fix is to decouple application from the decoding and:
- apply new_weight first
- apply new_state before new_up_client
- twiddle osd_state flags if marking in
- clear out some of the state if osd is destroyed
Fixes: http://tracker.ceph.com/issues/14901
Cc: stable@vger.kernel.org # 3.15+: 6dd74e44dc1d: libceph: set 'exists' flag for newly up osd
Cc: stable@vger.kernel.org # 3.15+
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Yan, Zheng [Fri, 28 Aug 2015 09:59:35 +0000 (17:59 +0800)]
libceph: set 'exists' flag for newly up osd
[ Upstream commit
6dd74e44dc1df85f125982a8d6591bc4a76c9f5d ]
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Maxim Patlasov [Fri, 22 Jul 2016 01:24:26 +0000 (18:24 -0700)]
ovl: verify upper dentry in ovl_remove_and_whiteout()
[ Upstream commit
cfc9fde0b07c3b44b570057c5f93dda59dca1c94 ]
The upper dentry may become stale before we call ovl_lock_rename_workdir.
For example, someone could (mistakenly or maliciously) manually unlink(2)
it directly from upperdir.
To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir
and and check if it matches the upper dentry.
Essentially, it is the same problem and similar solution as in
commit
11f3710417d0 ("ovl: verify upper dentry before unlink and rename").
Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Dmitry Torokhov [Mon, 27 Jun 2016 21:12:34 +0000 (14:12 -0700)]
tty/vt/keyboard: fix OOB access in do_compute_shiftstate()
[ Upstream commit
510cccb5b0c8868a2b302a0ab524da7912da648b ]
The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
which is currently 256, whereas number of keys/buttons in input device (and
therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
out-of-bound access when we do
sym = U(key_maps[0][k]);
with large 'k'.
To fix it we should not attempt iterating beyond smaller of NR_KEYS and
KEY_CNT.
Also while at it let's switch to for_each_set_bit() instead of open-coding
it.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Tejun Heo [Mon, 18 Jul 2016 22:40:00 +0000 (18:40 -0400)]
libata: LITE-ON CX1-JB256-HP needs lower max_sectors
[ Upstream commit
1488a1e3828d60d74c9b802a05e24c0487babe4e ]
Since
34b48db66e08 ("block: remove artifical max_hw_sectors cap"),
max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON
CX1-JB256-HP keeps timing out with higher max_sectors. Revert it to
the previous value.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: dgerasimov@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671
Cc: stable@vger.kernel.org # v3.19+
Fixes:
34b48db66e08 ("block: remove artifical max_hw_sectors cap")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Taras Kondratiuk [Wed, 13 Jul 2016 22:05:38 +0000 (22:05 +0000)]
mmc: block: fix packed command header endianness
[ Upstream commit
f68381a70bb2b26c31b13fdaf67c778f92fd32b4 ]
The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:
[ 563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[ 563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1
Convert header data to LE.
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Fixes:
ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
James Patrick-Evans [Fri, 15 Jul 2016 15:40:45 +0000 (16:40 +0100)]
media: fix airspy usb probe error path
[ Upstream commit
aa93d1fee85c890a34f2510a310e55ee76a27848 ]
Fix a memory leak on probe error of the airspy usb device driver.
The problem is triggered when more than 64 usb devices register with
v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.
The memory leak is caused by the probe function of the airspy driver
mishandeling errors and not freeing the corresponding control structures
when an error occours registering the device to v4l2 core.
A badusb device can emulate 64 of these devices, and then through
continual emulated connect/disconnect of the 65th device, cause the
kernel to run out of RAM and crash the kernel, thus causing a local DOS
vulnerability.
Fixes CVE-2016-5400
Signed-off-by: James Patrick-Evans <james@jmp-e.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Dmitry Vyukov [Thu, 14 Jul 2016 19:07:29 +0000 (12:07 -0700)]
vmlinux.lds: account for destructor sections
[ Upstream commit
e41f501d391265ff568f3e49d6128cc30856a36f ]
If CONFIG_KASAN is enabled and gcc is configured with
--disable-initfini-array and/or gold linker is used, gcc emits
.ctors/.dtors and .text.startup/.text.exit sections instead of
.init_array/.fini_array. .dtors section is not explicitly accounted in
the linker script and messes vvar/percpu layout.
We want:
ffffffff822bfd80 D _edata
ffffffff822c0000 D __vvar_beginning_hack
ffffffff822c0000 A __vvar_page
ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
ffffffff822c1000 A __init_begin
ffffffff822c1000 D init_per_cpu__irq_stack_union
ffffffff822c1000 A __per_cpu_load
ffffffff822d3000 D init_per_cpu__gdt_page
We got:
ffffffff8279a600 D _edata
ffffffff8279b000 A __vvar_page
ffffffff8279c000 A __init_begin
ffffffff8279c000 D init_per_cpu__irq_stack_union
ffffffff8279c000 A __per_cpu_load
ffffffff8279e000 D __vvar_beginning_hack
ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
ffffffff827ae000 D init_per_cpu__gdt_page
This happens because __vvar_page and .vvar get different addresses in
arch/x86/kernel/vmlinux.lds.S:
. = ALIGN(PAGE_SIZE);
__vvar_page = .;
.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
/* work around gold bug 13023 */
__vvar_beginning_hack = .;
Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
Merge .text.startup into init text.
Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@google.com
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org> [4.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
David Rientjes [Thu, 14 Jul 2016 19:06:50 +0000 (12:06 -0700)]
mm, compaction: prevent VM_BUG_ON when terminating freeing scanner
[ Upstream commit
a46cbf3bc53b6a93fb84a5ffb288c354fa807954 ]
It's possible to isolate some freepages in a pageblock and then fail
split_free_page() due to the low watermark check. In this case, we hit
VM_BUG_ON() because the freeing scanner terminated early without a
contended lock or enough freepages.
This should never have been a VM_BUG_ON() since it's not a fatal
condition. It should have been a VM_WARN_ON() at best, or even handled
gracefully.
Regardless, we need to terminate anytime the full pageblock scan was not
done. The logic belongs in isolate_freepages_block(), so handle its
state gracefully by terminating the pageblock loop and making a note to
restart at the same pageblock next time since it was not possible to
complete the scan this time.
[rientjes@google.com: don't rescan pages in a pageblock]
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1607111244150.83138@chino.kir.corp.google.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1606291436300.145590@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Minchan Kim <minchan@kernel.org>
Tested-by: Minchan Kim <minchan@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Vlastimil Babka [Tue, 8 Sep 2015 22:02:39 +0000 (15:02 -0700)]
mm, compaction: simplify handling restart position in free pages scanner
[ Upstream commit
f5f61a320bf6275f37fcabf6645b4ac8e683c007 ]
Handling the position where compaction free scanner should restart
(stored in cc->free_pfn) got more complex with commit
e14c720efdd7 ("mm,
compaction: remember position within pageblock in free pages scanner").
Currently the position is updated in each loop iteration of
isolate_freepages(), although it should be enough to update it only when
breaking from the loop. There's also an extra check outside the loop
updates the position in case we have met the migration scanner.
This can be simplified if we move the test for having isolated enough
from the for-loop header next to the test for contention, and
determining the restart position only in these cases. We can reuse the
isolate_start_pfn variable for this instead of setting cc->free_pfn
directly. Outside the loop, we can simply set cc->free_pfn to current
value of isolate_start_pfn without any extra check.
Also add a VM_BUG_ON to catch possible mistake in the future, in case we
later add a new condition that terminates isolate_freepages_block()
prematurely without also considering the condition in
isolate_freepages().
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Minchan Kim <minchan@kernel.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Chris Wilson [Mon, 11 Jul 2016 13:46:17 +0000 (14:46 +0100)]
drm/i915: Update ifdeffery for mutex->owner
[ Upstream commit
b19240062722c39fa92c99f04cbfd93034625123 ]
In commit
7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when
appropriate") the owner field in the mutex was updated from being
dependent upon CONFIG_SMP to using optimistic spin. Update our peek
function to suite.
Fixes:
7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...")
Reported-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1468244777-4888-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
(cherry picked from commit
4f074a5393431a7d2cc0de7fcfe2f61d24854628)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Awais Belal [Tue, 12 Jul 2016 10:21:28 +0000 (15:21 +0500)]
ALSA: hda: add AMD Stoney PCI ID with proper driver caps
[ Upstream commit
d716fb03f76411fc7e138692e33b749cada5c094 ]
This allows the device to correctly show up as ATI HDMI
rather than a generic one and allows the driver to use
the available caps.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Sat, 6 Aug 2016 16:55:50 +0000 (12:55 -0400)]
ALSA: hda - fix use-after-free after module unload
[ Upstream commit
ab58d8cc870ef3f0771c197700441936898d1f1d ]
register_vga_switcheroo() sets the PM ops from the hda structure which
is freed later in azx_free. Make sure that these ops are cleared.
Caught by KASAN, initially noticed due to a general protection fault.
Fixes:
246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)")
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Alexey Dobriyan [Thu, 7 Jul 2016 22:39:11 +0000 (01:39 +0300)]
posix_cpu_timer: Exit early when process has been reaped
[ Upstream commit
2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 ]
Variable "now" seems to be genuinely used unintialized
if branch
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
is not taken and branch
if (unlikely(sighand == NULL)) {
is taken. In this case the process has been reaped and the timer is marked as
disarmed anyway. So none of the postprocessing of the sample is
required. Return right away.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20160707223911.GA26483@p183.telecom.by
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Lukas Wunner [Sun, 12 Jun 2016 10:31:53 +0000 (12:31 +0200)]
x86/quirks: Add early quirk to reset Apple AirPort card
[ Upstream commit
abb2bafd295fe962bbadc329dbfb2146457283ac ]
The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.
The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.
The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.
When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=
9d34bb85da56
This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.
Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.
Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback
towards finding the best solution to this problem.
The following should be a comprehensive list of affected models:
iMac13,1 2012 21.5" [Root Port 00:1c.3 = 8086:1e16]
iMac13,2 2012 27" [Root Port 00:1c.3 = 8086:1e16]
Macmini5,1 2011 i5 2.3 GHz [Root Port 00:1c.1 = 8086:1c12]
Macmini5,2 2011 i5 2.5 GHz [Root Port 00:1c.1 = 8086:1c12]
Macmini5,3 2011 i7 2.0 GHz [Root Port 00:1c.1 = 8086:1c12]
Macmini6,1 2012 i5 2.5 GHz [Root Port 00:1c.1 = 8086:1e12]
Macmini6,2 2012 i7 2.3 GHz [Root Port 00:1c.1 = 8086:1e12]
MacBookPro8,1 2011 13" [Root Port 00:1c.1 = 8086:1c12]
MacBookPro8,2 2011 15" [Root Port 00:1c.1 = 8086:1c12]
MacBookPro8,3 2011 17" [Root Port 00:1c.1 = 8086:1c12]
MacBookPro9,1 2012 15" [Root Port 00:1c.1 = 8086:1e12]
MacBookPro9,2 2012 13" [Root Port 00:1c.1 = 8086:1e12]
MacBookPro10,1 2012 15" [Root Port 00:1c.1 = 8086:1e12]
MacBookPro10,2 2012 13" [Root Port 00:1c.1 = 8086:1e12]
For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):
irq 17: nobody cared (try booting with the "irqpoll" option)
handlers:
[<
ffffffff81374370>] pcie_isr
[<
ffffffffc0704550>] sdhci_irq [sdhci] threaded [<
ffffffffc07013c0>] sdhci_thread_irq [sdhci]
[<
ffffffffc0a0b960>] azx_interrupt [snd_hda_codec]
Disabling IRQ #17
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
Tested-by: Konstantin Simanov <k.simanov@stlk.ru> # [MacBookPro8,1]
Tested-by: Lukas Wunner <lukas@wunner.de> # [MacBookPro9,1]
Tested-by: Bryan Paradis <bryan.paradis@gmail.com> # [MacBookPro9,2]
Tested-by: Andrew Worsley <amworsley@gmail.com> # [MacBookPro10,1]
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> # [MacBookPro10,2]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chris Milsted <cmilsted@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Michael Buesch <m@bues.ch>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: b43-dev@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
[ Did minor readability edits. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Dmitri Epshtein [Wed, 6 Jul 2016 02:18:58 +0000 (04:18 +0200)]
net: mvneta: set real interrupt per packet for tx_done
[ Upstream commit
06708f81528725148473c0869d6af5f809c6824b ]
Commit
aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.
In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.
This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v3.10+
Fixes
aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Takashi Iwai [Fri, 8 Jul 2016 06:23:43 +0000 (08:23 +0200)]
ALSA: pcm: Free chmap at PCM free callback, too
[ Upstream commit
a8ff48cb70835f48de5703052760312019afea55 ]
The chmap ctls assigned to PCM streams are freed in the PCM disconnect
callback. However, since the disconnect callback isn't called when
the card gets freed before registering, the chmap ctls may still be
left assigned. They are eventually freed together with other ctls,
but it may cause an Oops at pcm_chmap_ctl_private_free(), as the
function refers to the assigned PCM stream, while the PCM objects have
been already freed beforehand.
The fix is to free the chmap ctls also at PCM free callback, not only
at PCM disconnect.
Reported-by: Laxminath Kasam <b_lkasam@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Takashi Iwai [Fri, 8 Jul 2016 06:05:19 +0000 (08:05 +0200)]
ALSA: ctl: Stop notification after disconnection
[ Upstream commit
f388cdcdd160687c6650833f286b9c89c50960ff ]
snd_ctl_remove() has a notification for the removal event. It's
superfluous when done during the device got disconnected. Although
the notification itself is mostly harmless, it may potentially be
harmful, and should be suppressed. Actually some components PCM may
free ctl elements during the disconnect or free callbacks, thus it's
no theoretical issue.
This patch adds the check of card->shutdown flag for avoiding
unnecessary notifications after (or during) the disconnect.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Hui Wang [Fri, 8 Jul 2016 06:26:57 +0000 (14:26 +0800)]
ALSA: hda/realtek - add new pin definition in alc225 pin quirk table
[ Upstream commit
8a132099f080d7384bb6ab4cc168f76cb4b47d08 ]
We have some Dell laptops which can't detect headset mic, the machines
use the codec ALC225, they have some new pin configuration values,
after adding them in the alc225 pin quirk table, they work well.
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Vivek Goyal [Fri, 1 Jul 2016 20:34:25 +0000 (16:34 -0400)]
ovl: Copy up underlying inode's ->i_mode to overlay inode
[ Upstream commit
07a2daab49c549a37b5b744cbebb6e3f445f12bc ]
Right now when a new overlay inode is created, we initialize overlay
inode's ->i_mode from underlying inode ->i_mode but we retain only
file type bits (S_IFMT) and discard permission bits.
This patch changes it and retains permission bits too. This should allow
overlay to do permission checks on overlay inode itself in task context.
[SzM] It also fixes clearing suid/sgid bits on write.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes:
4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Miklos Szeredi [Mon, 4 Jul 2016 14:49:48 +0000 (16:49 +0200)]
ovl: handle ATTR_KILL*
[ Upstream commit
51234eac5dd8b5feda9a3a8fa766f5398ecf91e3 ]
commit
b99c2d913810e56682a538c9f2394d76fca808f8 upstream.
Before
4bacc9c9234c ("overlayfs: Make f_path...") file->f_path pointed to
the underlying file, hence suid/sgid removal on write worked fine.
After that patch file->f_path pointed to the overlay file, and the file
mode bits weren't copied to overlay_inode->i_mode. So the suid/sgid
removal simply stopped working.
The fix is to copy the mode bits, but then ovl_setattr() needs to clear
ATTR_MODE to avoid the BUG() in notify_change(). So do this first, then in
the next patch copy the mode.
Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes:
4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sinclair Yeh [Wed, 29 Jun 2016 19:58:49 +0000 (12:58 -0700)]
drm/ttm: Make ttm_bo_mem_compat available
[ Upstream commit
94477bff390aa4612d2332c8abafaae0a13d6923 ]
There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>
---
This is the first of a 3-patch series to fix a black screen
issue observed on Ubuntu 16.04 server.
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Cameron Gutman [Wed, 29 Jun 2016 16:51:35 +0000 (09:51 -0700)]
Input: xpad - validate USB endpoint count during probe
[ Upstream commit
caca925fca4fb30c67be88cacbe908eec6721e43 ]
This prevents a malicious USB device from causing an oops.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Thomas Petazzoni [Thu, 16 Jun 2016 13:42:25 +0000 (15:42 +0200)]
ARM: mvebu: fix HW I/O coherency related deadlocks
[ Upstream commit
c5379ba8fccd99d5f99632c789f0393d84a57805 ]
Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.
This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).
Tested-by: Terry Stockert <stockert@inkblotadmirer.me>
Tested-by: Romain Perier <romain.perier@free-electrons.com>
Cc: Terry Stockert <stockert@inkblotadmirer.me>
Cc: Romain Perier <romain.perier@free-electrons.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Florian Westphal [Wed, 3 Aug 2016 15:31:54 +0000 (11:31 -0400)]
netfilter: x_tables: speed up jump target validation
[ Upstream commit
f4dc77713f8016d2e8a3295e1c9c53a21f296def ]
The dummy ruleset I used to test the original validation change was broken,
most rules were unreachable and were not tested by mark_source_chains().
In some cases rulesets that used to load in a few seconds now require
several minutes.
sample ruleset that shows the behaviour:
echo "*filter"
for i in $(seq 0 100000);do
printf ":chain_%06x - [0:0]\n" $i
done
for i in $(seq 0 100000);do
printf -- "-A INPUT -j chain_%06x\n" $i
printf -- "-A INPUT -j chain_%06x\n" $i
printf -- "-A INPUT -j chain_%06x\n" $i
done
echo COMMIT
[ pipe result into iptables-restore ]
This ruleset will be about 74mbyte in size, with ~500k searches
though all 500k[1] rule entries. iptables-restore will take forever
(gave up after 10 minutes)
Instead of always searching the entire blob for a match, fill an
array with the start offsets of every single ipt_entry struct,
then do a binary search to check if the jump target is present or not.
After this change ruleset restore times get again close to what one
gets when reverting
36472341017529e (~3 seconds on my workstation).
[1] every user-defined rule gets an implicit RETURN, so we get
300k jumps + 100k userchains + 100k returns -> 500k rule entries
Fixes:
36472341017529e ("netfilter: x_tables: validate targets of jumps")
Reported-by: Jeff Wu <wujiafu@gmail.com>
Tested-by: Jeff Wu <wujiafu@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Sat, 30 Jul 2016 01:39:34 +0000 (21:39 -0400)]
Linux 4.1.29
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Steven Rostedt [Thu, 14 Jul 2016 21:55:21 +0000 (17:55 -0400)]
4.1.28 Fix bad backport of
8f182270dfec "mm/swap.c: flush lru pvecs on compound page arrival"
When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests,
it crashed with a severe OOM killing everything. I then tested 4.1.28
without -rt and it had the same issue. I did a bisect between 4.1.27
and 4.1.28 and found that the bug started at:
commit
8f182270dfec "mm/swap.c: flush lru pvecs on compound page
arrival"
Looking at that patch and what's in mainline, I see that there's a
mismatch in one of the hunks:
Mainline:
@@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
get_page(page);
- if (!pagevec_space(pvec))
+ if (!pagevec_add(pvec, page) || PageCompound(page))
__pagevec_lru_add(pvec);
- pagevec_add(pvec, page);
put_cpu_var(lru_add_pvec);
}
Stable 4.1.28:
@@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page)
struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
page_cache_get(page);
- if (!pagevec_space(pvec))
+ if (!pagevec_space(pvec) || PageCompound(page))
__pagevec_lru_add(pvec);
- pagevec_add(pvec, page);
put_cpu_var(lru_add_pvec);
}
Where mainline replace pagevec_space() with pagevec_add, and stable did
not.
Fixing this makes the OOM go away.
Note, 3.18 has the same bug.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Michael Ellerman [Thu, 14 Jul 2016 11:10:37 +0000 (21:10 +1000)]
powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC
The backport of
4705e02498d6 ("powerpc: Update TM user feature bits in
scan_features()") (
f49eb503f0f9), missed the fact that 4.1 doesn't
include the commit that added PPC_FEATURE2_HTM_NOSC.
The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC.
Fixes:
f49eb503f0f9 ("powerpc: Update TM user feature bits in scan_features()")
Reported-by: Christian Zigotzky <chzigotzky@bayern-mail.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jeff Mahoney [Tue, 5 Jul 2016 21:32:30 +0000 (17:32 -0400)]
ecryptfs: don't allow mmap when the lower fs doesn't support it
[ Upstream commit
f0fe970df3838c202ef6c07a4c2b36838ef0a88b ]
There are legitimate reasons to disallow mmap on certain files, notably
in sysfs or procfs. We shouldn't emulate mmap support on file systems
that don't offer support natively.
CVE-2016-1583
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Cc: stable@vger.kernel.org
[tyhicks: clean up f_op check by using ecryptfs_file_to_lower()]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jan Beulich [Fri, 8 Jul 2016 12:15:07 +0000 (06:15 -0600)]
xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7
[ Upstream commit
6f2d9d99213514360034c6d52d2c3919290b3504 ]
As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.
Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jan Beulich [Thu, 7 Jul 2016 07:32:04 +0000 (01:32 -0600)]
xenbus: don't bail early from xenbus_dev_request_and_reply()
[ Upstream commit
7469be95a487319514adce2304ad2af3553d2fc9 ]
xenbus_dev_request_and_reply() needs to track whether a transaction is
open. For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().
If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.
If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.
Commit
027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open. This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.
It appears that the problematic change was added accidentally, so just
remove it.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jeff Mahoney [Tue, 5 Jul 2016 21:32:29 +0000 (17:32 -0400)]
Revert "ecryptfs: forbid opening files without mmap handler"
[ Upstream commit
78c4e172412de5d0456dc00d2b34050aa0b683b5 ]
This reverts commit
2f36db71009304b3f0b95afacd8eba1f9f046b87.
It fixed a local root exploit but also introduced a dependency on
the lower file system implementing an mmap operation just to open a file,
which is a bit of a heavy hammer. The right fix is to have mmap depend
on the existence of the mmap handler instead.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Jan Beulich [Thu, 7 Jul 2016 07:23:57 +0000 (01:23 -0600)]
xenbus: don't BUG() on user mode induced condition
[ Upstream commit
0beef634b86a1350c31da5fcc2992f0d7c8a622b ]
Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
David Daney [Thu, 16 Jun 2016 22:50:31 +0000 (15:50 -0700)]
MIPS: Fix page table corruption on THP permission changes.
[ Upstream commit
88d02a2ba6c52350f9a73ff1b01a5be839c3ca17 ]
When the core THP code is modifying the permissions of a huge page it
calls pmd_modify(), which unfortunately was clearing the _PAGE_HUGE bit
of the page table entry. The result can be kernel messages like:
mm/memory.c:397: bad pmd
000000040080004d.
mm/memory.c:397: bad pmd
00000003ff00004d.
mm/memory.c:397: bad pmd
000000040100004d.
or:
------------[ cut here ]------------
WARNING: at mm/mmap.c:3200 exit_mmap+0x150/0x158()
Modules linked in: ipv6 at24 octeon3_ethernet octeon_srio_nexus m25p80
CPU: 12 PID: 1295 Comm: pmderr Not tainted 3.10.87-rt80-Cavium-Octeon #4
Stack :
0000000040808000 0000000014009ce1 0000000000400004 ffffffff81076ba0
0000000000000000 0000000000000000 ffffffff85110000 0000000000000119
0000000000000004 0000000000000000 0000000000000119 43617669756d2d4f
0000000000000000 ffffffff850fda40 ffffffff85110000 0000000000000000
0000000000000000 0000000000000009 ffffffff809207a0 0000000000000c80
ffffffff80f1bf20 0000000000000001 000000ffeca36828 0000000000000001
0000000000000000 0000000000000001 000000ffeca7e700 ffffffff80886924
80000003fd7a0000 80000003fd7a39b0 80000003fdea8000 ffffffff80885780
80000003fdea8000 ffffffff80f12218 000000000000000c 000000000000050f
0000000000000000 ffffffff80865c4c 0000000000000000 0000000000000000
...
Call Trace:
[<
ffffffff80865c4c>] show_stack+0x6c/0xf8
[<
ffffffff80885780>] warn_slowpath_common+0x78/0xa8
[<
ffffffff809207a0>] exit_mmap+0x150/0x158
[<
ffffffff80882d44>] mmput+0x5c/0x110
[<
ffffffff8088b450>] do_exit+0x230/0xa68
[<
ffffffff8088be34>] do_group_exit+0x54/0x1d0
[<
ffffffff8088bfc0>] __wake_up_parent+0x0/0x18
---[ end trace
c7b38293191c57dc ]---
BUG: Bad rss-counter state mm:
80000003fa168000 idx:1 val:1536
Fix by not clearing _PAGE_HUGE bit.
Signed-off-by: David Daney <david.daney@cavium.com>
Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13687/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Torsten Hilbrich [Tue, 5 Jul 2016 08:40:22 +0000 (10:40 +0200)]
ALSA: hda/realtek: Add Lenovo L460 to docking unit fixup
[ Upstream commit
9cd25743765cfe851aed8d655a62d60156aed293 ]
This solves the issue that a headphone is not working on the docking
unit.
Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Ursula Braun [Mon, 4 Jul 2016 12:07:16 +0000 (14:07 +0200)]
qeth: delete napi struct when removing a qeth device
[ Upstream commit
7831b4ff0d926e0deeaabef9db8800ed069a2757 ]
A qeth_card contains a napi_struct linked to the net_device during
device probing. This struct must be deleted when removing the qeth
device, otherwise Panic on oops can occur when qeth devices are
repeatedly removed and added.
Fixes:
a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
Cc: stable@vger.kernel.org # v2.6.37+
Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Tested-by: Alexander Klein <ALKL@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Colin Pitrat [Sat, 18 Jun 2016 18:05:04 +0000 (19:05 +0100)]
gpio: sch: Fix Oops on module load on Asus Eee PC 1201
[ Upstream commit
87041a58d3b19455d39baed2a5e5bb43b58fb915 ]
This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.
The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.
The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.
Thanks Mika for your patience with me :-)
Cc: stable@vger.kernel.org
Signed-off-by: Colin Pitrat <colin.pitrat@gmail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Takashi Iwai [Mon, 4 Jul 2016 12:02:15 +0000 (14:02 +0200)]
ALSA: timer: Fix negative queue usage by racy accesses
[ Upstream commit
3fa6993fef634e05d200d141a85df0b044572364 ]
The user timer tu->qused counter may go to a negative value when
multiple concurrent reads are performed since both the check and the
decrement of tu->qused are done in two individual locked contexts.
This results in bogus read outs, and the endless loop in the
user-space side.
The fix is to move the decrement of the tu->qused counter into the
same spinlock context as the zero-check of the counter.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Omar Sandoval [Fri, 1 Jul 2016 07:39:35 +0000 (00:39 -0700)]
block: fix use-after-free in sys_ioprio_get()
[ Upstream commit
8ba8682107ee2ca3347354e018865d8e1967c5f4 ]
get_task_ioprio() accesses the task->io_context without holding the task
lock and thus can race with exit_io_context(), leading to a
use-after-free. The reproducer below hits this within a few seconds on
my 4-core QEMU VM:
#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/wait.h>
int main(int argc, char **argv)
{
pid_t pid, child;
long nproc, i;
/* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */
syscall(SYS_ioprio_set, 1, 0, 0x6000);
nproc = sysconf(_SC_NPROCESSORS_ONLN);
for (i = 0; i < nproc; i++) {
pid = fork();
assert(pid != -1);
if (pid == 0) {
for (;;) {
pid = fork();
assert(pid != -1);
if (pid == 0) {
_exit(0);
} else {
child = wait(NULL);
assert(child == pid);
}
}
}
pid = fork();
assert(pid != -1);
if (pid == 0) {
for (;;) {
/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
syscall(SYS_ioprio_get, 2, 0);
}
}
}
for (;;) {
/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
syscall(SYS_ioprio_get, 2, 0);
}
return 0;
}
This gets us KASAN dumps like this:
[ 35.526914] ==================================================================
[ 35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr
ffff880066f34e6c
[ 35.530009] Read of size 2 by task ioprio-gpf/363
[ 35.530009] =============================================================================
[ 35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected
[ 35.530009] -----------------------------------------------------------------------------
[ 35.530009] Disabling lock debugging due to kernel taint
[ 35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360
[ 35.530009] ___slab_alloc+0x55d/0x5a0
[ 35.530009] __slab_alloc.isra.20+0x2b/0x40
[ 35.530009] kmem_cache_alloc_node+0x84/0x200
[ 35.530009] create_task_io_context+0x2b/0x370
[ 35.530009] get_task_io_context+0x92/0xb0
[ 35.530009] copy_process.part.8+0x5029/0x5660
[ 35.530009] _do_fork+0x155/0x7e0
[ 35.530009] SyS_clone+0x19/0x20
[ 35.530009] do_syscall_64+0x195/0x3a0
[ 35.530009] return_from_SYSCALL_64+0x0/0x6a
[ 35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060
[ 35.530009] __slab_free+0x27b/0x3d0
[ 35.530009] kmem_cache_free+0x1fb/0x220
[ 35.530009] put_io_context+0xe7/0x120
[ 35.530009] put_io_context_active+0x238/0x380
[ 35.530009] exit_io_context+0x66/0x80
[ 35.530009] do_exit+0x158e/0x2b90
[ 35.530009] do_group_exit+0xe5/0x2b0
[ 35.530009] SyS_exit_group+0x1d/0x20
[ 35.530009] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080
[ 35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001
[ 35.530009] ==================================================================
Fix it by grabbing the task lock while we poke at the io_context.
Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Borislav Petkov [Thu, 16 Jun 2016 17:13:49 +0000 (19:13 +0200)]
x86/amd_nb: Fix boot crash on non-AMD systems
[ Upstream commit
1ead852dd88779eda12cb09cc894a03d9abfe1ec ]
Fix boot crash that triggers if this driver is built into a kernel and
run on non-AMD systems.
AMD northbridges users call amd_cache_northbridges() and it returns
a negative value to signal that we weren't able to cache/detect any
northbridges on the system.
At least, it should do so as all its callers expect it to do so. But it
does return a negative value only when kmalloc() fails.
Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb
users like amd64_edac, for example, which relies on it to know whether
it should load or not, gets loaded on systems like Intel Xeons where it
shouldn't.
Reported-and-tested-by: Tony Battersby <tonyb@cybernetics.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de
Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Takashi Iwai [Wed, 29 Jun 2016 13:23:08 +0000 (15:23 +0200)]
ALSA: au88x0: Fix calculation in vortex_wtdma_bufshift()
[ Upstream commit
62db7152c924e4c060e42b34a69cd39658e8a0dc ]
vortex_wtdma_bufshift() function does calculate the page index
wrongly, first masking then shift, which always results in zero.
The proper computation is to first shift, then mask.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Brian King [Mon, 27 Jun 2016 14:09:40 +0000 (09:09 -0500)]
ipr: Clear interrupt on croc/crocodile when running with LSI
[ Upstream commit
54e430bbd490e18ab116afa4cd90dcc45787b3df ]
If we fall back to using LSI on the Croc or Crocodile chip we need to
clear the interrupt so we don't hang the system.
Cc: <stable@vger.kernel.org>
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Christophe JAILLET [Mon, 27 Jun 2016 19:06:51 +0000 (21:06 +0200)]
ALSA: echoaudio: Fix memory allocation
[ Upstream commit
9c6795a9b3cbb56a9fbfaf43909c5c22999ba317 ]
'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes.
We then copy 'sizeof(struct comm_page)' bytes in it.
On my system, smatch complains because one is 2960 and the other is 3072.
This would result in memory corruption or a oops.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Bob Copeland [Sat, 25 Jun 2016 11:58:45 +0000 (07:58 -0400)]
ALSA: hda - fix read before array start
[ Upstream commit
81e43960dce1c8e58e682fb3ec26c1d8f83a9afc ]
UBSAN reports the following warning from accessing path->path[-1]
in set_path_power():
[ 16.078040] ================================================================================
[ 16.078124] UBSAN: Undefined behaviour in sound/pci/hda/hda_generic.c:3981:17
[ 16.078198] index -1 is out of range for type 'hda_nid_t [10]'
[ 16.078270] CPU: 2 PID: 1738 Comm: modprobe Not tainted 4.7.0-rc1-wt+ #47
[ 16.078274] Hardware name: LENOVO 3443CTO/3443CTO, BIOS G6ET23WW (1.02 ) 08/14/2012
[ 16.078278]
ffff8800cb246000 ffff8800cb3638b8 ffffffff815c4fe3 0000000000000032
[ 16.078286]
ffff8800cb3638e0 ffffffffffffffff ffff8800cb3638d0 ffffffff8162443d
[ 16.078294]
ffffffffa0894200 ffff8800cb363920 ffffffff81624af7 0000000000000292
[ 16.078302] Call Trace:
[ 16.078311] [<
ffffffff815c4fe3>] dump_stack+0x86/0xd3
[ 16.078317] [<
ffffffff8162443d>] ubsan_epilogue+0xd/0x40
[ 16.078324] [<
ffffffff81624af7>] __ubsan_handle_out_of_bounds+0x67/0x70
[ 16.078335] [<
ffffffffa087665f>] set_path_power+0x1bf/0x230 [snd_hda_codec_generic]
[ 16.078344] [<
ffffffffa087880d>] add_pin_power_ctls+0x8d/0xc0 [snd_hda_codec_generic]
[ 16.078352] [<
ffffffffa087f190>] ? pin_power_down_callback+0x20/0x20 [snd_hda_codec_generic]
[ 16.078360] [<
ffffffffa0878947>] add_all_pin_power_ctls+0x107/0x150 [snd_hda_codec_generic]
[ 16.078370] [<
ffffffffa08842b3>] snd_hda_gen_parse_auto_config+0x2d73/0x49e0 [snd_hda_codec_generic]
[ 16.078376] [<
ffffffff81173360>] ? trace_hardirqs_on_caller+0x1b0/0x2c0
[ 16.078390] [<
ffffffffa089df27>] alc_parse_auto_config+0x147/0x310 [snd_hda_codec_realtek]
[ 16.078402] [<
ffffffffa08a332a>] patch_alc269+0x23a/0x560 [snd_hda_codec_realtek]
[ 16.078417] [<
ffffffffa0838644>] hda_codec_driver_probe+0xa4/0x1a0 [snd_hda_codec]
[ 16.078424] [<
ffffffff817bbac1>] driver_probe_device+0x101/0x380
[ 16.078430] [<
ffffffff817bbdf9>] __driver_attach+0xb9/0x100
[ 16.078438] [<
ffffffff817bbd40>] ? driver_probe_device+0x380/0x380
[ 16.078444] [<
ffffffff817b8d20>] bus_for_each_dev+0x70/0xc0
[ 16.078449] [<
ffffffff817bb087>] driver_attach+0x27/0x50
[ 16.078454] [<
ffffffff817ba956>] bus_add_driver+0x166/0x2c0
[ 16.078460] [<
ffffffffa0369000>] ? 0xffffffffa0369000
[ 16.078465] [<
ffffffff817bd13d>] driver_register+0x7d/0x130
[ 16.078477] [<
ffffffffa083816f>] __hda_codec_driver_register+0x6f/0x90 [snd_hda_codec]
[ 16.078488] [<
ffffffffa036901e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek]
[ 16.078493] [<
ffffffff8100215e>] do_one_initcall+0x4e/0x1d0
[ 16.078499] [<
ffffffff8119f54d>] ? rcu_read_lock_sched_held+0x6d/0x80
[ 16.078504] [<
ffffffff813701b1>] ? kmem_cache_alloc_trace+0x391/0x560
[ 16.078510] [<
ffffffff812bb314>] ? do_init_module+0x28/0x273
[ 16.078515] [<
ffffffff812bb387>] do_init_module+0x9b/0x273
[ 16.078522] [<
ffffffff811e3782>] load_module+0x20b2/0x3410
[ 16.078527] [<
ffffffff811df140>] ? m_show+0x210/0x210
[ 16.078533] [<
ffffffff813b2b26>] ? kernel_read+0x66/0xe0
[ 16.078541] [<
ffffffff811e4cfa>] SYSC_finit_module+0xba/0xc0
[ 16.078547] [<
ffffffff811e4d1e>] SyS_finit_module+0xe/0x10
[ 16.078552] [<
ffffffff81a860fc>] entry_SYSCALL_64_fastpath+0x1f/0xbd
[ 16.078556] ================================================================================
Fix by checking path->depth before use.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Sasha Levin [Wed, 13 Jul 2016 18:17:46 +0000 (14:17 -0400)]
Linux 4.1.28
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hugh Dickins [Sun, 10 Jul 2016 23:46:32 +0000 (16:46 -0700)]
tmpfs: fix regression hang in fallocate undo
[ Upstream commit
7f556567036cb7f89aabe2f0954b08566b4efb53 ]
The well-spotted fallocate undo fix is good in most cases, but not when
fallocate failed on the very first page. index 0 then passes lend -1
to shmem_undo_range(), and that has two bad effects: (a) that it will
undo every fallocation throughout the file, unrestricted by the current
range; but more importantly (b) it can cause the undo to hang, because
lend -1 is treated as truncation, which makes it keep on retrying until
every page has gone, but those already fully instantiated will never go
away. Big thank you to xfstests generic/269 which demonstrates this.
Fixes:
b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page")
Cc: stable@vger.kernel.org
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 13:37:59 +0000 (15:37 +0200)]
netfilter: x_tables: introduce and use xt_copy_counters_from_user
[ Upstream commit
d7591f0c41ce3e67600a982bab6989ef0f07b3ce ]
The three variants use same copy&pasted code, condense this into a
helper and use that.
Make sure info.name is 0-terminated.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:34 +0000 (14:17 +0200)]
netfilter: x_tables: do compat validation via translate_table
[ Upstream commit
09d9686047dbbe1cf4faa558d3ecc4aae2046054 ]
This looks like refactoring, but its also a bug fix.
Problem is that the compat path (32bit iptables, 64bit kernel) lacks a few
sanity tests that are done in the normal path.
For example, we do not check for underflows and the base chain policies.
While its possible to also add such checks to the compat path, its more
copy&pastry, for instance we cannot reuse check_underflow() helper as
e->target_offset differs in the compat case.
Other problem is that it makes auditing for validation errors harder; two
places need to be checked and kept in sync.
At a high level 32 bit compat works like this:
1- initial pass over blob:
validate match/entry offsets, bounds checking
lookup all matches and targets
do bookkeeping wrt. size delta of 32/64bit structures
assign match/target.u.kernel pointer (points at kernel
implementation, needed to access ->compatsize etc.)
2- allocate memory according to the total bookkeeping size to
contain the translated ruleset
3- second pass over original blob:
for each entry, copy the 32bit representation to the newly allocated
memory. This also does any special match translations (e.g.
adjust 32bit to 64bit longs, etc).
4- check if ruleset is free of loops (chase all jumps)
5-first pass over translated blob:
call the checkentry function of all matches and targets.
The alternative implemented by this patch is to drop steps 3&4 from the
compat process, the translation is changed into an intermediate step
rather than a full 1:1 translate_table replacement.
In the 2nd pass (step #3), change the 64bit ruleset back to a kernel
representation, i.e. put() the kernel pointer and restore ->u.user.name .
This gets us a 64bit ruleset that is in the format generated by a 64bit
iptables userspace -- we can then use translate_table() to get the
'native' sanity checks.
This has two drawbacks:
1. we re-validate all the match and target entry structure sizes even
though compat translation is supposed to never generate bogus offsets.
2. we put and then re-lookup each match and target.
THe upside is that we get all sanity tests and ruleset validations
provided by the normal path and can remove some duplicated compat code.
iptables-restore time of autogenerated ruleset with 300k chains of form
-A CHAIN0001 -m limit --limit 1/s -j CHAIN0002
-A CHAIN0002 -m limit --limit 1/s -j CHAIN0003
shows no noticeable differences in restore times:
old: 0m30.796s
new: 0m31.521s
64bit: 0m25.674s
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:33 +0000 (14:17 +0200)]
netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
[ Upstream commit
0188346f21e6546498c2a0f84888797ad4063fc5 ]
Always returned 0.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:31 +0000 (14:17 +0200)]
netfilter: ip6_tables: simplify translate_compat_table args
[ Upstream commit
329a0807124f12fe1c8032f95d8a8eb47047fb0e ]
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:30 +0000 (14:17 +0200)]
netfilter: ip_tables: simplify translate_compat_table args
[ Upstream commit
7d3f843eed29222254c9feab481f55175a1afcc9 ]
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:32 +0000 (14:17 +0200)]
netfilter: arp_tables: simplify translate_compat_table args
[ Upstream commit
8dddd32756f6fe8e4e82a63361119b7e2384e02f ]
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Wed, 1 Jun 2016 00:04:44 +0000 (02:04 +0200)]
netfilter: x_tables: don't reject valid target size on some architectures
[ Upstream commit
7b7eba0f3515fca3296b8881d583f7c1042f5226 ]
Quoting John Stultz:
In updating a 32bit arm device from 4.6 to Linus' current HEAD, I
noticed I was having some trouble with networking, and realized that
/proc/net/ip_tables_names was suddenly empty.
Digging through the registration process, it seems we're catching on the:
if (strcmp(t->u.user.name, XT_STANDARD_TARGET) == 0 &&
target_offset + sizeof(struct xt_standard_target) != next_offset)
return -EINVAL;
Where next_offset seems to be 4 bytes larger then the
offset + standard_target struct size.
next_offset needs to be aligned via XT_ALIGN (so we can access all members
of ip(6)t_entry struct).
This problem didn't show up on i686 as it only needs 4-byte alignment for
u64, but iptables userspace on other 32bit arches does insert extra padding.
Reported-by: John Stultz <john.stultz@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Fixes:
7ed2abddd20cf ("netfilter: x_tables: check standard target size too")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:29 +0000 (14:17 +0200)]
netfilter: x_tables: validate all offsets and sizes in a rule
[ Upstream commit
13631bfc604161a9d69cd68991dff8603edd66f9 ]
Validate that all matches (if any) add up to the beginning of
the target and that each match covers at least the base structure size.
The compat path should be able to safely re-use the function
as the structures only differ in alignment; added a
BUILD_BUG_ON just in case we have an arch that adds padding as well.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:28 +0000 (14:17 +0200)]
netfilter: x_tables: check for bogus target offset
[ Upstream commit
ce683e5f9d045e5d67d1312a42b359cb2ab2a13c ]
We're currently asserting that targetoff + targetsize <= nextoff.
Extend it to also check that targetoff is >= sizeof(xt_entry).
Since this is generic code, add an argument pointing to the start of the
match/target, we can then derive the base structure size from the delta.
We also need the e->elems pointer in a followup change to validate matches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:27 +0000 (14:17 +0200)]
netfilter: x_tables: check standard target size too
[ Upstream commit
7ed2abddd20cf8f6bd27f65bd218f26fa5bf7f44 ]
We have targets and standard targets -- the latter carries a verdict.
The ip/ip6tables validation functions will access t->verdict for the
standard targets to fetch the jump offset or verdict for chainloop
detection, but this happens before the targets get checked/validated.
Thus we also need to check for verdict presence here, else t->verdict
can point right after a blob.
Spotted with UBSAN while testing malformed blobs.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:26 +0000 (14:17 +0200)]
netfilter: x_tables: add compat version of xt_check_entry_offsets
[ Upstream commit
fc1221b3a163d1386d1052184202d5dc50d302d1 ]
32bit rulesets have different layout and alignment requirements, so once
more integrity checks get added to xt_check_entry_offsets it will reject
well-formed 32bit rulesets.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:25 +0000 (14:17 +0200)]
netfilter: x_tables: assert minimum target size
[ Upstream commit
a08e4e190b866579896c09af59b3bdca821da2cd ]
The target size includes the size of the xt_entry_target struct.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:24 +0000 (14:17 +0200)]
netfilter: x_tables: kill check_entry helper
[ Upstream commit
aa412ba225dd3bc36d404c28cdc3d674850d80d0 ]
Once we add more sanity testing to xt_check_entry_offsets it
becomes relvant if we're expecting a 32bit 'config_compat' blob
or a normal one.
Since we already have a lot of similar-named functions (check_entry,
compat_check_entry, find_and_check_entry, etc.) and the current
incarnation is short just fold its contents into the callers.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:23 +0000 (14:17 +0200)]
netfilter: x_tables: add and use xt_check_entry_offsets
[ Upstream commit
7d35812c3214afa5b37a675113555259cfd67b98 ]
Currently arp/ip and ip6tables each implement a short helper to check that
the target offset is large enough to hold one xt_entry_target struct and
that t->u.target_size fits within the current rule.
Unfortunately these checks are not sufficient.
To avoid adding new tests to all of ip/ip6/arptables move the current
checks into a helper, then extend this helper in followup patches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:22 +0000 (14:17 +0200)]
netfilter: x_tables: validate targets of jumps
[ Upstream commit
36472341017529e2b12573093cc0f68719300997 ]
When we see a jump also check that the offset gets us to beginning of
a rule (an ipt_entry).
The extra overhead is negible, even with absurd cases.
300k custom rules, 300k jumps to 'next' user chain:
[ plus one jump from INPUT to first userchain ]:
Before:
real 0m24.874s
user 0m7.532s
sys 0m16.076s
After:
real 0m27.464s
user 0m7.436s
sys 0m18.840s
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Florian Westphal [Fri, 1 Apr 2016 12:17:21 +0000 (14:17 +0200)]
netfilter: x_tables: don't move to non-existent next rule
[ Upstream commit
f24e230d257af1ad7476c6e81a8dc3127a74204e ]
Ben Hawkes says:
In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
is possible for a user-supplied ipt_entry structure to have a large
next_offset field. This field is not bounds checked prior to writing a
counter value at the supplied offset.
Base chains enforce absolute verdict.
User defined chains are supposed to end with an unconditional return,
xtables userspace adds them automatically.
But if such return is missing we will move to non-existent next rule.
Reported-by: Ben Hawkes <hawkes@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>