Greg Kroah-Hartman [Tue, 16 Dec 2014 17:09:56 +0000 (09:09 -0800)]
Linux 3.10.63
Anton Blanchard [Wed, 26 Nov 2014 21:11:28 +0000 (08:11 +1100)]
powerpc: 32 bit getcpu VDSO function uses 64 bit instructions
commit
152d44a853e42952f6c8a504fb1f8eefd21fd5fd upstream.
I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.
Fixes:
18ad51dd342a ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Fujinaka [Tue, 17 Jun 2014 06:58:11 +0000 (06:58 +0000)]
igb: bring link up when PHY is powered up
commit
aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.
Call igb_setup_link() when the PHY is powered up.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Reported-by: Jeff Westfahl <jeff.westfahl@ni.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nadav Har'El [Mon, 5 Aug 2013 08:07:17 +0000 (11:07 +0300)]
nEPT: Nested INVEPT
commit
bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.
If we let L1 use EPT, we should probably also support the INVEPT instruction.
In our current nested EPT implementation, when L1 changes its EPT table
for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
the course of this modification already calls INVEPT. But if last level
of shadow page is unsync not all L1's changes to EPT12 are intercepted,
which means roots need to be synced when L1 calls INVEPT. Global INVEPT
should not be different since roots are synced by kvm_mmu_load() each
time EPTP02 changes.
Reviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Nadav Har'El <nyh@il.ibm.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Xinhao Xu <xinhao.xu@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 3.2:
- Adjust context, filename
- Simplify handle_invept() as recommended by Paolo - nEPT is not
supported so we always raise #UD]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Vinson Lee <vlee@twopensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
willy tarreau [Tue, 2 Dec 2014 07:13:04 +0000 (08:13 +0100)]
net: mvneta: fix Tx interrupt delay
[ Upstream commit
aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ]
The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.
The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.
In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.
The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.
Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.
No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.
This fix needs to be applied to stable kernels starting with 3.10.
Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jack Morgenstein [Tue, 25 Nov 2014 09:54:31 +0000 (11:54 +0200)]
net/mlx4_core: Limit count field to 24 bits in qp_alloc_res
[ Upstream commit
2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ]
Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.
Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.
As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.
Fixes:
c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuri Chislov [Mon, 24 Nov 2014 10:25:15 +0000 (11:25 +0100)]
ipv6: gre: fix wrong skb->protocol in WCCP
[ Upstream commit
be6572fdb1bfbe23b2624d477de50af50b02f5d6 ]
When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.
Fixes:
c12b395a4664 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Yuri Chislov <yuri.chislov@gmail.com>
Tested-by: Yuri Chislov <yuri.chislov@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Thu, 4 Dec 2014 18:13:28 +0000 (13:13 -0500)]
ahci: disable MSI on SAMSUNG 0xa800 SSD
commit
2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream.
Just like 0x1600 which got blacklisted by
66a7cbc303f4 ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled. Disable MSI.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dominik Mierzejewski <dominik@greysector.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sakari Ailus [Thu, 6 Nov 2014 20:49:45 +0000 (17:49 -0300)]
media: smiapp: Only some selection targets are settable
commit
b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.
Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Petr Mladek [Thu, 27 Nov 2014 15:57:21 +0000 (16:57 +0100)]
drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
commit
f5475cc43c899e33098d4db44b7c5e710f16589d upstream.
I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():
[drm] Initialized drm 1.1.0
20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
[drm] register mmio base: 0xC8400000
[drm] register mmio size: 65536
radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 16bits DDR
[TTM] Zone kernel: Available graphics memory:
3829346 kiB
[TTM] Zone dma32: Available graphics memory:
2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 16M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x0000000037880000).
radeon 0000:0b:01.0: WB disabled
radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:0b:01.0: failed initializing CP (-2).
radeon 0000:0b:01.0: Disabling GPU acceleration
[drm] radeon: cp finalized
BUG: unable to handle kernel NULL pointer dereference at
000000000000025c
IP: [<
ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
task:
ffff880234da2010 ti:
ffff880234da4000 task.ti:
ffff880234da4000
RIP: 0010:[<
ffffffff8150423b>] [<
ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP: 0000:
ffff880234da7918 EFLAGS:
00010086
RAX:
ffffffff81557890 RBX:
0000000000000000 RCX:
ffff880234da7a48
RDX:
ffff880234da79f4 RSI:
0000000000000000 RDI:
ffff880232e15000
RBP:
ffff880234da79b8 R08:
0000000000000000 R09:
0000000000000000
R10:
000000000000000a R11:
0000000000000001 R12:
ffff880232dda1c0
R13:
ffff880232e1518c R14:
0000000000000292 R15:
ffff880232e15000
FS:
0000000000000000(0000) GS:
ffff88023fc40000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
000000000000025c CR3:
0000000002014000 CR4:
00000000000007e0
Stack:
ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
Call Trace:
[<
ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
[<
ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
[<
ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
[<
ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
[<
ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
[<
ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
[<
ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
[<
ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
[<
ffffffff8156c07e>] r100_init+0x26e/0x410
[<
ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
[<
ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
[<
ffffffff81506965>] drm_dev_register+0xb5/0x110
[<
ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
[<
ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
[<
ffffffff8141a365>] local_pci_probe+0x45/0xa0
[<
ffffffff8141b741>] pci_device_probe+0xd1/0x130
[<
ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
[<
ffffffff8163413b>] __driver_attach+0x9b/0xa0
[<
ffffffff816340a0>] ? __device_attach+0x40/0x40
[<
ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
[<
ffffffff8163378e>] driver_attach+0x1e/0x20
[<
ffffffff81633390>] bus_add_driver+0x180/0x240
[<
ffffffff81634914>] driver_register+0x64/0xf0
[<
ffffffff81419cac>] __pci_register_driver+0x4c/0x50
[<
ffffffff81509bf5>] drm_pci_init+0xf5/0x120
[<
ffffffff821dc871>] ? ttm_init+0x6a/0x6a
[<
ffffffff821dc908>] radeon_init+0x97/0xb5
[<
ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
[<
ffffffff810e3278>] ? __wake_up+0x48/0x60
[<
ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
[<
ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
[<
ffffffff818a78f0>] ? rest_init+0x80/0x80
[<
ffffffff818a78fe>] kernel_init+0xe/0xf0
[<
ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
[<
ffffffff818a78f0>] ? rest_init+0x80/0x80
Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
RIP [<
ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP <
ffff880234da7918>
CR2:
000000000000025c
---[ end trace
ad2c0aadf48e2032 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Kochetkov [Fri, 21 Nov 2014 00:16:51 +0000 (04:16 +0400)]
i2c: omap: fix i207 errata handling
commit
ccfc866356674cb3a61829d239c685af6e85f197 upstream.
commit
6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled.
6d9939f6514 code doesn't correspond to workaround provided by
errata.
According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.
Restored pre
6d9939f6514 way of handling errata.
Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes:
6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seth Forshee [Wed, 26 Nov 2014 02:28:24 +0000 (20:28 -0600)]
xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
commit
8d609725d4357f499e2103e46011308b32f53513 upstream.
These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.
Fixes:
f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Weijie Yang [Tue, 2 Dec 2014 23:59:25 +0000 (15:59 -0800)]
mm: frontswap: invalidate expired data on a dup-store failure
commit
fb993fa1a2f669215fa03a09eed7848f2663e336 upstream.
If a frontswap dup-store failed, it should invalidate the expired page
in the backend, or it could trigger some data corruption issue.
Such as:
1. use zswap as the frontswap backend with writeback feature
2. store a swap page(version_1) to entry A, success
3. dup-store a newer page(version_2) to the same entry A, fail
4. use __swap_writepage() write version_2 page to swapfile, success
5. zswap do shrink, writeback version_1 page to swapfile
6. version_2 page is overwrited by version_1, data corrupt.
This patch fixes this issue by invalidating expired data immediately
when meet a dup-store failure.
Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 6 Dec 2014 23:55:43 +0000 (15:55 -0800)]
Linux 3.10.62
Sergio Gelato [Wed, 24 Sep 2014 06:47:24 +0000 (08:47 +0200)]
nfsd: Fix ACL null pointer deref
BugLink: http://bugs.launchpad.net/bugs/1348670
Fix regression introduced in pre-3.14 kernels by cherry-picking
aa07c713ecfc0522916f3cd57ac628ea6127c0ec
(NFSD: Call ->set_acl with a NULL ACL structure if no entries).
The affected code was removed in 3.14 by commit
4ac7249ea5a0ceef9f8269f63f33cc873c3fac61
(nfsd: use get_acl and ->set_acl).
The ->set_acl methods are already able to cope with a NULL argument.
Signed-off-by: Sergio Gelato <Sergio.Gelato@astro.su.se>
[bwh: Rewrite the subject]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Moritz Mühlenhoff <muehlenhoff@univention.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Herrenschmidt [Tue, 7 Oct 2014 05:12:36 +0000 (16:12 +1100)]
powerpc/powernv: Honor the generic "no_64bit_msi" flag
commit
360743814c4082515581aa23ab1d8e699e1fbe88 upstream.
Instead of the arch specific quirk which we are deprecating
and that drivers don't understand.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maurizio Lombardi [Thu, 20 Nov 2014 10:17:33 +0000 (11:17 +0100)]
bnx2fc: do not add shared skbs to the fcoe_rx_list
commit
01a4cc4d0cd6a836c7b923760e8eb1cbb6a47258 upstream.
In some cases, the fcoe_rx_list may contains multiple instances
of the same skb (the so called "shared skbs").
the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
modifies (and destroys) its content and then proceed to the next one.
The problem is that if the skb is shared, the remaining instances will
be corrupted.
The solution is to use skb_share_check() before adding the skb to the
fcoe_rx_list.
[ 6286.808725] ------------[ cut here ]------------
[ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
[ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
[ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
[ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 6286.808752]
0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba
[ 6286.808753]
ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888
[ 6286.808754]
ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48
[ 6286.808754] Call Trace:
[ 6286.808759] [<
ffffffff815ec0ba>] dump_stack+0x19/0x1b
[ 6286.808762] [<
ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
[ 6286.808763] [<
ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20
[ 6286.808765] [<
ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
[ 6286.808767] [<
ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
[ 6286.808769] [<
ffffffff81085aef>] kthread+0xcf/0xe0
[ 6286.808770] [<
ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
[ 6286.808772] [<
ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
[ 6286.808773] [<
ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
[ 6286.808774] ---[ end trace
c6cdb939184ccb4e ]---
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Acked-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
J. Bruce Fields [Thu, 15 Aug 2013 20:55:26 +0000 (16:55 -0400)]
nfsd4: fix leak of inode reference on delegation failure
commit
bf7bd3e98be5c74813bee6ad496139fb0a011b3b upstream.
This fixes a regression from
68a3396178e6688ad7367202cdf0af8ed03c8727
"nfsd4: shut down more of delegation earlier".
After that commit, nfs4_set_delegation() failures result in
nfs4_put_delegation being called, but nfs4_put_delegation doesn't free
the nfs4_file that has already been set by alloc_init_deleg().
This can result in an oops on later unmounting the exported filesystem.
Note also delaying the fi_had_conflict check we're able to return a
better error (hence give 4.1 clients a better idea why the delegation
failed; though note CONFLICT isn't an exact match here, as that's
supposed to indicate a current conflict, but all we know here is that
there was one recently).
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
[tuomasjjrasanen: backported to 3.10
Conflicts fs/nfsd/nfs4state.c:
Delegation type flags have been removed from upstream code. In 3.10-series,
they still exists and therefore the commit caused few conflicts in function
signatures.
]
Signed-off-by: Tuomas Räsänen <tuomasjjrasanen@opinsys.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Wed, 19 Nov 2014 17:47:50 +0000 (12:47 -0500)]
nfsd: Fix slot wake up race in the nfsv4.1 callback code
commit
c6c15e1ed303ffc47e696ea1c9a9df1761c1f603 upstream.
The currect code for nfsd41_cb_get_slot() and nfsd4_cb_done() has no
locking in order to guarantee atomicity, and so allows for races of
the form.
Task 1 Task 2
====== ======
if (test_and_set_bit(0) != 0) {
clear_bit(0)
rpc_wake_up_next(queue)
rpc_sleep_on(queue)
return false;
}
This patch breaks the race condition by adding a retest of the bit
after the call to rpc_sleep_on().
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Tue, 11 Nov 2014 13:28:47 +0000 (14:28 +0100)]
rt2x00: do not align payload on modern H/W
commit
cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.
RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.
For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.
Patch fixes skb_under_panic problems reported from time to time:
https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&m=
139108549530402&w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
1087591
Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:
if (payload_length && payload_align > header_align)
header_align += 4;
but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).
Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
Debugged-by: Antti S. Lankila <alankila@bel.fi>
Reported-by: Henrik Asp <solenskiner@gmail.com>
Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Körper [Fri, 31 Oct 2014 06:33:54 +0000 (07:33 +0100)]
can: dev: avoid calling kfree_skb() from interrupt context
commit
5247a589c24022ab34e780039cc8000c48f2035e upstream.
ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:
[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778] [<
c167906f>] dump_stack+0x41/0x52
[ 1153.360782] [<
c105bb7e>] warn_slowpath_common+0x7e/0xa0
[ 1153.360784] [<
c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786] [<
c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788] [<
c105bc42>] warn_slowpath_null+0x22/0x30
[ 1153.360791] [<
c158b909>] skb_release_head_state+0xb9/0xd0
[ 1153.360793] [<
c158be90>] skb_release_all+0x10/0x30
[ 1153.360795] [<
c158bf06>] kfree_skb+0x36/0x80
[ 1153.360799] [<
f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802] [<
f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805] [<
f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809] [<
c10a75b5>] handle_irq_event_percpu+0x35/0x180
[ 1153.360811] [<
c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813] [<
c10a7731>] handle_irq_event+0x31/0x50
[ 1153.360816] [<
c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818] [<
c10a9c10>] ? handle_edge_irq+0x110/0x110
[ 1153.360822] [<
c1011b61>] handle_irq+0x71/0x90
[ 1153.360823] <IRQ> [<
c168152c>] do_IRQ+0x3c/0xd0
[ 1153.360829] [<
c1680b6c>] common_interrupt+0x2c/0x34
[ 1153.360834] [<
c107d277>] ? finish_task_switch+0x47/0xf0
[ 1153.360836] [<
c167c27b>] __schedule+0x35b/0x7e0
[ 1153.360839] [<
c10a5334>] ? console_unlock+0x2c4/0x4d0
[ 1153.360842] [<
c13df500>] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845] [<
c10707b6>] ? process_one_work+0x196/0x370
[ 1153.360847] [<
c167c723>] schedule+0x23/0x60
[ 1153.360849] [<
c1070de1>] worker_thread+0x161/0x460
[ 1153.360852] [<
c1090fcf>] ? __wake_up_locked+0x1f/0x30
[ 1153.360854] [<
c1070c80>] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856] [<
c1074f01>] kthread+0xa1/0xc0
[ 1153.360859] [<
c1680401>] ret_from_kernel_thread+0x21/0x30
[ 1153.360861] [<
c1074e60>] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace
5ff83639cbb74b35 ]---
This patch replaces the kfree_skb() by dev_kfree_skb_any().
Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thor Thayer [Thu, 6 Nov 2014 19:54:27 +0000 (13:54 -0600)]
spi: dw: Fix dynamic speed change.
commit
0a8727e69778683495058852f783eeda141a754e upstream.
An IOCTL call that calls spi_setup() and then dw_spi_setup() will
overwrite the persisted last transfer speed. On each transfer, the
SPI speed is compared to the last transfer speed to determine if the
clock divider registers need to be updated (did the speed change?).
This bug was observed with the spidev driver using spi-config to
update the max transfer speed.
This fix: Don't overwrite the persisted last transaction clock speed
when updating the SPI parameters in dw_spi_setup(). On the next
transaction, the new speed won't match the persisted last speed
and the hardware registers will be updated.
On initialization, the persisted last transaction clock
speed will be 0 but will be updated after the first SPI
transaction.
Move zeroed clock divider check into clock change test because
chip->clk_div is zero on startup and would cause a divide-by-zero
error. The calculation was wrong as well (can't support odd #).
Reported-by: Vlastimil Setka <setka@vsis.cz>
Signed-off-by: Vlastimil Setka <setka@vsis.cz>
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sagi Grimberg [Tue, 28 Oct 2014 20:45:03 +0000 (13:45 -0700)]
iser-target: Handle DEVICE_REMOVAL event on network portal listener correctly
commit
3b726ae2de02a406cc91903f80132daee37b6f1b upstream.
In this case the cm_id->context is the isert_np, and the cm_id->qp
is NULL, so use that to distinct the cases.
Since we don't expect any other events on this cm_id we can
just return -1 for explicit termination of the cm_id by the
cma layer.
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roland Dreier [Tue, 14 Oct 2014 21:16:24 +0000 (14:16 -0700)]
target: Don't call TFO->write_pending if data_length == 0
commit
885e7b0e181c14e4d0ddd26c688bad2b84c1ada9 upstream.
If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
sets the transfer direction in the transport layer to indicate a
data-out phase, we still shouldn't try to transfer data. At best it's
a NOP, and depending on the transport, we might crash on an
uninitialized sg list.
Reported-by: Craig Watson <craig.watson@vanguard-rugged.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Sun, 19 Oct 2014 15:05:33 +0000 (18:05 +0300)]
srp-target: Retry when QP creation fails with ENOMEM
commit
ab477c1ff5e0a744c072404bf7db51bfe1f05b6e upstream.
It is not guaranteed to that srp_sq_size is supported
by the HCA. So if we failed to create the QP with ENOMEM,
try with a smaller srp_sq_size. Keep it up until we hit
MIN_SRPT_SQ_SIZE, then fail the connection.
Reported-by: Mark Lehrer <lehrer@gmail.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 25 Nov 2014 08:38:17 +0000 (00:38 -0800)]
Input: xpad - use proper endpoint type
commit
a1f9a4072655843fc03186acbad65990cc05dd2d upstream.
The xpad wireless endpoint is not a bulk endpoint on my devices, but
rather an interrupt one, so the USB core complains when it is submitted.
I'm guessing that the author really did mean that this should be an
interrupt urb, but as there are a zillion different xpad devices out
there, let's cover out bases and handle both bulk and interrupt
endpoints just as easily.
Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Tue, 25 Nov 2014 17:43:15 +0000 (18:43 +0100)]
ARM: 8222/1: mvebu: enable strex backoff delay
commit
995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.
Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.
This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.
Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.
[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]
Fixes:
de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Eremin-Solenikov [Fri, 21 Nov 2014 14:29:00 +0000 (15:29 +0100)]
ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
commit
ef59a20ba375aeb97b3150a118318884743452a8 upstream.
According to the manuals I have, XScale auxiliary register should be
reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
also use c1, c0, 1.
The issue was primarily noticed thanks to qemu reporing "unsupported
instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
XScale Core manuals and in PXA270 and PXA320 Developers Guides.
Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jurgen Kramer [Sat, 15 Nov 2014 13:01:21 +0000 (14:01 +0100)]
ALSA: usb-audio: Add ctrl message delay quirk for Marantz/Denon devices
commit
6e84a8d7ac3ba246ef44e313e92bc16a1da1b04a upstream.
This patch adds a USB control message delay quirk for a few specific Marantz/Denon
devices. Without the delay the DACs will not work properly and produces the
following type of messages:
Nov 15 10:09:21 orwell kernel: [ 91.342880] usb 3-13: clock source 41 is not valid, cannot use
Nov 15 10:09:21 orwell kernel: [ 91.343775] usb 3-13: clock source 41 is not valid, cannot use
There are likely other Marantz/Denon devices using the same USB module which exhibit the
same problems. But as this cannot be verified I limited the patch to the devices
I could test.
The following two devices are covered by this path:
- Marantz SA-14S1
- Marantz HD-DAC1
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Fri, 10 Oct 2014 20:31:07 +0000 (00:31 +0400)]
can: esd_usb2: fix memory leak on disconnect
commit
efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.
It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Tue, 18 Nov 2014 09:27:11 +0000 (11:27 +0200)]
USB: xhci: don't start a halted endpoint before its new dequeue is set
commit
c3492dbfa1050debf23a5b5cd2bc7514c5b37896 upstream.
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes:
e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Mon, 24 Nov 2014 10:22:38 +0000 (11:22 +0100)]
usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000
commit
263e80b43559a6103e178a9176938ce171b23872 upstream.
This wireless mouse receiver needs a reset-resume quirk to properly come
out of reset.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Troy Clark [Mon, 17 Nov 2014 22:33:17 +0000 (14:33 -0800)]
usb: serial: ftdi_sio: add PIDs for Matrix Orbital products
commit
204ec6e07ea7aff863df0f7c53301f9cbbfbb9d3 upstream.
Add PIDs for new Matrix Orbital GTT series products.
Signed-off-by: Troy Clark <tclark@matrixorbital.ca>
[johan: shorten commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Preston Fick [Sat, 8 Nov 2014 05:26:11 +0000 (23:26 -0600)]
USB: serial: cp210x: add IDs for CEL MeshConnect USB Stick
commit
ffcfe30ebd8dd703d0fc4324ffe56ea21f5479f4 upstream.
Signed-off-by: Preston Fick <pffick@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 18 Nov 2014 10:25:19 +0000 (11:25 +0100)]
USB: keyspan: fix tty line-status reporting
commit
5d1678a33c731b56e245e888fdae5e88efce0997 upstream.
Fix handling of TTY error flags, which are not bitmasks and must
specifically not be ORed together as this prevents the line discipline
from recognising them.
Also insert null characters when reporting overrun errors as these are
not associated with the received character.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 18 Nov 2014 10:25:20 +0000 (11:25 +0100)]
USB: keyspan: fix overrun-error reporting
commit
855515a6d3731242d85850a206f2ec084c917338 upstream.
Fix reporting of overrun errors, which are not associated with a
character. Instead insert a null character and report only once.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 18 Nov 2014 10:25:21 +0000 (11:25 +0100)]
USB: ssu100: fix overrun-error reporting
commit
75bcbf29c284dd0154c3e895a0bd1ef0e796160e upstream.
Fix reporting of overrun errors, which should only be reported once
using the inserted null character.
Fixes:
6b8f1ca5581b ("USB: ssu100: set tty_flags in ssu100_process_packet")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cristina Ciocan [Tue, 11 Nov 2014 14:07:42 +0000 (16:07 +0200)]
iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask
commit
ccf54555da9a5e91e454b909ca6a5303c7d6b910 upstream.
The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask
in order to retrieve it, that is 0x7F, not 0xCF as it is now.
Fixes:
ade7ef7ba (staging:iio: Differential channel handling)
Signed-off-by: Cristina Ciocan <cristina.ciocan@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Dufour [Mon, 24 Nov 2014 14:07:53 +0000 (15:07 +0100)]
powerpc/pseries: Fix endiannes issue in RTAS call from xmon
commit
3b8a3c01096925a824ed3272601082289d9c23a5 upstream.
On pseries system (LPAR) xmon failed to enter when running in LE mode,
system is hunging. Inititating xmon will lead to such an output on the
console:
SysRq : Entering xmon
cpu 0x15: Vector: 0 at [
c0000003f39ffb10]
pc:
c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
lr:
c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
sp:
c0000003f39ffc70
msr:
8000000000009033
current = 0xc0000003fafa7180
paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01
pid = 14617, comm = bash
Bad kernel stack pointer
fafb4b0 at
eca7cc4
cpu 0x15: Vector: 300 (Data Access) at [
c000000007f07d40]
pc:
000000000eca7cc4
lr:
000000000eca7c44
sp:
fafb4b0
msr:
8000000000001000
dar:
10000000
dsisr:
42000000
current = 0xc0000003fafa7180
paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01
pid = 14617, comm = bash
cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
xmon: WARNING: bad recursive fault on cpu 0x15
The root cause is that xmon is calling RTAS to turn off the surveillance
when entering xmon, and RTAS is requiring big endian parameters.
This patch is byte swapping the RTAS arguments when running in LE mode.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Herrenschmidt [Tue, 7 Oct 2014 05:12:55 +0000 (16:12 +1100)]
powerpc/pseries: Honor the generic "no_64bit_msi" flag
commit
415072a041bf50dbd6d56934ffc0cbbe14c97be8 upstream.
Instead of the arch specific quirk which we are deprecating
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Herrenschmidt [Fri, 14 Nov 2014 06:55:03 +0000 (17:55 +1100)]
of/base: Fix PowerPC address parsing hack
commit
746c9e9f92dde2789908e51a354ba90a1962a2eb upstream.
We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac "bad"
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.
This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Charles Keepax [Mon, 17 Nov 2014 10:48:21 +0000 (10:48 +0000)]
ASoC: wm_adsp: Avoid attempt to free buffers that might still be in use
commit
9da7a5a9fdeeb76b2243f6b473363a7e6147ab6f upstream.
We should not free any buffers associated with writing out coefficients
to the DSP until all the async writes have completed. This patch updates
the out of memory path when allocating a new buffer to include a call to
regmap_async_complete.
Reported-by: JS Park <aitdark.park@samsung.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Estevam [Fri, 14 Nov 2014 04:14:47 +0000 (02:14 -0200)]
ASoC: sgtl5000: Fix SMALL_POP bit definition
commit
c251ea7bd7a04f1f2575467e0de76e803cf59149 upstream.
On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen
5 seconds after the end of a playback.
The SMALL_POP bit should fix this, but its definition is incorrect:
according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
bit 1.
Fix the definition accordingly and enable the bit as intended per the code
comment.
After applying this change, no loud 'click' sound is heard after playback
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Herrenschmidt [Fri, 3 Oct 2014 05:13:24 +0000 (15:13 +1000)]
PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
commit
f144d1496b47e7450f41b767d0d91c724c2198bc upstream.
This can be set by quirks/drivers to be used by the architecture code
that assigns the MSI addresses.
We additionally add verification in the core MSI code that the values
assigned by the architecture do satisfy the limitation in order to fail
gracefully if they don't (ie. the arch hasn't been updated to deal with
that quirk yet).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Bohac [Wed, 19 Nov 2014 22:05:49 +0000 (23:05 +0100)]
ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
[ Upstream commit
01462405f0c093b2f8dfddafcadcda6c9e4c5cdf ]
This fixes an old regression introduced by commit
b0d0d915 (ipx: remove the BKL).
When a recvmsg syscall blocks waiting for new data, no data can be sent on the
same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
This breaks mars-nwe (NetWare emulator):
- the ncpserv process reads the request using recvmsg
- ncpserv forks and spawns nwconn
- ncpserv calls a (blocking) recvmsg and waits for new requests
- nwconn deadlocks in sendmsg on the same socket
Commit
b0d0d915 has simply replaced BKL locking with
lock_sock/release_sock. Unlike now, BKL got unlocked while
sleeping, so a blocking recvmsg did not block a concurrent
sendmsg.
Only keep the socket locked while actually working with the socket data and
release it prior to calling skb_recv_datagram().
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Wed, 19 Nov 2014 17:05:26 +0000 (18:05 +0100)]
pptp: fix stack info leak in pptp_getname()
[ Upstream commit
a5f6fc28d6e6cc379c6839f21820e62262419584 ]
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Fix this by memset(0)'ing the union before.
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Hauke [Sun, 16 Nov 2014 18:55:25 +0000 (19:55 +0100)]
qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
[ Upstream commit
bb2bdeb83fb125c95e47fc7eca2a3e8f868e2a74 ]
Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
Signed-off-by: Martin Hauke <mardnh@gmx.de>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Fri, 14 Nov 2014 23:11:59 +0000 (02:11 +0300)]
ieee802154: fix error handling in ieee802154fake_probe()
[ Upstream commit
8c2dd54485ccee7fc4086611e188478584758c8d ]
In case of any failure ieee802154fake_probe() just calls unregister_netdev().
But it does not look safe to unregister netdevice before it was registered.
The patch implements straightforward resource deallocation in case of
failure in ieee802154fake_probe().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Panu Matilainen [Fri, 14 Nov 2014 11:14:32 +0000 (13:14 +0200)]
ipv4: Fix incorrect error code when adding an unreachable route
[ Upstream commit
49dd18ba4615eaa72f15c9087dea1c2ab4744cf5 ]
Trying to add an unreachable route incorrectly returns -ESRCH if
if custom FIB rules are present:
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: Network is unreachable
[root@localhost ~]# ip rule add to 55.66.77.88 table 200
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: No such process
[root@localhost ~]#
Commit
83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
return value for rule lookup") changed fib_rules_lookup()
to use -ESRCH as a "not found" code internally, but for user space it
should be translated into -ENETUNREACH. Handle the translation centrally in
ipv4-specific fib_lookup(), leaving the DECnet case alone.
On a related note, commit
b7a71b51ee37d919e4098cd961d59a883fd272d8
("ipv4: removed redundant conditional") removed a similar translation from
ip_route_input_slow() prematurely AIUI.
Fixes:
b7a71b51ee37 ("ipv4: removed redundant conditional")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vincent BENAYOUN [Thu, 13 Nov 2014 12:47:26 +0000 (13:47 +0100)]
inetdevice: fixed signed integer overflow
[ Upstream commit
84bc88688e3f6ef843aa8803dbcd90168bb89faf ]
There could be a signed overflow in the following code.
The expression, (32-logmask) is comprised between 0 and 31 included.
It may be equal to 31.
In such a case the left shift will produce a signed integer overflow.
According to the C99 Standard, this is an undefined behavior.
A simple fix is to replace the signed int 1 with the unsigned int 1U.
Signed-off-by: Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Sun, 16 Nov 2014 21:19:32 +0000 (13:19 -0800)]
sparc64: Fix constraints on swab helpers.
[ Upstream commit
5a2b59d3993e8ca4f7788a48a23e5cb303f26954 ]
We are reading the memory location, so we have to have a memory
constraint in there purely for the sake of showing the data flow
to the compiler.
Reported-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Fri, 21 Nov 2014 21:26:07 +0000 (13:26 -0800)]
uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
commit
82975bc6a6df743b9a01810fb32cb65d0ec5d60b upstream.
x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but
not on non-paranoid returns. I suspect that this is a mistake and that
the code only works because int3 is paranoid.
Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround
for the x86 bug. With that bug fixed, we can remove _TIF_NOTIFY_RESUME
from the uprobes code.
Reported-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Fri, 14 Nov 2014 19:47:37 +0000 (11:47 -0800)]
x86, mm: Set NX across entire PMD at boot
commit
45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 upstream.
When setting up permissions on kernel memory at boot, the end of the
PMD that was split from bss remained executable. It should be NX like
the rest. This performs a PMD alignment instead of a PAGE alignment to
get the correct span of memory.
Before:
---[ High Kernel Mapping ]---
...
0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte
0xffffffff82200000-0xffffffff82c00000 10M RW PSE GLB NX pmd
0xffffffff82c00000-0xffffffff82df5000 2004K RW GLB NX pte
0xffffffff82df5000-0xffffffff82e00000 44K RW GLB x pte
0xffffffff82e00000-0xffffffffc0000000 978M pmd
After:
---[ High Kernel Mapping ]---
...
0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte
0xffffffff82200000-0xffffffff82e00000 12M RW PSE GLB NX pmd
0xffffffff82e00000-0xffffffffc0000000 978M pmd
[ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
We really should unmap the reminder along with the holes
caused by init,initdata etc. but thats a different issue ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Hansen [Tue, 11 Nov 2014 22:01:33 +0000 (14:01 -0800)]
x86: Require exact match for 'noxsave' command line option
commit
2cd3949f702692cf4c5d05b463f19cd706a92dd3 upstream.
We have some very similarly named command-line options:
arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
__setup() is designed to match options that take arguments, like
"foo=bar" where you would have:
__setup("foo", x86_foo_func...);
The problem is that "noxsave" actually _matches_ "noxsaves" in
the same way that "foo" matches "foo=bar". If you boot an old
kernel that does not know about "noxsaves" with "noxsaves" on the
command line, it will interpret the argument as "noxsave", which
is not what you want at all.
This makes the "noxsave" handler only return success when it finds
an *exact* match.
[ tglx: We really need to make __setup() more robust. ]
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Sun, 23 Nov 2014 02:00:33 +0000 (18:00 -0800)]
x86_64, traps: Rework bad_iret
commit
b645af2d5905c4e32399005b867987919cbfc3ae upstream.
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Sun, 23 Nov 2014 02:00:32 +0000 (18:00 -0800)]
x86_64, traps: Stop using IST for #SS
commit
6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.
On a 32-bit kernel, this has no effect, since there are no IST stacks.
On a 64-bit kernel, #SS can only happen in user code, on a failed iret
to user space, a canonical violation on access via RSP or RBP, or a
genuine stack segment violation in 32-bit kernel code. The first two
cases don't need IST, and the latter two cases are unlikely fatal bugs,
and promoting them to double faults would be fine.
This fixes a bug in which the espfix64 code mishandles a stack segment
violation.
This saves 4k of memory per CPU and a tiny bit of code.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Sun, 23 Nov 2014 02:00:31 +0000 (18:00 -0800)]
x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C
commit
af726f21ed8af2cdaa4e93098dc211521218ae65 upstream.
There's nothing special enough about the espfix64 double fault fixup to
justify writing it in assembly. Move it to C.
This also fixes a bug: if the double fault came from an IST stack, the
old asm code would return to a partially uninitialized stack frame.
Fixes:
3891a04aafd668686239349ea58f3314ea2af86b
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaro Koskinen [Wed, 19 Nov 2014 23:05:38 +0000 (01:05 +0200)]
MIPS: Loongson: Make platform serial setup always built-in.
commit
26927f76499849e095714452b8a4e09350f6a3b9 upstream.
If SERIAL_8250 is compiled as a module, the platform specific setup
for Loongson will be a module too, and it will not work very well.
At least on Loongson 3 it will trigger a build failure,
since loongson_sysconf is not exported to modules.
Fix by making the platform specific serial code always built-in.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reported-by: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/8533/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaro Koskinen [Fri, 17 Oct 2014 15:10:24 +0000 (18:10 +0300)]
MIPS: oprofile: Fix backtrace on 64-bit kernel
commit
bbaf113a481b6ce32444c125807ad3618643ce57 upstream.
Fix incorrect cast that always results in wrong address for the new
frame on 64-bit kernels.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8110/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pop Alexandru Radu [Sat, 7 Apr 2018 08:22:02 +0000 (11:22 +0300)]
bcmdhd_1_77_nn: Fix android version check
Danny Wood [Fri, 11 Jan 2019 08:00:51 +0000 (08:00 +0000)]
bcmdhd_1_77_nn: Import nougat driver from A510FXXU7CRJ4 and switch to building it for the BCM4343
Danny Wood [Tue, 11 Dec 2018 16:36:51 +0000 (16:36 +0000)]
arm64: regernate lineageos_a3xelte_defconfig
Danny Wood [Tue, 4 Dec 2018 13:02:14 +0000 (13:02 +0000)]
Merge in Samsung changes from A510FXXU7CRJ4
Eric Biggers [Mon, 18 Sep 2017 18:37:23 +0000 (11:37 -0700)]
KEYS: prevent KEYCTL_READ on negative key
commit
37863c43b2c6464f252862bf2e9768264e961678 upstream.
Because keyctl_read_key() looks up the key with no permissions
requested, it may find a negatively instantiated key. If the key is
also possessed, we went ahead and called ->read() on the key. But the
key payload will actually contain the ->reject_error rather than the
normal payload. Thus, the kernel oopses trying to read the
user_key_payload from memory address (int)-ENOKEY = 0x00000000ffffff82.
Fortunately the payload data is stored inline, so it shouldn't be
possible to abuse this as an arbitrary memory read primitive...
Reproducer:
keyctl new_session
keyctl request2 user desc '' @s
keyctl read $(keyctl show | awk '/user: desc/ {print $1}')
It causes a crash like the following:
BUG: unable to handle kernel paging request at
00000000ffffff92
IP: user_read+0x33/0xa0
PGD
36a54067 P4D
36a54067 PUD 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 211 Comm: keyctl Not tainted 4.14.0-rc1 #337
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
task:
ffff90aa3b74c3c0 task.stack:
ffff9878c0478000
RIP: 0010:user_read+0x33/0xa0
RSP: 0018:
ffff9878c047bee8 EFLAGS:
00010246
RAX:
0000000000000001 RBX:
ffff90aa3d7da340 RCX:
0000000000000017
RDX:
0000000000000000 RSI:
00000000ffffff82 RDI:
ffff90aa3d7da340
RBP:
ffff9878c047bf00 R08:
00000024f95da94f R09:
0000000000000000
R10:
0000000000000001 R11:
0000000000000000 R12:
0000000000000000
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000000
FS:
00007f58ece69740(0000) GS:
ffff90aa3e200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000ffffff92 CR3:
0000000036adc001 CR4:
00000000003606f0
Call Trace:
keyctl_read_key+0xac/0xe0
SyS_keyctl+0x99/0x120
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f58ec787bb9
RSP: 002b:
00007ffc8d401678 EFLAGS:
00000206 ORIG_RAX:
00000000000000fa
RAX:
ffffffffffffffda RBX:
00007ffc8d402800 RCX:
00007f58ec787bb9
RDX:
0000000000000000 RSI:
00000000174a63ac RDI:
000000000000000b
RBP:
0000000000000004 R08:
00007ffc8d402809 R09:
0000000000000020
R10:
0000000000000000 R11:
0000000000000206 R12:
00007ffc8d402800
R13:
00007ffc8d4016e0 R14:
0000000000000000 R15:
0000000000000000
Code: e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb e8 a4 b4 ad ff 85 c0 74 09 80 3d b9 4c 96 00 00 74 43 48 8b b3 20 01 00 00 4d 85 ed <0f> b7 5e 10 74 29 4d 85 e4 74 24 4c 39 e3 4c 89 e2 4c 89 ef 48
RIP: user_read+0x33/0xa0 RSP:
ffff9878c047bee8
CR2:
00000000ffffff92
Change-Id: Icb005a3f0f766690ff7303339372c369d2e2ca69
Fixes:
61ea0c0ba904 ("KEYS: Skip key state checks when checking for possession")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Eric Biggers [Thu, 8 Jun 2017 13:48:40 +0000 (14:48 +0100)]
KEYS: fix dereferencing NULL payload with nonzero length
commit
5649645d725c73df4302428ee4e02c869248b4c5 upstream.
sys_add_key() and the KEYCTL_UPDATE operation of sys_keyctl() allowed a
NULL payload with nonzero length to be passed to the key type's
->preparse(), ->instantiate(), and/or ->update() methods. Various key
types including asymmetric, cifs.idmap, cifs.spnego, and pkcs7_test did
not handle this case, allowing an unprivileged user to trivially cause a
NULL pointer dereference (kernel oops) if one of these key types was
present. Fix it by doing the copy_from_user() when 'plen' is nonzero
rather than when '_payload' is non-NULL, causing the syscall to fail
with EFAULT as expected when an invalid buffer is specified.
Change-Id: I1f7328e3f7677cee5b3e5ba3969b5f0f9a9d4927
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Wed, 19 Apr 2017 16:08:20 +0000 (17:08 +0100)]
KEYS: Change the name of the dead type to ".dead" to prevent user access
This fixes CVE-2017-6951.
Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs. Attempting to use it may cause the kernel to crash.
Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().
Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:
commit
c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
Author: David Howells <dhowells@redhat.com>
Date: Tue Sep 16 17:36:06 2014 +0100
KEYS: Remove key_type::match in favour of overriding default by match_preparse
which went in before 3.18-rc1.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org
Eric Biggers [Tue, 6 Feb 2018 21:22:15 +0000 (13:22 -0800)]
KEYS: encrypted: fix buffer overread in valid_master_desc()
commit
794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream
With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer. Fix this by using strncmp() instead of memcmp(). [Also
clean up the code to deduplicate some logic.]
Cc: linux-stable <stable@vger.kernel.org> # 4.4.y
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Jin Qian <jinqian@android.com>
Vladis Dronov [Wed, 2 Aug 2017 17:50:14 +0000 (19:50 +0200)]
xfrm: policy: check policy direction value
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
Change-Id: I7ce3c3cc90e352d854ddb6361730918fe143b6ec
References: https://bugzilla.redhat.com/show_bug.cgi?id=
1474928
Fixes:
80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Cc: <stable@vger.kernel.org> # v2.6.21-rc1
Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Marissa Wall [Fri, 17 Nov 2017 00:56:10 +0000 (16:56 -0800)]
BACKPORT: packet: in packet_do_bind, test fanout with bind_lock held
[ Upstream commit
4971613c1639d8e5f102c4e797c3bf8f83a5a69e ]
Once a socket has po->fanout set, it remains a member of the group
until it is destroyed. The prot_hook must be constant and identical
across sockets in the group.
If fanout_add races with packet_do_bind between the test of po->fanout
and taking the lock, the bind call may make type or dev inconsistent
with that of the fanout group.
Hold po->bind_lock when testing po->fanout to avoid this race.
I had to introduce artificial delay (local_bh_enable) to actually
observe the race.
Bug:
69160446
Fixes:
dc99f600698d ("packet: Add fanout support.")
Change-Id: I899f9b6bcbd1d4b033388ef22c472857574bfc30
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Marissa Wall <marissaw@google.com>
Signed-off-by: Siqi Lin <siqilin@google.com>
Marissa Wall [Thu, 16 Nov 2017 01:46:10 +0000 (17:46 -0800)]
UPSTREAM: packet: fix tp_reserve race in packet_set_ring
[ Upstream commit
c27927e372f0785f3303e8fad94b85945e2c97b7 ]
Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.
This bug was discovered by syzkaller.
Fixes:
8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Bug:
68806121
Change-Id: Ifbceac3542a1b7f25290c3e21008fa76c59fe391
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Marissa Wall <marissaw@google.com>
Willem de Bruijn [Thu, 14 Sep 2017 21:14:41 +0000 (17:14 -0400)]
UPSTREAM: packet: hold bind lock when rebinding to fanout hook
[ Upstream commit
008ba2a13f2d04c947adc536d19debb8fe66f110 ]
Packet socket bind operations must hold the po->bind_lock. This keeps
po->running consistent with whether the socket is actually on a ptype
list to receive packets.
fanout_add unbinds a socket and its packet_rcv/tpacket_rcv call, then
binds the fanout object to receive through packet_rcv_fanout.
Make it hold the po->bind_lock when testing po->running and rebinding.
Else, it can race with other rebind operations, such as that in
packet_set_ring from packet_rcv to tpacket_rcv. Concurrent updates
can result in a socket being added to a fanout group twice, causing
use-after-free KASAN bug reports, among others.
Reported independently by both trinity and syzkaller.
Verified that the syzkaller reproducer passes after this patch.
Bug:
69160446
Fixes:
dc99f600698d ("packet: Add fanout support.")
Change-Id: I6817d1f12654dd682a962cfd4645006a7315360d
Reported-by: nixioaming <nixiaoming@huawei.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Marissa Wall <marissaw@google.com>
Signed-off-by: Siqi Lin <siqilin@google.com>
Eric Dumazet [Tue, 14 Feb 2017 17:03:51 +0000 (09:03 -0800)]
UPSTREAM: packet: fix races in fanout_add()
commit
d199fab63c11998a602205f7ee7ff7c05c97164b upstream.
Multiple threads can call fanout_add() at the same time.
We need to grab fanout_mutex earlier to avoid races that could
lead to one thread freeing po->rollover that was set by another thread.
Do the same in fanout_release(), for peace of mind, and to help us
finding lockdep issues earlier.
[js] no rollover in 3.12
Fixes:
dc99f600698d ("packet: Add fanout support.")
Fixes:
0648ab70afe6 ("packet: rollover prepare: per-socket state")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit
2a272abc4e543f488b3a73292ee75a06f20d077a)
Bug:
37897645
Change-Id: I3b021869ee26b88d10f4d6408ce34d351543ce74
Andrey Konovalov [Wed, 29 Mar 2017 14:11:22 +0000 (16:11 +0200)]
UPSTREAM: net/packet: fix overflow in check for tp_reserve
When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
Fix by checking that tp_reserve <= INT_MAX on assign.
Bug:
36725304
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
bcc5364bdcfe131e6379363f089e7b4108d35b70)
Change-Id: I17af0b50ea5b1caa8349e216b88ef57f5287de3c
Andrey Konovalov [Wed, 29 Mar 2017 14:11:21 +0000 (16:11 +0200)]
UPSTREAM: net/packet: fix overflow in check for tp_frame_nr
When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow.
Add a check that tp_block_size * tp_block_nr <= UINT_MAX.
Since frames_per_block <= tp_block_size, the expression would
never overflow.
Bug:
36725304
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
8f8d28e4d6d815a391285e121c3a53a0b6cb9e7b)
Change-Id: I86e923ec03855dd7c8faaddc861a6211d03f0bc2
Chenbo Feng [Wed, 29 Nov 2017 02:22:11 +0000 (18:22 -0800)]
ANDROID: qtaguid: Fix the UAF probelm with tag_ref_tree
When multiple threads is trying to tag/delete the same socket at the
same time, there is a chance the tag_ref_entry of the target socket to
be null before the uid_tag_data entry is freed. It is caused by the
ctrl_cmd_tag function where it doesn't correctly grab the spinlocks
when tagging a socket.
Signed-off-by: Chenbo Feng <fengc@google.com>
Bug:
65853158
Change-Id: I5d89885918054cf835370a52bff2d693362ac5f0
Git-repo: https://android.googlesource.com/kernel/msm
Git-commit:
a6661da56dc61b67cc65222b71896a775ceb17be
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>
Dan Carpenter [Tue, 2 May 2017 10:58:53 +0000 (13:58 +0300)]
ipx: call ipxitf_put() in ioctl error path
We should call ipxitf_put() if the copy_to_user() fails.
Change-Id: I861de4cc5255c83e45b8d0a2a7e30f0a47bc65cd
Reported-by: 李强 <liqiang6-s@360.cn>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Sun, 5 Feb 2017 07:18:55 +0000 (23:18 -0800)]
BACKPORT: ip6_gre: fix ip6gre_err() invalid reads
Andrey Konovalov reported out of bound accesses in ip6gre_err()
If GRE flags contains GRE_KEY, the following expression
*(((__be32 *)p) + (grehlen / 4) - 1)
accesses data ~40 bytes after the expected point, since
grehlen includes the size of IPv6 headers.
Let's use a "struct gre_base_hdr *greh" pointer to make this
code more readable.
p[1] becomes greh->protocol.
grhlen is the GRE header length.
Fixes:
c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Roberto Pereira <rpere@google.com>
(cherry picked from commit
7892032cfe67f4bde6fc2ee967e45a8fbaf33756)
Bug:
37871211
Change-Id: I839afd0948805b98e1aa6cbaca56f2e443f303af
Greg Kroah-Hartman [Fri, 27 Jul 2018 10:26:55 +0000 (12:26 +0200)]
tcp: detect malicious patterns in tcp_collapse_ofo_queue()
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit
3d4bf93ac12003f9b8e1e2de37fe27983deebdcf ]
In case an attacker feeds tiny packets completely out of order,
tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
expensive copies, but not changing socket memory usage at all.
1) Do not attempt to collapse tiny skbs.
2) Add logic to exit early when too many tiny skbs are detected.
We prefer not doing aggressive collapsing (which copies packets)
for pathological flows, and revert to tcp_prune_ofo_queue() which
will be less expensive.
In the future, we might add the possibility of terminating flows
that are proven to be malicious.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Wang [Wed, 1 Nov 2017 21:26:25 +0000 (22:26 +0100)]
tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0
commit
499350a5a6e7512d9ed369ed63a4244b6536f4f8 upstream.
When tcp_disconnect() is called, inet_csk_delack_init() sets
icsk->icsk_ack.rcv_mss to 0.
This could potentially cause tcp_recvmsg() => tcp_cleanup_rbuf() =>
__tcp_select_window() call path to have division by 0 issue.
So this patch initializes rcv_mss to TCP_MIN_MSS instead of 0.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Danny Wood [Tue, 4 Dec 2018 11:40:17 +0000 (11:40 +0000)]
Revert "net: increase fragment memory usage limits"
This reverts commit
c2a936600f78aea00d3312ea4b66a79a4619f9b4.
Paul Lawrence [Wed, 18 Oct 2017 16:20:15 +0000 (09:20 -0700)]
iovec: make sure the caller actually wants anything in memcpy_fromiovecend
Based on upstream change
06ebb06d49486676272a3c030bfeef4bd969a8e6
One more instance when the caller requests 0 bytes instead of running
off and dereferencing potentially invalid iovecs.
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug:
36279469
Change-Id: Ib8d529e17c07c77357ab70bd6a2d7e305d6b27f0
Florian Westphal [Mon, 19 Feb 2018 00:24:15 +0000 (01:24 +0100)]
netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets
commit
b71812168571fa55e44cdd0254471331b9c4c4c6 upstream.
We need to make sure the offsets are not out of range of the
total size.
Also check that they are in ascending order.
The WARN_ON triggered by syzkaller (it sets panic_on_warn) is
changed to also bail out, no point in continuing parsing.
Briefly tested with simple ruleset of
-A INPUT --limit 1/s' --log
plus jump to custom chains using 32bit ebtables binary.
Reported-by: <syzbot+845a53d13171abf8bf29@syzkaller.appspotmail.com>
Bug:
77902350
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I01c7b86ed219c461113208c575148fe84f96317a
Marissa Wall [Mon, 9 Oct 2017 16:37:32 +0000 (09:37 -0700)]
BACKPORT: Sanitize 'move_pages()' permission checks
The 'move_paghes()' system call was introduced long long ago with the
same permission checks as for sending a signal (except using
CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
That turns out to not be a great choice - while the system call really
only moves physical page allocations around (and you need other
capabilities to do a lot of it), you can check the return value to map
out some the virtual address choices and defeat ASLR of a binary that
still shares your uid.
So change the access checks to the more common 'ptrace_may_access()'
model instead.
This tightens the access checks for the uid, and also effectively
changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
anybody really _uses_ this legacy system call any more (we hav ebetter
NUMA placement models these days), so I expect nobody to notice.
Famous last words.
Reported-by: Otto Ebeling <otto.ebeling@iki.fi>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@kernel.org
Bug:
65468230
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cherry-picked from:
197e7e521384a23b9e585178f3f11c9fa08274b9
This branch does not have the PTRACE_MODE_REALCREDS flag but its
default behavior is the same as PTRACE_MODE_REALCREDS. So use
PTRACE_MODE_READ instead of PTRACE_MODE_READ_REALCREDS.
Change-Id: I75364561d91155c01f78dd62cdd41c5f0f418854
Chris Fries [Fri, 28 Apr 2017 04:29:40 +0000 (23:29 -0500)]
ANDROID: lib: vsprintf: Add "%paP" option
Add %paP for physical address that need to always be shown, regardless
of kptr restrictions.
Bug:
37723342
Bug:
30368199
Change-Id: I4884854d9465be89f366d4d7b56c825918b91599
Signed-off-by: Chris Fries <cfries@google.com>
Dave Weinstein [Thu, 12 Jan 2017 00:27:59 +0000 (16:27 -0800)]
ANDROID: lib: vsprintf: default kptr_restrict to the maximum value
Set the initial value of kptr_restrict to the maximum
setting rather than the minimum setting, to ensure that
early boot logging is not leaking information.
BUG:
30368199
Change-Id: If738e3b2ff85b737127daf16f2f3a722e616f389
Signed-off-by: Dave Weinstein <olorin@google.com>
Dave Weinstein [Thu, 12 Jan 2017 00:13:09 +0000 (16:13 -0800)]
ANDROID: lib: vsprintf: physical address kernel pointer filtering options
Add the kptr_restrict setting of 4 which results in %pa and
%p[rR] values being replaced by zeros.
BUG:
30368199
Change-Id: I2cfac7cd0d9c05dbad07c683fac79aea8c2ba59d
Signed-off-by: Dave Weinstein <olorin@google.com>
Dave Weinstein [Wed, 11 Jan 2017 23:39:07 +0000 (15:39 -0800)]
ANDROID: lib: vsprintf: additional kernel pointer filtering options
Add the kptr_restrict setting of 3 which results in both
%p and %pK values being replaced by zeros.
Add an additional %pP value inspired by the Grsecurity
option which explicitly whitelists pointers for output.
This patch is based on work by William Roberts
<william.c.roberts@intel.com>
BUG:
30368199
Change-Id: Ic5cef86617f7758514271edd67199683d2c4e2bb
Signed-off-by: Dave Weinstein <olorin@google.com>
Eric Biggers [Fri, 8 Dec 2017 15:13:27 +0000 (15:13 +0000)]
BACKPORT: ASN.1: fix out-of-bounds read when parsing indefinite length item
In asn1_ber_decoder(), indefinitely-sized ASN.1 items were being passed
to the action functions before their lengths had been computed, using
the bogus length of 0x80 (ASN1_INDEFINITE_LENGTH). This resulted in
reading data past the end of the input buffer, when given a specially
crafted message.
Fix it by rearranging the code so that the indefinite length is resolved
before the action is called.
This bug was originally found by fuzzing the X.509 parser in userspace
using libFuzzer from the LLVM project.
KASAN report (cleaned up slightly):
BUG: KASAN: slab-out-of-bounds in memcpy ./include/linux/string.h:341 [inline]
BUG: KASAN: slab-out-of-bounds in x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
Read of size 128 at addr
ffff880035dd9eaf by task keyctl/195
CPU: 1 PID: 195 Comm: keyctl Not tainted
4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xd1/0x175 lib/dump_stack.c:53
print_address_description+0x78/0x260 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x23f/0x350 mm/kasan/report.c:409
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy ./include/linux/string.h:341 [inline]
x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
asn1_ber_decoder+0xb4a/0x1fd0 lib/asn1_decoder.c:447
x509_cert_parse+0x1c7/0x620 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 195:
__do_kmalloc_node mm/slab.c:3675 [inline]
__kmalloc_node+0x47/0x60 mm/slab.c:3682
kvmalloc ./include/linux/mm.h:540 [inline]
SYSC_add_key security/keys/keyctl.c:104 [inline]
SyS_add_key+0x19e/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes:
42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Reported-by: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit
e0058f3a874ebb48b25be7ff79bc3b4e59929f90)
Bug:
73827422
Change-Id: Ib1278bd75b3be8e41b2ab0dc3a750d52006acc4b
Signed-off-by: Connor O'Brien <connoro@google.com>
Eric Biggers [Thu, 2 Nov 2017 00:47:19 +0000 (00:47 +0000)]
UPSTREAM: KEYS: fix out-of-bounds read during ASN.1 parsing
syzkaller with KASAN reported an out-of-bounds read in
asn1_ber_decoder(). It can be reproduced by the following command,
assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y:
keyctl add asymmetric desc $'\x30\x30' @s
The bug is that the length of an ASN.1 data value isn't validated in the
case where it is encoded using the short form, causing the decoder to
read past the end of the input buffer. Fix it by validating the length.
The bug report was:
BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
Read of size 1 at addr
ffff88003cccfa02 by task syz-executor0/6818
CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted
4.14.0-rc7-00008-g5f479447d983 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xb3/0x10b lib/dump_stack.c:52
print_address_description+0x79/0x2a0 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x236/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x347/0xb20 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x447c89
RSP: 002b:
00007fca7a5d3bd8 EFLAGS:
00000246 ORIG_RAX:
00000000000000f8
RAX:
ffffffffffffffda RBX:
00007fca7a5d46cc RCX:
0000000000447c89
RDX:
0000000020006f4a RSI:
0000000020006000 RDI:
0000000020001ff5
RBP:
0000000000000046 R08:
fffffffffffffffd R09:
0000000000000000
R10:
0000000000000002 R11:
0000000000000246 R12:
0000000000000000
R13:
0000000000000000 R14:
00007fca7a5d49c0 R15:
00007fca7a5d4700
Fixes:
42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
(cherry picked from commit
2eb9eabf1e868fda15808954fb29b0f105ed65f1)
Bug:
73827422
Change-Id: I3c57fd16ebc63214c4225e85004b1339fbc41728
Signed-off-by: Connor O'Brien <connoro@google.com>
Ben Hutchings [Wed, 28 Feb 2018 15:20:22 +0000 (15:20 +0000)]
futex: Prevent overflow by strengthen input validation
3.2.100-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Li Jinyue <lijinyue@huawei.com>
commit
fbe0e839d1e22d88810f3ee3e2f1479be4c0aa4a upstream.
UBSAN reports signed integer overflow in kernel/futex.c:
UBSAN: Undefined behaviour in kernel/futex.c:2041:18
signed integer overflow:
0 - -
2147483648 cannot be represented in type 'int'
Add a sanity check to catch negative values of nr_wake and nr_requeue.
Signed-off-by: Li Jinyue <lijinyue@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: dvhart@infradead.org
Link: https://lkml.kernel.org/r/1513242294-31786-1-git-send-email-lijinyue@huawei.com
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Johan Hovold [Wed, 4 Oct 2017 09:01:13 +0000 (11:01 +0200)]
UPSTREAM: USB: serial: console: fix use-after-free after failed setup
commit
299d7572e46f98534033a9e65973f13ad1ce9047
Make sure to reset the USB-console port pointer when console setup fails
in order to avoid having the struct usb_serial be prematurely freed by
the console code when the device is later disconnected.
Bug:
69050921
Change-Id: I46e86fddd10611a30e7f4ab62ba07dc6eccc0312
Fixes:
73e487fdb75f ("[PATCH] USB console: fix disconnection issues")
Cc: stable <stable@vger.kernel.org> # 2.6.18
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Jerry Zhang [Tue, 26 Sep 2017 01:14:51 +0000 (18:14 -0700)]
ANDROID: usb: gadget: f_mtp: Return error if count is negative
If the user passes in a negative file size in a int64,
this will compare to be smaller than buffer length,
and it will get truncated to form a read length that
is larger than the buffer length.
To fix, return -EINVAL if the count argument is negative,
so the loop will never happen.
Bug:
37429972
Test: Test with PoC
Change-Id: I5d52e38e6fbe2c17eb8c493f9eb81df6cfd780a4
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Greg Kroah-Hartman [Tue, 19 Sep 2017 13:07:17 +0000 (15:07 +0200)]
UPSTREAM: USB: fix out-of-bounds in usb_set_configuration
commit
bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb
Andrey Konovalov reported a possible out-of-bounds problem for a USB interface
association descriptor. He writes:
It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION
descriptor. It's only checked that the size is >= 2 in
usb_parse_configuration(), so find_iad() might do out-of-bounds access
to intf_assoc->bInterfaceCount.
And he's right, we don't check for crazy descriptors of this type very well, so
resolve this problem. Yet another issue found by syzkaller...
Bug:
69052055
Change-Id: I2cc3b5a66d16abd0fc567d69457fc90a45eb12d8
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Wed, 18 Oct 2017 16:49:38 +0000 (12:49 -0400)]
UPSTREAM: USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()
commit
1c0edc3633b56000e18d82fc241e3995ca18a69e
Andrey used the syzkaller fuzzer to find an out-of-bounds memory
access in usb_get_bos_descriptor(). The code wasn't checking that the
next usb_dev_cap_header structure could fit into the remaining buffer
space.
This patch fixes the error and also reduces the bNumDeviceCaps field
in the header to match the actual number of capabilities found, in
cases where there are fewer than expected.
Bug:
69052675
Change-Id: Ica990541695ce5ba46ca8d2bd01e8230dcf5dcd4
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Viktor Slavkovic [Mon, 2 Oct 2017 17:26:45 +0000 (10:26 -0700)]
staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl
A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a
race condition when mmap is called. After the !asma->file check, before
setting asma->size, asma->file can be set in mmap. That would result in
having different asma->size than the mapped memory size. Combined with
ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory
corruption.
Bug:
66954097
Signed-off-by: Viktor Slavkovic <viktors@google.com>
Change-Id: Ia52312a75ade30bc94be6b94420f17f34e0c1f86
CVE-2017-13216
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
(cherry picked from commit
b150b0606691a89adfd4729238a1c92b8011a207)
Dmitry Torokhov [Tue, 24 Oct 2017 16:39:43 +0000 (09:39 -0700)]
Input: gtco - fix potential out-of-bound access
On Tue, Oct 24, 2017 at 01:04:03PM +0200, Andrey Konovalov wrote:
> On Tue, Oct 24, 2017 at 7:28 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > parse_hid_report_descriptor() has a while (i < length) loop, which
> > only guarantees that there's at least 1 byte in the buffer, but the
> > loop body can read multiple bytes which causes out-of-bounds access.
> >
> > Reported-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/input/tablet/gtco.c | 24 +++++++++++++++++-------
> > 1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
> > index
b796e891e2ee..
0351203b8c24 100644
> > --- a/drivers/input/tablet/gtco.c
> > +++ b/drivers/input/tablet/gtco.c
> > @@ -230,13 +230,24 @@ static void parse_hid_report_descriptor(struct gtco *device, char * report,
> >
> > /* Walk this report and pull out the info we need */
> > while (i < length) {
> > - prefix = report[i];
> > -
> > - /* Skip over prefix */
> > - i++;
> > + prefix = report[i++];
> >
> > /* Determine data size and save the data in the proper variable */
> > - size = PREF_SIZE(prefix);
> > + if (PREF_SIZE(prefix) < 1) {
>
> AFAIU PREF_SIZE(prefix) == 0 is a perfectly valid item data size.
Fair enough. How about the below instead then?
Greg Kroah-Hartman [Mon, 29 Jan 2018 12:57:05 +0000 (13:57 +0100)]
ipv6: fix udpv6 sendmsg crash caused by too small MTU
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Maloney <maloney@google.com>
[ Upstream commit
749439bfac6e1a2932c582e2699f91d329658196 ]
The logic in __ip6_append_data() assumes that the MTU is at least large
enough for the headers. A device's MTU may be adjusted after being
added while sendmsg() is processing data, resulting in
__ip6_append_data() seeing any MTU. For an mtu smaller than the size of
the fragmentation header, the math results in a negative 'maxfraglen',
which causes problems when refragmenting any previous skb in the
skb_write_queue, leaving it possibly malformed.
Instead sendmsg returns EINVAL when the mtu is calculated to be less
than IPV6_MIN_MTU.
Found by syzkaller:
kernel BUG at ./include/linux/skbuff.h:2064!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 14216 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task:
ffff8801d0b68580 task.stack:
ffff8801ac6b8000
RIP: 0010:__skb_pull include/linux/skbuff.h:2064 [inline]
RIP: 0010:__ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617
RSP: 0018:
ffff8801ac6bf570 EFLAGS:
00010216
RAX:
0000000000010000 RBX:
0000000000000028 RCX:
ffffc90003cce000
RDX:
00000000000001b8 RSI:
ffffffff839df06f RDI:
ffff8801d9478ca0
RBP:
ffff8801ac6bf780 R08:
ffff8801cc3f1dbc R09:
0000000000000000
R10:
ffff8801ac6bf7a0 R11:
43cb4b7b1948a9e7 R12:
ffff8801cc3f1dc8
R13:
ffff8801cc3f1d40 R14:
0000000000001036 R15:
dffffc0000000000
FS:
00007f43d740c700(0000) GS:
ffff8801dc100000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f7834984000 CR3:
00000001d79b9000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
ip6_finish_skb include/net/ipv6.h:911 [inline]
udp_v6_push_pending_frames+0x255/0x390 net/ipv6/udp.c:1093
udpv6_sendmsg+0x280d/0x31a0 net/ipv6/udp.c:1363
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x352/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4512e9
RSP: 002b:
00007f43d740bc08 EFLAGS:
00000216 ORIG_RAX:
000000000000002c
RAX:
ffffffffffffffda RBX:
00000000007180a8 RCX:
00000000004512e9
RDX:
000000000000002e RSI:
0000000020d08000 RDI:
0000000000000005
RBP:
0000000000000086 R08:
00000000209c1000 R09:
000000000000001c
R10:
0000000000040800 R11:
0000000000000216 R12:
00000000004b9c69
R13:
00000000ffffffff R14:
0000000000000005 R15:
00000000202c2000
Code: 9e 01 fe e9 c5 e8 ff ff e8 7f 9e 01 fe e9 4a ea ff ff 48 89 f7 e8 52 9e 01 fe e9 aa eb ff ff e8 a8 b6 cf fd 0f 0b e8 a1 b6 cf fd <0f> 0b 49 8d 45 78 4d 8d 45 7c 48 89 85 78 fe ff ff 49 8d 85 ba
RIP: __skb_pull include/linux/skbuff.h:2064 [inline] RSP:
ffff8801ac6bf570
RIP: __ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP:
ffff8801ac6bf570
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Mike Maloney <maloney@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Potapenko [Wed, 3 May 2017 15:06:58 +0000 (17:06 +0200)]
ipv4, ipv6: ensure raw socket message is big enough to hold an IP header
raw_send_hdrinc() and rawv6_send_hdrinc() expect that the buffer copied
from the userspace contains the IPv4/IPv6 header, so if too few bytes are
copied, parts of the header may remain uninitialized.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <glider@google.com>
Greg Kroah-Hartman [Wed, 22 Nov 2017 10:12:04 +0000 (11:12 +0100)]
sctp: do not peel off an assoc from one netns to another one
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <lucien.xin@gmail.com>
[ Upstream commit
df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ]
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
socket$inet6_sctp()
bind$inet6()
sendto$inet6()
unshare(0x40000000)
getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <chunwang@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Hackmann [Wed, 4 Oct 2017 16:31:34 +0000 (09:31 -0700)]
arm64: issue isb when trapping CNTVCT_EL0 access
Change-Id: I6005a6e944494257bfc2243fde2f7a09c3fd76c6
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
projects / GitHub / LineageOS / android_kernel_samsung_universal7580.git / log