- 09 Dec, 2015 40 commits
-
-
David Hildenbrand authored
commit c5c2c393 upstream. We seemed to have missed a few corner cases in commit f6c137ff ("KVM: s390: randomize sca address"). The SCA has a maximum size of 2112 bytes. By setting the sca_offset to some unlucky numbers, we exceed the page. 0x7c0 (1984) -> Fits exactly 0x7d0 (2000) -> 16 bytes out 0x7e0 (2016) -> 32 bytes out 0x7f0 (2032) -> 48 bytes out One VCPU entry is 32 bytes long. For the last two cases, we actually write data to the other page. 1. The address of the VCPU. 2. Injection/delivery/clearing of SIGP externall calls via SIGP IF. Especially the 2. happens regularly. So this could produce two problems: 1. The guest losing/getting external calls. 2. Random memory overwrites in the host. So this problem happens on every 127 + 128 created VM with 64 VCPUs. Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sebastian Ott authored
commit 7cc8944e upstream. zpci_err_insn writes stale stack content to the debugfs. Ensure that the struct in zpci_err_insn is ordered in a way that we don't have uninitialized holes in it. In addition to that add the packed attribute. Fixes: 3d8258e4 (s390/pci: move debug messages to debugfs) Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit 55a423b6 upstream. git commit 155e839a "s390/kernel: dynamically allocate FP register save area" introduced a regression in regard to ptrace. If the vector register extension is not present or unused the ptrace peek of a floating pointer register return incorrect data and the ptrace poke to a floating pointer register overwrites the task structure starting at task->thread.fpu.fprs. Signed-off-by:
-
Rajkumar Manoharan authored
commit f680f70a upstream. The number of spatial streams that are derived from chain mask for 4x4 devices is using wrong bitmask and conditional check. This is affecting downlink throughput for QCA99x0 devices. Earlier cfg_tx_chainmask is not filled by default until user configured it and so get_nss_from_chainmask never be called. This issue is exposed by recent commit 166de3f1 ("ath10k: remove supported chain mask"). By default maximum supported chain mask is filled in cfg_tx_chainmask. Fixes: 5572a95b ("ath10k: apply chainmask settings to vdev on creation") Signed-off-by:
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Vivek Natarajan authored
commit 72f8cef5 upstream. The current number of spatial streams used by the client is advertised as a separate IE in assoc request. Use this information to set the NSS operating mode. Fixes: 45c9abc0 ("ath10k: implement more versatile set_bitrate_mask"). Signed-off-by:
Vivek Natarajan <nataraja@qti.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
commit 5af82fa6 upstream. This was missed in the original commit adding the flag and ath10k only printed "bit10": ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70.6-2 api 3 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p,bit10 Also add a build test to avoid this happening again. Fixes: ccec9038 ("ath10k: enable raw encap mode and software crypto engine") Signed-off-by:
-
Jonas Gorski authored
commit 11091fb0 upstream. The DEBUG_FS=n #defines for the dbg_show functions were missed when renaming the driver from msm_ to pm8xxx_, causing it to break the build when DEBUG_FS isn't enabled: CC [M] drivers/pinctrl/qcom/pinctrl-ssbi-gpio.o drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c:597:14: error: ‘pm8xxx_gpio_dbg_showâ€
™ undeclared here (not in a function) .dbg_show = pm8xxx_gpio_dbg_show, Fix this by renaming them correctly. Fixes: b4c45fe9 ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers") Signed-off-by:Jonas Gorski <jogo@openwrt.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Masahiro Yamada authored
commit bac7f4c1 upstream. While IECTRL is disabled, input signals are pulled-down internally. If pin-muxing is set up first, glitch signals (Low to High transition) might be input to hardware blocks. Bad case scenario: [1] The hardware block is already running before pinctrl is handled. (the reset is de-asserted by default or by a firmware, for example) [2] The pin-muxing is set up. The input signals to hardware block are pulled-down by the chip-internal biasing. [3] The pins are input-enabled. The signals from the board reach the hardware block. Actually, one invalid character is input to the UART blocks for such SoCs as PH1-LD4, PH1-sLD8, where UART devices start to run at the power on reset. To avoid such problems, pins should be input-enabled before muxing. Fixes: 6e908892 ("pinctrl: UniPhier: add UniPhier pinctrl core support") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by:
Dai Okamura <okamura.dai@socionext.com> Signed-off-by:
-
Mark Rutland authored
commit cb083816 upstream. A kernel built with DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA doesn't have .text aligned to a page boundary, though fixup_executable works at page-granularity thanks to its use of create_mapping. If .text is not page-aligned, the first page it exists in may be marked non-executable, leading to failures when an attempt is made to execute code in said page. This patch upgrades ALIGN_DEBUG_RO and ALIGN_DEBUG_RO_MIN to force page alignment for DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA kernels, ensuring that all sections with specific RWX permission requirements are mapped with the correct permissions. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reported-by:
Jeremy Linton <jeremy.linton@arm.com> Reviewed-by:
Laura Abbott <laura@labbott.name> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Suzuki Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Fixes: da141706 ("arm64: add better page protections to arm64") Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Robin Murphy authored
commit 5accd17d upstream. For reasons not entirely apparent, but now enshrined in history, the architectural mapping of AArch32 banked registers to AArch64 registers actually orders SP_<mode> and LR_<mode> backwards compared to the intuitive r13/r14 order, for all modes except FIQ. Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding subtle bugs with KVM and AArch32 guests. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Mirza Krak authored
commit 7cecd9ab upstream. According to SJA1000 data sheet error-warning (EI) interrupt is not cleared by setting the controller in to reset-mode. Then if we have the following case: - system is suspended (echo mem > /sys/power/state) and SJA1000 is left in operating state - A bus error condition occurs which activates EI interrupt, system is still suspended which means EI interrupt will be not be handled nor cleared. If the above two events occur, on resume there is no way to return the SJA1000 to operating state, except to cycle power to it. By simply reading the IR register on start we will clear any previous conditions that could be present. Signed-off-by:
Mirza Krak <mirza.krak@hostmobility.com> Reported-by:
Christian Magnusson <Christian.Magnusson@semcon.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marek Vasut authored
commit 562b103a upstream. The sizeof() is invoked on an incorrect variable, likely due to some copy-paste error, and this might result in memory corruption. Fix this. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: netdev@vger.kernel.org Signed-off-by:
-
Johan Hedberg authored
commit 8ce783dc upstream. The hci_conn objects don't have a dedicated lock themselves but rely on the caller to hold the hci_dev lock for most types of access. The hci_conn_timeout() function has so far sent certain HCI commands based on the hci_conn state which has been possible without holding the hci_dev lock. The recent changes to do LE scanning before connect attempts added even more operations to hci_conn and hci_dev from hci_conn_timeout, thereby exposing potential race conditions with the hci_dev and hci_conn states. As an example of such a race, here there's a timeout but an l2cap_sock_connect() call manages to race with the cleanup routine: [Oct21 08:14] l2cap_chan_timeout: chan ee4b12c0 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b12c0 state BT_CONNECT [ +0.000002] l2cap_chan_del: chan ee4b12c0, conn f3141580, err 111, state BT_CONNECT [ +0.000002] l2cap_sock_teardown_cb: chan ee4b12c0 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b12c0 orig refcnt 4 [ +0.000010] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000013] l2cap_chan_put: chan ee4b12c0 orig refcnt 3 [ +0.000063] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000049] hci_conn_params_del: addr ee:0d:30:09:53:1f (type 1) [ +0.000002] hci_chan_list_flush: hcon f53d56e0 [ +0.000001] hci_chan_del: hci0 hcon f53d56e0 chan f4e7ccc0 [ +0.004528] l2cap_sock_create: sock e708fc00 [ +0.000023] l2cap_chan_create: chan ee4b1770 [ +0.000001] l2cap_chan_hold: chan ee4b1770 orig refcnt 1 [ +0.000002] l2cap_sock_init: sk ee4b3390 [ +0.000029] l2cap_sock_bind: sk ee4b3390 [ +0.000010] l2cap_sock_setsockopt: sk ee4b3390 [ +0.000037] l2cap_sock_connect: sk ee4b3390 [ +0.000002] l2cap_chan_connect: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f (type 2) psm 0x00 [ +0.000002] hci_get_route: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f [ +0.000001] hci_dev_hold: hci0 orig refcnt 8 [ +0.000003] hci_conn_hold: hcon f53d56e0 orig refcnt 0 Above the l2cap_chan_connect() shouldn't have been able to reach the hci_conn f53d56e0 anymore but since hci_conn_timeout didn't do proper locking that's not the case. The end result is a reference to hci_conn that's not in the conn_hash list, resulting in list corruption when trying to remove it later: [Oct21 08:15] l2cap_chan_timeout: chan ee4b1770 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b1770 state BT_CONNECT [ +0.000003] l2cap_chan_del: chan ee4b1770, conn f3141580, err 111, state BT_CONNECT [ +0.000001] l2cap_sock_teardown_cb: chan ee4b1770 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b1770 orig refcnt 4 [ +0.000002] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000015] l2cap_chan_put: chan ee4b1770 orig refcnt 3 [ +0.000038] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000003] hci_chan_list_flush: hcon f53d56e0 [ +0.000002] hci_conn_hash_del: hci0 hcon f53d56e0 [ +0.000001] ------------[ cut here ]------------ [ +0.000461] WARNING: CPU: 0 PID: 1782 at lib/list_debug.c:56 __list_del_entry+0x3f/0x71() [ +0.000839] list_del corruption, f53d56e0->prev is LIST_POISON2 (00000200) The necessary fix is unfortunately more complicated than just adding hci_dev_lock/unlock calls to the hci_conn_timeout() call path. Particularly, the hci_conn_del() API, which expects the hci_dev lock to be held, performs a cancel_delayed_work_sync(&hcon->disc_work) which would lead to a deadlock if the hci_conn_timeout() call path tries to acquire the same lock. This patch solves the problem by deferring the cleanup work to a separate work callback. To protect against the hci_dev or hci_conn going away meanwhile temporary references are taken with the help of hci_dev_hold() and hci_conn_get(). Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hedberg authored
commit a6ad2a6b upstream. The commit 89cbb063 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by:
-
Dmitry Tunin authored
commit 18e0afab upstream. T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=817b Rev=00.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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1506615Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
Dmitry Tunin authored
commit cd355ff0 upstream. This adapter works with the existing linux-firmware. T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=021c Rev=00.01 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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1502781Signed-off-by:
-
David Herrmann authored
commit 660f0fc0 upstream. The HIDP specs define an idle-timeout which automatically disconnects a device. This has always been implemented in the HIDP layer and forced a synchronous shutdown of the hidp-scheduler. This works just fine, but lacks a forced disconnect on the underlying l2cap channels. This has been broken since: commit 5205185d Author: David Herrmann <dh.herrmann@gmail.com> Date: Sat Apr 6 20:28:47 2013 +0200 Bluetooth: hidp: remove old session-management The old session-management always forced an l2cap error on the ctrl/intr channels when shutting down. The new session-management skips this, as we don't want to enforce channel policy on the caller. In other words, if user-space removes an HIDP device, the underlying channels (which are *owned* and *referenced* by user-space) are still left active. User-space needs to call shutdown(2) or close(2) to release them. Unfortunately, this does not work with idle-timeouts. There is no way to signal user-space that the HIDP layer has been stopped. The API simply does not support any event-passing except for poll(2). Hence, we restore old behavior and force EUNATCH on the sockets if the HIDP layer is disconnected due to idle-timeouts (behavior of explicit disconnects remains unmodified). User-space can still call getsockopt(..., SO_ERROR, ...) ..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can still be re-used (which nobody does so far, though). Therefore, the API still supports the new behavior, but with this patch it's also compatible to the old implicit channel shutdown. Reported-by:
Mark Haun <haunma@keteu.org> Reported-by:
Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 1e6e6328 upstream. This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file was checked to verify that the addition is correct. Reported-by:
Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
-
Dan Carpenter authored
commit 1f9c6e1b upstream. There were several bugs here. 1) The done label was in the wrong place so we didn't copy any information out when there was no command given. 2) We were using PAGE_SIZE as the size of the buffer instead of "PAGE_SIZE - pos". 3) snprintf() returns the number of characters that would have been printed if there were enough space. If there was not enough space (and we had fixed the memory corruption bug #2) then it would result in an information leak when we do simple_read_from_buffer(). I've changed it to use scnprintf() instead. I also removed the initialization at the start of the function, because I thought it made the code a little more clear. Fixes: 5e6e3a92 ('wireless: mwifiex: initial commit for Marvell mwifiex driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Amitkumar Karwar authored
commit 14d9c11c upstream. Preallocated PCIe buffer is being reused for all PCIe interface events. Physical address of the buffer is shared with firmware so that it can perform DMA on it. As event length is specified in the header, there should not be a problem if the buffer gets overwritten. We will save some cycles by avoiding memset everytime while submitting the buffer to firmware. Fixes: 2728cecd(mwifiex: corrections in PCIe event skb) Signed-off-by:
-
Aniket Nagarnaik authored
commit 17e524b1 upstream. This NULL pointer dereference is observed during suspend resume stress test. All pending commands are cancelled when system goes into suspend state. There a corner case in which host may receive response for last scan command after this and try to trigger extra active scan for hidden SSIDs. The issue is fixed by adding a NULL check to skip that extra scan. Fixes: 2375fa2b (mwifiex: fix unable to connect hidden SSID..) Signed-off-by:
Aniket Nagarnaik <aniketn@marvell.com> Signed-off-by:
-
Tony Lindgren authored
commit 75c08f17 upstream. Commit 68bab866 ("mfd: twl6040: Optional clk32k clock handling") added clock handling for the 32k clock from palmas-clk. However, that patch did not consider a typical situation where twl6040 is built-in, and palmas-clk is a loadable module like we have in omap2plus_defconfig. If palmas-clk is not loaded before twl6040 probes, we will get a "clk32k is not handled" warning during booting. This means that any drivers relying on this clock will mysteriously fail, including omap5-uevm WLAN and audio. Note that for WLAN, we probably should also eventually get the clk32kgaudio for MMC3 directly as that's shared between audio and WLAN SDIO at least for omap5-uevm. It seems the WLAN chip cannot get it as otherwise MMC3 won't get properly probed. Fixes: 68bab866 ("mfd: twl6040: Optional clk32k clock handling") Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
commit 7bdccef3 upstream. A static code checker found a memory leak in the Versatile ICST code. Fix it. Fixes: a183da63 "clk: versatile: respect parent rate in ICST clock" Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Simran Rai authored
commit 63243a4d upstream. This patch affects the clocks that use fractional ndivider in their PLL output frequency calculation. Instead of 2^20 divide factor, the clock's ndiv integer shift was used. Fixed the bug by replacing ndiv integer shift with 2^20 factor. Signed-off-by:
Simran Rai <ssimran@broadcom.com> Signed-off-by:
Ray Jui <rjui@broadcom.com> Reviewed-by:
Scott Branden <sbranden@broadcom.com> Fixes: 5fe225c1 ("clk: iproc: add initial common clock support") Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Signed-off-by:
-
Ingo Molnar authored
commit b2f73922 upstream. So the /proc/PID/stat 'wchan' field (the 30th field, which contains the absolute kernel address of the kernel function a task is blocked in) leaks absolute kernel addresses to unprivileged user-space: seq_put_decimal_ull(m, ' ', wchan); The absolute address might also leak via /proc/PID/wchan as well, if KALLSYMS is turned off or if the symbol lookup fails for some reason: static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns, struct pid *pid, struct task_struct *task) { unsigned long wchan; char symname[KSYM_NAME_LEN]; wchan = get_wchan(task); if (lookup_symbol_name(wchan, symname) < 0) { if (!ptrace_may_access(task, PTRACE_MODE_READ)) return 0; seq_printf(m, "%lu", wchan); } else { seq_printf(m, "%s", symname); } return 0; } This isn't ideal, because for example it trivially leaks the KASLR offset to any local attacker: fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35) ffffffff8123b380 Most real-life uses of wchan are symbolic: ps -eo pid:10,tid:10,wchan:30,comm and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat: triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1 open("/proc/30833/wchan", O_RDONLY) = 6 There's one compatibility quirk here: procps relies on whether the absolute value is non-zero - and we can provide that functionality by outputing "0" or "1" depending on whether the task is blocked (whether there's a wchan address). These days there appears to be very little legitimate reason user-space would be interested in the absolute address. The absolute address is mostly historic: from the days when we didn't have kallsyms and user-space procps had to do the decoding itself via the System.map. So this patch sets all numeric output to "0" or "1" and keeps only symbolic output, in /proc/PID/wchan. ( The absolute sleep address can generally still be profiled via perf, by tasks with sufficient privileges. ) Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: kasan-dev <kasan-dev@googlegroups.com> Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Marcin Wojtas authored
commit 26c17a17 upstream. In the actual RX processing, there is same error path for both descriptor ring refilling and building skb fails. This is not correct, because after successful refill, the ring is already updated with newly allocated buffer. Then, in case of build_skb() fail, hitherto code left the original buffer unmapped. This patch fixes above situation by swapping error check of skb build with DMA-unmap of original buffer. Signed-off-by:
Marcin Wojtas <mw@semihalf.com> Acked-by:
Simon Guinot <simon.guinot@sequanux.org> Fixes a84e3289 ("net: mvneta: fix refilling for Rx DMA buffers") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Maxime Ripard authored
commit 2502d0ef upstream. The CPU_MAP register is duplicated for each CPUs at different addresses, each instance being at a different address. However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP registers for each registers, while the SoCs embed at most 4 CPUs. This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS is currently set to 16, resulting in writes to registers that are not CPU_MAP. Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Oren Givon authored
commit 4ab75944 upstream. Add some new PCI IDs for the 8260 series which were missing. The following sub-system IDs were added: 0x0130, 0x1130, 0x0132, 0x1132, 0x1150, 0x8110, 0x9110, 0x8130, 0x9130, 0x8132, 0x9132, 0x8150, 0x9150, 0x0044, 0x0930 Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 03a19cbb upstream. The hardware bug in the commit mentioned below forces us not to re-enable the clock gating in the Host Cluster. The impact on the power consumption is minimal and it allows the WAKE_ME interrupt to propagate. Fixes: c9fdec9f ("iwlwifi: pcie: fix prepare card flow") Signed-off-by:
-
Christophe Ricard authored
commit e65917b6 upstream. When receiving data in nci_hci_msg_rx_work, extract pipe value using NCI_HCP_MSG_GET_PIPE macro. Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Christophe Ricard authored
commit d8cd37ed upstream. When sending HCI data over NCI, HCI return code is part of the NCI data. In order to get correctly the HCI return code, we assume the NCI communication is successful and extract the return code for the nci_hci functions return code. This is done because nci_to_errno does not match hci return code value. Signed-off-by:
-
Christophe Ricard authored
commit 500c4ef0 upstream. When sending HCI data over NCI, cmd information should be present only on the first packet. Each packet shall be specifically allocated and sent to the NCI layer. Signed-off-by:
-
Christophe Ricard authored
commit a1269dd1 upstream. When sending data over SPI, the maximum expected length is the maximum nci packet payload + data header size + the frame head room (1 for the ndlc header) + the frame trail room (0). Signed-off-by:
-
Ola Olsson authored
commit 4baf6bea upstream. If parse_acl_data succeeds but the subsequent parsing of smps attributes fails, there will be a memory leak due to early returns. Fix that by moving the ACL parsing later. Fixes: 18998c38 ("cfg80211: allow requesting SMPS mode on ap start") Signed-off-by:
Ola Olsson <ola.olsson@sonymobile.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Janusz.Dziedzic@tieto.com authored
commit 519ee691 upstream. In case of one shot NOA the interval can be 0, catch that instead of potentially (depending on the driver) crashing like this: divide error: 0000 [#1] SMP [...] Call Trace: <IRQ> [<ffffffffc08e891c>] ieee80211_extend_absent_time+0x6c/0xb0 [mac80211] [<ffffffffc08e8a17>] ieee80211_update_p2p_noa+0xb7/0xe0 [mac80211] [<ffffffffc069cc30>] ath9k_p2p_ps_timer+0x170/0x190 [ath9k] [<ffffffffc070adf8>] ath_gen_timer_isr+0xc8/0xf0 [ath9k_hw] [<ffffffffc0691156>] ath9k_tasklet+0x296/0x2f0 [ath9k] [<ffffffff8107ad65>] tasklet_action+0xe5/0xf0 [...] Signed-off-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by:
-
Arik Nemtsov authored
commit 254d3dfe upstream. In TDLS channel-switch operations the chandef can sometimes be NULL. Avoid an oops in the trace code for these cases and just print a chandef full of zeros. Fixes: a7a6bdd0 ("mac80211: introduce TDLS channel switch ops") Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 8ec6d978 upstream. The ifmgd->ave_beacon_signal value cannot be taken as is for comparisons, it must be divided by since it's represented like that for better accuracy of the EWMA calculations. This would lead to invalid driver RSSI events. Fix the used value. Fixes: 615f7b9b ("mac80211: add driver RSSI threshold events") Signed-off-by:
-
Andrei Otcheretianski authored
commit a64cba3c upstream. Local request to deauthenticate wasn't handled while associating, thus the association could continue even when the user space required to disconnect. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Dave Hansen authored
commit f3119b83 upstream. I received a bug report that running 32-bit MPX binaries on 64-bit kernels was broken. I traced it down to this little code snippet. We were switching our "number of bounds directory entries" calculation correctly. But, we didn't switch the other side of the calculation: the virtual space size. This meant that we were calculating an absurd size for bd_entry_virt_space() on 32-bit because we used the 64-bit virt_space. This was _also_ broken for 32-bit kernels running on 64-bit hardware since boot_cpu_data.x86_virt_bits=48 even when running in 32-bit mode. Correct that and properly handle all 3 possible cases: 1. 32-bit binary on 64-bit kernel 2. 64-bit binary on 64-bit kernel 3. 32-bit binary on 32-bit kernel This manifested in having bounds tables not properly unmapped. It "leaked" memory but had no functional impact otherwise. Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20151111181934.FA7FAC34@viggo.jf.intel.comSigned-off-by:
-
Dave Hansen authored
commit 46561c39 upstream. When you call get_user(foo, bar), you effectively do a copy_from_user(&foo, bar, sizeof(*bar)); Note that the sizeof() is implicit. When we reach out to userspace to try to zap an entire "bounds table" we need to go read a "bounds directory entry" in order to locate the table's address. The size of a "directory entry" depends on the binary being run and is always the size of a pointer. But, when we have a 64-bit kernel and a 32-bit application, the directory entry is still only 32-bits long, but we fetch it with a 64-bit pointer which makes get_user() does a 64-bit fetch. Reading 4 extra bytes isn't harmful, unless we are at the end of and run off the table. It might also cause the zero page to get faulted in unnecessarily even if you are not at the end. Fix it up by doing a special 32-bit get_user() via a cast when we have 32-bit userspace. Signed-off-by:
-
