14 Oct, 2013
40 commits
-
commit bf5430360ebe4b2d0c51d91f782e649107b502eb upstream.
We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.Signed-off-by: Johan Hedberg
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit 5e130367d43ff22836bbae380d197d600fe8ddbb upstream.
This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.Signed-off-by: Johan Hedberg
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.
Yet another vendor specific ID for this chipset; this one for the ASUS
USB-BT400 Bluetooth 4.0 adapter.T: Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0b05 ProdID=17cb Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=000272C64400
C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)Signed-off-by: Raphael Kubo da Costa
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.
usb device info:
T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e005 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1msSigned-off-by: Peng Chen
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit 89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream.
This patch fixes the connection encryption key size information when
the host is playing the peripheral role. We should set conn->enc_key_
size in hci_le_ltk_request_evt, otherwise it is left uninitialized.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream.
While playing the peripheral role, the host gets a LE Long Term Key
Request Event from the controller when a connection is established
with a bonded device. The host then informs the LTK which should be
used for the connection. Once the link is encrypted, the host gets
an Encryption Change Event.Therefore we should set conn->pending_sec_level instead of conn->
sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
properly updated in hci_encrypt_change_evt.Moreover, since we have a LTK associated to the device, we have at
least BT_SECURITY_MEDIUM security level.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo Padovan
Signed-off-by: Greg Kroah-Hartman -
commit db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream.
The driver uses platform_driver_probe() to obtain platform data
if any. However, that function is placed in the .init section so
it must be called upon driver module initialization.The problem was reported by Fenguang Wu resulting in a kernel
oops because the .init section was already freed.[ 48.966342] Switched to clocksource tsc
[ 48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
[ 48.970957] IP: [] classes_init+0x26/0x26
[ 48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
[ 48.970957] Oops: 0011 [#1]
[ 48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
[ 48.970957] Workqueue: events brcmf_driver_init
[ 48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
[ 48.970957] RIP: 0010:[] [] classes_init+0x26/0x26
[ 48.970957] RSP: 0000:ffff8800001d5d40 EFLAGS: 00000286
[ 48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
[ 48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
[ 48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
[ 48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
[ 48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
[ 48.970957] FS: 0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
[ 48.970957] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
[ 48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
[ 48.970957] Stack:
[ 48.970957] ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
[ 48.970957] ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
[ 48.970957] 0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
[ 48.970957] Call Trace:
[ 48.970957] [] ? brcmf_sdio_init+0x18/0x70
[ 48.970957] [] brcmf_driver_init+0x9/0x10
[ 48.970957] [] process_one_work+0x1d5/0x480
[ 48.970957] [] ? process_one_work+0x178/0x480
[ 48.970957] [] worker_thread+0x118/0x3a0
[ 48.970957] [] ? process_one_work+0x480/0x480
[ 48.970957] [] kthread+0xe7/0xf0
[ 48.970957] [] ? finish_task_switch.constprop.57+0x37/0xd0
[ 48.970957] [] ? __kthread_parkme+0x80/0x80
[ 48.970957] [] ret_from_fork+0x7a/0xb0
[ 48.970957] [] ? __kthread_parkme+0x80/0x80
[ 48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ 48.970957] RIP [] classes_init+0x26/0x26
[ 48.970957] RSP
[ 48.970957] CR2: ffffffff82196446
[ 48.970957] ---[ end trace 62980817cd525f14 ]---Reported-by: Fengguang Wu
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Tested-by: Fengguang Wu
Signed-off-by: Arend van Spriel
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 0ab08f576b9e6a6b689fc6b4e632079b978e619b upstream.
A former patch introducing FUSE_I_SIZE_UNSTABLE flag provided detailed
description of races between ftruncate and anyone who can extend i_size:> 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size
> changed (due to our own fuse_do_setattr()) and is going to call
> truncate_pagecache() for some 'new_size' it believes valid right now. But by
> the time that particular truncate_pagecache() is called ...
> 2. fuse_do_setattr() returns (either having called truncate_pagecache() or
> not -- it doesn't matter).
> 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
> 4. mmap-ed write makes a page in the extended region dirty.This patch adds necessary bits to fuse_file_fallocate() to protect from that
race.Signed-off-by: Maxim Patlasov
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit bde52788bdb755b9e4b75db6c434f30e32a0ca0b upstream.
The patch fixes a race between mmap-ed write and fallocate(PUNCH_HOLE):
1) An user makes a page dirty via mmap-ed write.
2) The user performs fallocate(2) with mode == PUNCH_HOLE|KEEP_SIZE
and covering the page.
3) Before truncate_pagecache_range call from fuse_file_fallocate,
the page goes to write-back. The page is fully processed by fuse_writepage
(including end_page_writeback on the page), but fuse_flush_writepages did
nothing because fi->writectr < 0.
4) truncate_pagecache_range is called and fuse_file_fallocate is finishing
by calling fuse_release_nowrite. The latter triggers processing queued
write-back request which will write stale data to the hole soon.Changed in v2 (thanks to Brian for suggestion):
- Do not truncate page cache until FUSE_FALLOCATE succeeded. Otherwise,
we can end up in returning -ENOTSUPP while user data is already punched
from page cache. Use filemap_write_and_wait_range() instead.
Changed in v3 (thanks to Miklos for suggestion):
- fuse_wait_on_writeback() is prone to livelocks; use fuse_set_nowrite()
instead. So far as we need a dirty-page barrier only, fuse_sync_writes()
should be enough.
- rebased to for-linus branch of fuse.gitSigned-off-by: Maxim Patlasov
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.
The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.This commit therefore restores these register on error exit from the loop.
Signed-off-by: Paul E. McKenney
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.
arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violationSigned-off-by: Madhavan Srinivasan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream.
The csum_partial_copy_generic() uses register r7 to adjust the remaining
bytes to process. Unfortunately, r7 also holds a parameter, namely the
address of the flag to set in case of access exceptions while reading
the source buffer. Lacking a quantum implementation of PowerPC, this
commit instead uses register r9 to do the adjusting, leaving r7's
pointer uncorrupted.Signed-off-by: Paul E. McKenney
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 upstream.
modalias_show() should return an empty string on error, not -ENODEV.
This causes the following false and annoying error:
> find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such deviceSigned-off-by: Prarit Bhargava
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983 upstream.
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit a53b27b3abeef406de92a2bb0ceb6fb4c3fb8fc4 upstream.
Commit 4df4899 "Add power8 EBB support" included a bug in the handling
of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
however we were then or'ing that value directly into MMCR1.This meant we were failing to set the FAB fields correctly, and also
potentially corrupting the value for PMC4SEL. Leading to no counts for
the FAB events and incorrect counts for PMC4.The fix is simply to shift left the FAB value correctly before or'ing it
with MMCR1.Reported-by: Sooraj Ravindran Nair
Signed-off-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 1cf389df090194a0976dc867b7fffe99d9d490cb upstream.
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.With this change under the same conditions, we have not been able to
reproduce the panic.Signed-off-by: Nishanth Aravamudan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit d63733aed90b432e5cc489ddfa28e342f91b4652 upstream.
If the user passes an invalid value it leads to an info leak when we
print the error message or it could oops. This is called with user
supplied data from snd_ctl_elem_write().Signed-off-by: Dan Carpenter
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d967967e8d1116fb38bad25e58714b5dddd03cca upstream.
This is called from snd_ctl_elem_write() with user supplied data so we
need to add some bounds checking.Signed-off-by: Dan Carpenter
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit f8d7b13e14357ed19d2ca2799539600418dc3939 upstream.
The ->put() function are called from snd_ctl_elem_write() with user
supplied data. The limit checks here could underflow leading to a
crash.Signed-off-by: Dan Carpenter
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit fac7fa162a19100298d5d91359960037dc5bfca9 upstream.
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.Acked-by: Stephen Warren
Tested-by: George Cherian
Tested-by: Aaro Koskinen
Tested-by: Lars Poeschel
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Acked-by: Santosh Shilimkar
Acked-by: Tony Lindgren
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit fa365e4d729065b5e85165df3dc9699ed47489cc upstream.
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.Acked-by: Stephen Warren
Tested-by: George Cherian
Tested-by: Aaro Koskinen
Tested-by: Lars Poeschel
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Acked-by: Santosh Shilimkar
Acked-by: Tony Lindgren
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 72023656961b8c81a168a7a6762d589339d0d7ec upstream.
A high setting of max_map_count, and a process core-dumping with a large
enough vm_map_count could result in an NT_FILE note not being written,
and the kernel crashing immediately later because it has assumed
otherwise.Reproduction of the oops-causing bug described here:
https://lkml.org/lkml/2013/8/30/50
Rge ussue originated in commit 2aa362c49c31 ("coredump: extend core dump
note section to contain file names of mapped file") from Oct 4, 2012.This patch make that section optional in that case. fill_files_note()
should signify the error, and also let the info struct in
elf_core_dump() be zero-initialized so that we can check for the
optionally written note.[akpm@linux-foundation.org: avoid abusing E2BIG, remove a couple of not-really-needed local variables]
[akpm@linux-foundation.org: fix sparse warning]
Signed-off-by: Dan Aloni
Cc: Al Viro
Cc: Denys Vlasenko
Reported-by: Martin MOKREJS
Tested-by: Martin MOKREJS
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1b0135b5e20c56b2edae29e92b91c0b12c983432 upstream.
Since commit 01426478df3a8791ff5c8b6b82d409e699cfaf38
(avr32: Use generic idle loop) the kernel throws the
following warning on avr32:WARNING: at 900322e4 [verbose debug info unavailable]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc2 #117
task: 901c3ecc ti: 901c0000 task.ti: 901c0000
PC is at cpu_idle_poll_ctrl+0x1c/0x38
LR is at comparator_mode+0x3e/0x40
pc : [] lr : [] Not tainted
sp : 901c1f74 r12: 00000000 r11: 901c74a0
r10: 901d2510 r9 : 00000001 r8 : 901db4de
r7 : 901c74a0 r6 : 00000001 r5 : 00410020 r4 : 901db574
r3 : 00410024 r2 : 90206fe0 r1 : 00000000 r0 : 007f0000
Flags: qvnzc
Mode bits: hjmde....G
CPU Mode: Supervisor
Call trace:
[] clockevents_set_mode+0x16/0x2e
[] clockevents_shutdown+0xa/0x1e
[] clockevents_exchange_device+0x58/0x70
[] tick_check_new_device+0x38/0x54
[] clockevents_register_device+0x32/0x90
[] time_init+0xa8/0x108
[] start_kernel+0x128/0x23cWhen the 'avr32_comparator' clockevent device is registered,
the clockevent core sets the mode of that clockevent device
to CLOCK_EVT_MODE_SHUTDOWN. Due to this, the 'comparator_mode'
function calls the 'cpu_idle_poll_ctrl' to disables idle poll.
This results in the aforementioned warning because the polling
is not enabled yet.Change the code to only disable idle poll if it is enabled by
the same function to avoid the warning.Signed-off-by: Gabor Juhos
Acked-by: Hans-Christian Egtvedt
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit bb8140947a247b9aa15652cc24dc555ebb0b64b0 ]
rtnl ops where introduced by c075b13098b3 ("ip6tnl: advertise tunnel param via
rtnl"), but I forget to assign rtnl ops to fb tunnels.Now that it is done, we must remove the explicit call to
unregister_netdevice_queue(), because the fallback tunnel is added to the queue
in ip6_tnl_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
is valid since commit 0bd8762824e7 ("ip6tnl: add x-netns support")).Signed-off-by: Nicolas Dichtel
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 205983c43700ac3a81e7625273a3fa83cd2759b5 ]
rtnl ops where introduced by ba3e3f50a0e5 ("sit: advertise tunnel param via
rtnl"), but I forget to assign rtnl ops to fb tunnels.Now that it is done, we must remove the explicit call to
unregister_netdevice_queue(), because the fallback tunnel is added to the queue
in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
is valid since commit 5e6700b3bf98 ("sit: add support of x-netns")).Signed-off-by: Nicolas Dichtel
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3e08f4a72f689c6296d336c2aab4bddd60c93ae2 ]
We might extend the used aera of a skb beyond the total
headroom when we install the ipip header. Fix this by
calling skb_cow_head() unconditionally.Bug was introduced with commit c544193214
("GRE: Refactor GRE tunneling code.")Cc: Pravin Shelar
Signed-off-by: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]
The dma descriptors indexes are only initialized on the probe function.
If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.So an interface could be left in an usable state after ifdow/ifup.
This patch makes sure that the descriptors indexes are in a proper
status when the device is open.Signed-off-by: Ricardo Ribalda Delgado
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9260d3e1013701aa814d10c8fc6a9f92bd17d643 ]
It is possible for the timer handlers to run after the call to
ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the
handler function in order to do proper cleanup when the refcnt
reaches 0. Otherwise, the refcnt can reach zero without the
inet6_dev being destroyed and we end up leaking a reference to
the net_device and see messages like the following,unregister_netdevice: waiting for eth0 to become free. Usage count = 1
Tested on linux-3.4.43.
Signed-off-by: Salam Noureddine
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ]
It is possible for the timer handlers to run after the call to
ip_mc_down so use in_dev_put instead of __in_dev_put in the handler
function in order to do proper cleanup when the refcnt reaches 0.
Otherwise, the refcnt can reach zero without the in_device being
destroyed and we end up leaking a reference to the net_device and
see messages like the following,unregister_netdevice: waiting for eth0 to become free. Usage count = 1
Tested on linux-3.4.43.
Signed-off-by: Salam Noureddine
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3da812d860755925da890e8c713f2d2e2d7b1bae ]
gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header,
so initialize max_headroom to zero. Otherwise theif (encap_limit >= 0) {
max_headroom += 8;
mtu -= 8;
}increments an uninitialized variable before max_headroom was reset.
Found with coverity: 728539
Cc: Dmitry Kozlov
Signed-off-by: Hannes Frederic Sowa
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ]
Recently grabbed this report:
https://bugzilla.redhat.com/show_bug.cgi?id=1005567Of an issue in which the bonding driver, with an attached vlan encountered the
following errors when bond0 was taken down and back up:dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
device might be broken.The error occurs because, during __bond_release_one, if we release our last
slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
notification. With an attached vlan, the vlan may see that the vlan and bond
mac address were in sync, but no longer are. This triggers a call to dev_uc_add
and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when
we complete __bond_release_one, we use the current state of the bond flags to
determine if we should decrement the promiscuity of the releasing slave. But
since the bond changed promiscuity state during the release operation, we
incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
to begin with, causing the above errorFix is pretty simple, just cache the bonding flags at the start of the function
and use those when determining the need to set promiscuity.This is also needed for the ALLMULTI flag
Reported-by: Mark Wu
CC: Jay Vosburgh
CC: Andy Gospodarek
CC: Mark Wu
CC: "David S. Miller"
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ]
Pass-all-multicast is controlled by bit 3 in RX control, not bit 2
(pass undersized frames).Reported-by: Joseph Chang
Signed-off-by: Peter Korsgaard
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9a3bab6b05383f1e4c3716b3615500c51285959e ]
A host might need net_secret[] and never open a single socket.
Problem added in commit aebda156a570782
("net: defer net_secret[] initialization")Based on prior patch from Hannes Frederic Sowa.
Reported-by: Hannes Frederic Sowa
Signed-off-by: Eric Dumazet
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 7df37ff33dc122f7bd0614d707939fe84322d264 ]
When a router is doing DNAT for 6to4/6rd packets the latest
anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for
6to4 and 6rd") will drop them because the IPv6 address embedded does
not match the IPv4 destination. This patch will allow them to pass by
testing if we have an address that matches on 6to4/6rd interface. I
have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
Also, log the dropped packets (with rate limit).Signed-off-by: Catalin(ux) M. BOIE
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ]
Outgoing packets sent by via-rhine have their VLAN PCP field off by one
(when hardware acceleration is enabled). The TX descriptor expects only VID
and PCP (without a CFI/DEI bit).Peter Boström noticed and reported the bug.
Signed-off-by: Roger Luethi
Cc: Peter Boström
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2811ebac2521ceac84f2bdae402455baa6a7fb47 ]
In the following scenario the socket is corked:
If the first UDP packet is larger then the mtu we try to append it to the
write queue via ip6_ufo_append_data. A following packet, which is smaller
than the mtu would be appended to the already queued up gso-skb via
plain ip6_append_data. This causes random memory corruptions.In ip6_ufo_append_data we also have to be careful to not queue up the
same skb multiple times. So setup the gso frame only when no first skb
is available.This also fixes a shortcoming where we add the current packet's length to
cork->length but return early because of a packet > mtu with dontfrag set
(instead of sutracting it again).Found with trinity.
Cc: YOSHIFUJI Hideaki
Signed-off-by: Hannes Frederic Sowa
Reported-by: Dmitry Vyukov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 ]
If local fragmentation is allowed, then ip_select_ident() and
ip_select_ident_more() need to generate unique IDs to ensure
correct defragmentation on the peer.For example, if IPsec (tunnel mode) has to encrypt large skbs
that have local_df bit set, then all IP fragments that belonged
to different ESP datagrams would have used the same identificator.
If one of these IP fragments would get lost or reordered, then
peer could possibly stitch together wrong IP fragments that did
not belong to the same datagram. This would lead to a packet loss
or data corruption.Signed-off-by: Ansis Atteka
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 749154aa56b57652a282cbde57a57abc278d1205 ]
skb->data already points to IP header, but for the sake of
consistency we can also use ip_hdr() to retrieve it.Signed-off-by: Ansis Atteka
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit bd784a140712fd06674f2240eecfc4ccae421129 ]
DCCP shouldn't be setting sk_err on redirects as it
isn't an error condition. it should be doing exactly
what tcp is doing and leaving the error handler without
touching the socket.Signed-off-by: Duan Jiong
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3f96a532113131d5a65ac9e00fc83cfa31b0295f ]
Adapt the same behaviour for SCTP as present in TCP for ICMP redirect
messages. For IPv6, RFC4443, section 2.4. says:...
(e) An ICMPv6 error message MUST NOT be originated as a result of
receiving the following:
...
(e.2) An ICMPv6 redirect message [IPv6-DISC].
...Therefore, do not report an error to user space, just invoke dst's redirect
callback and leave, same for IPv4 as done in TCP as well. The implication
w/o having this patch could be that the reception of such packets would
generate a poll notification and in worst case it could even tear down the
whole connection. Therefore, stop updating sk_err on redirects.Reported-by: Duan Jiong
Reported-by: Hannes Frederic Sowa
Suggested-by: Vlad Yasevich
Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
