An error occurred fetching the project authors.
- 14 Jul, 2019 17 commits
-
-
Sean Nyekjaer authored
[ Upstream commit 0df82dcd ] Fully compatible with mcp2515, the mcp25625 have integrated transceiver. This patch add the mcp25625 to the device tree bindings documentation. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Srinivas Kandagatla authored
[ Upstream commit 39194128 ] Looks like there is a copy paste error. This patch fixes it! Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 69ae4f6a ] A few places in mwifiex_uap_parse_tail_ies() perform memcpy() unconditionally, which may lead to either buffer overflow or read over boundary. This patch addresses the issues by checking the read size and the destination size at each place more properly. Along with the fixes, the patch cleans up the code slightly by introducing a temporary variable for the token size, and unifies the error path with the standard goto statement. Reported-by:
huangwen <huangwen@venustech.com.cn> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit a8627176 ] In the error handling code of iwl_req_fw_callback(), iwl_dealloc_ucode() is called to free data. In iwl_drv_stop(), iwl_dealloc_ucode() is called again, which can cause double-free problems. To fix this bug, the call to iwl_dealloc_ucode() in iwl_req_fw_callback() is deleted. This bug is found by a runtime fuzzing tool named FIZZER written by us. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 13ec7f10 ] mwifiex_update_bss_desc_with_ie() calls memcpy() unconditionally in a couple places without checking the destination size. Since the source is given from user-space, this may trigger a heap buffer overflow. Fix it by putting the length check before performing memcpy(). This fix addresses CVE-2019-3846. Reported-by:
-
Pradeep Kumar Chitrapu authored
[ Upstream commit 0112fa55 ] freeing peer keys after vif down is resulting in peer key uninstall to fail due to interface lookup failure. so fix that. Signed-off-by:
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Thomas Pedersen authored
[ Upstream commit 55184244 ] ifmsh->csa is an RCU-protected pointer. The writer context in ieee80211_mesh_finish_csa() is already mutually exclusive with wdev->sdata.mtx, but the RCU checker did not know this. Use rcu_dereference_protected() to avoid a warning. fixes the following warning: [ 12.519089] ============================= [ 12.520042] WARNING: suspicious RCU usage [ 12.520652] 5.1.0-rc7-wt+ #16 Tainted: G W [ 12.521409] ----------------------------- [ 12.521972] net/mac80211/mesh.c:1223 suspicious rcu_dereference_check() usage! [ 12.522928] other info that might help us debug this: [ 12.523984] rcu_scheduler_active = 2, debug_locks = 1 [ 12.524855] 5 locks held by kworker/u8:2/152: [ 12.525438] #0: 00000000057be08c ((wq_completion)phy0){+.+.}, at: process_one_work+0x1a2/0x620 [ 12.526607] #1: 0000000059c6b07a ((work_completion)(&sdata->csa_finalize_work)){+.+.}, at: process_one_work+0x1a2/0x620 [ 12.528001] #2: 00000000f184ba7d (&wdev->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x2f/0x90 [ 12.529116] #3: 00000000831a1f54 (&local->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x47/0x90 [ 12.530233] #4: 00000000fd06f988 (&local->chanctx_mtx){+.+.}, at: ieee80211_csa_finalize_work+0x51/0x90 Signed-off-by:
Thomas Pedersen <thomas@eero.com> Signed-off-by:
-
Melissa Wen authored
[ Upstream commit df4d737e ] According to the AD7150 configuration register description, bit 7 assumes value 1 when the threshold mode is fixed and 0 when it is adaptive, however, the operation that identifies this mode was considering the opposite values. This patch renames the boolean variable to describe it correctly and properly replaces it in the places where it is used. Fixes: 531efd6a ("staging:iio:adc:ad7150: chan_spec conv + i2c_smbus commands + drop unused poweroff timeout control.") Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Srinivas Kandagatla authored
[ Upstream commit 03ecad90 ] Assigning local iterator to array element and using it again for indexing would cross the array boundary. Fix this by directly referring array element without using the local variable. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
John Fastabend authored
[ Upstream commit bd95e678 ] Backlog work for psock (sk_psock_backlog) might sleep while waiting for memory to free up when sending packets. However, while sleeping the socket may be closed and removed from the map by the user space side. This breaks an assumption in sk_stream_wait_memory, which expects the wait queue to be still there when it wakes up resulting in a use-after-free shown below. To fix his mark sendmsg as MSG_DONTWAIT to avoid the sleep altogether. We already set the flag for the sendpage case but we missed the case were sendmsg is used. Sockmap is currently the only user of skb_send_sock_locked() so only the sockmap paths should be impacted. ================================================================== BUG: KASAN: use-after-free in remove_wait_queue+0x31/0x70 Write of size 8 at addr ffff888069a0c4e8 by task kworker/0:2/110 CPU: 0 PID: 110 Comm: kworker/0:2 Not tainted 5.0.0-rc2-00335-g28f9d1a3-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 Workqueue: events sk_psock_backlog Call Trace: print_address_description+0x6e/0x2b0 ? remove_wait_queue+0x31/0x70 kasan_report+0xfd/0x177 ? remove_wait_queue+0x31/0x70 ? remove_wait_queue+0x31/0x70 remove_wait_queue+0x31/0x70 sk_stream_wait_memory+0x4dd/0x5f0 ? sk_stream_wait_close+0x1b0/0x1b0 ? wait_woken+0xc0/0xc0 ? tcp_current_mss+0xc5/0x110 tcp_sendmsg_locked+0x634/0x15d0 ? tcp_set_state+0x2e0/0x2e0 ? __kasan_slab_free+0x1d1/0x230 ? kmem_cache_free+0x70/0x140 ? sk_psock_backlog+0x40c/0x4b0 ? process_one_work+0x40b/0x660 ? worker_thread+0x82/0x680 ? kthread+0x1b9/0x1e0 ? ret_from_fork+0x1f/0x30 ? check_preempt_curr+0xaf/0x130 ? iov_iter_kvec+0x5f/0x70 ? kernel_sendmsg_locked+0xa0/0xe0 skb_send_sock_locked+0x273/0x3c0 ? skb_splice_bits+0x180/0x180 ? start_thread+0xe0/0xe0 ? update_min_vruntime.constprop.27+0x88/0xc0 sk_psock_backlog+0xb3/0x4b0 ? strscpy+0xbf/0x1e0 process_one_work+0x40b/0x660 worker_thread+0x82/0x680 ? process_one_work+0x660/0x660 kthread+0x1b9/0x1e0 ? __kthread_create_on_node+0x250/0x250 ret_from_fork+0x1f/0x30 Fixes: 20bf50de ("skbuff: Function to send an skbuf on a socket") Reported-by:
Jakub Sitnicki <jakub@cloudflare.com> Tested-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
John Crispin authored
[ Upstream commit 25d16d12 ] The reported rate is not scaled down correctly. After applying this patch, the function will behave just like the v/ht equivalents. Signed-off-by:
Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
-
Matteo Croce authored
[ Upstream commit a195ceff ] GCC 9 fails to calculate the size of local constant strings and produces a false positive: samples/bpf/task_fd_query_user.c: In function ‘test_debug_fs_uprobe’: samples/bpf/task_fd_query_user.c:242:67: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 215 [-Wformat-truncation=] 242 | snprintf(buf, sizeof(buf), "/sys/kernel/debug/tracing/events/%ss/%s/id", | ^~ 243 | event_type, event_alias); | ~~~~~~~~~~~ samples/bpf/task_fd_query_user.c:242:2: note: ‘snprintf’ output between 45 and 300 bytes into a destination of size 256 242 | snprintf(buf, sizeof(buf), "/sys/kernel/debug/tracing/events/%ss/%s/id", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 243 | event_type, event_alias); | ~~~~~~~~~~~~~~~~~~~~~~~~ Workaround this by lowering the buffer size to a reasonable value. Related GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431Signed-off-by:
Matteo Croce <mcroce@redhat.com> Signed-off-by:
-
Chang-Hsien Tsai authored
[ Upstream commit f7c2d64b ] If the trace for read is larger than 4096, the return value sz will be 4096. This results in off-by-one error on buf: static char buf[4096]; ssize_t sz; sz = read(trace_fd, buf, sizeof(buf)); if (sz > 0) { buf[sz] = 0; puts(buf); } Signed-off-by:
Chang-Hsien Tsai <luke.tw@gmail.com> Signed-off-by:
-
Aaron Ma authored
[ Upstream commit aa440de3 ] Adding 2 new touchpad PNPIDs to enable middle button support. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 6b23af07 ] The BIUCTRL register writes require that a data barrier be inserted after comitting the write to the register for the block to latch in the recently written values. Reads have no such requirement and are not changed. Fixes: 34642650 ("soc: Move brcmstb to bcm/brcmstb") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 490cad5a ] In case setup_hifcpubiuctrl_regs() returns an error, because of e.g: an unsupported CPU type, just catch that error and return instead of blindly continuing with the initialization. This fixes a NULL pointer de-reference with the code continuing without having a proper array of registers to use. Fixes: 22f7a911 ("soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs") Signed-off-by:
-
Christophe Leroy authored
commit a1a42f84 upstream. The talitos driver has two ways to perform AEAD depending on the HW capability. Some HW support both. It is needed to give them different names to distingish which one it is for instance when a test fails. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 7405c8d7 ("crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU") Cc: stable@vger.kernel.org Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 Jul, 2019 23 commits
-
-
Greg Kroah-Hartman authored
-
Robin Gong authored
commit 3f93a4f2 upstream. It is possible for an irq triggered by channel0 to be received later after clks are disabled once firmware loaded during sdma probe. If that happens then clearing them by writing to SDMA_H_INTR won't work and the kernel will hang processing infinite interrupts. Actually, don't need interrupt triggered on channel0 since it's pollling SDMA_H_STATSTOP to know channel0 done rather than interrupt in current code, just clear BD_INTR to disable channel0 interrupt to avoid the above case. This issue was brought by commit 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") which didn't take care the above case. Fixes: 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") Cc: stable@vger.kernel.org #5.0+ Signed-off-by:
Robin Gong <yibin.gong@nxp.com> Reported-by:
Sven Van Asbroeck <thesven73@gmail.com> Tested-by:
Michael Olbrich <m.olbrich@pengutronix.de> Signed-off-by:
-
Sricharan R authored
commit f6034225 upstream. One space is left unused in circular FIFO to differentiate 'full' and 'empty' cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: stable@vger.kernel.org Reported-by:
Sricharan R <sricharan@codeaurora.org> Tested-by:
-
Cedric Hombourger authored
commit 637dfa0f upstream. scripts/package/builddeb calls "make dtbs_install" after executing a plain make (i.e. no build targets specified). It will fail if dtbs were not built beforehand. Match the arm64 architecture where DTBs get built by the "all" target. Signed-off-by:
Cedric Hombourger <Cedric_Hombourger@mentor.com> [paul.burton@mips.com: s/builddep/builddeb] Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Cc: stable@vger.kernel.org # v4.1+ Signed-off-by:
-
Dmitry Korotin authored
commit 0b24cae4 upstream. Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence. Without this execution hazard barrier it's possible for the value read back from the KScratch register to be the value from before the mtc0. Reproducible on P5600 & P6600. The hazard is documented in the MIPS Architecture Reference Manual Vol. III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev 6.03 table 8.1 which includes: Producer | Consumer | Hazard ----------|----------|---------------------------- mtc0 | mfc0 | any coprocessor 0 register Signed-off-by:
Dmitry Korotin <dkorotin@wavecomp.com> [paul.burton@mips.com: - Commit message tweaks. - Add Fixes tags. - Mark for stable back to v3.15 where P5600 support was introduced.] Signed-off-by:
-
Hauke Mehrtens authored
commit d6ed083f upstream. The bounds check used the uninitialized variable vaddr, it should use the given parameter kaddr instead. When using the uninitialized value the compiler assumed it to be 0 and optimized this function to just return 0 in all cases. This should make the function check the range of the given address and only do the page map check in case it is in the expected range of virtual addresses. Fixes: 074a1e11 ("MIPS: Bounds check virt_addr_valid") Cc: stable@vger.kernel.org # v4.12+ Cc: Paul Burton <paul.burton@mips.com> Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Chuck Lever authored
commit 1e091c3b upstream. The DRC appears to be effectively empty after an RPC/RDMA transport reconnect. The problem is that each connection uses a different source port, which defeats the DRC hash. Clients always have to disconnect before they send retransmissions to reset the connection's credit accounting, thus every retransmit on NFS/RDMA will miss the DRC. An NFS/RDMA client's IP source port is meaningless for RDMA transports. The transport layer typically sets the source port value on the connection to a random ephemeral port. The server already ignores it for the "secure port" check. See commit 16e4d93f ("NFSD: Ignore client's source port on RDMA transports"). The Linux NFS server's DRC resolves XID collisions from the same source IP address by using the checksum of the first 200 bytes of the RPC call header. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Cc: stable@vger.kernel.org # v4.14+ Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Paul Menzel authored
commit 3b2d4dcf upstream. Since commit 10a68cdf (nfsd: fix performance-limiting session calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with 1 TB of memory cannot be mounted anymore. The mount just hangs on the client. The gist of commit 10a68cdf is the change below. -avail = clamp_t(int, avail, slotsize, avail/3); +avail = clamp_t(int, avail, slotsize, total_avail/3); Here are the macros. #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi) `total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts the values to `int`, which for 32-bit integers can only hold values −2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1). `avail` (in the function signature) is just 65536, so that no overflow was happening. Before the commit the assignment would result in 21845, and `num = 4`. When using `total_avail`, it is causing the assignment to be 18446744072226137429 (printed as %lu), and `num` is then 4164608182. My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the server thinks there is no memory available any more for this client. Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long` fixes the issue. Now, `avail = 65536` (before commit 10a68cdf `avail = 21845`), but `num = 4` remains the same. Fixes: c54f24e3 (nfsd: fix performance-limiting session calculation) Cc: stable@vger.kernel.org Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
Wanpeng Li authored
commit bb34e690 upstream. Thomas reported that: | Background: | | In preparation of supporting IPI shorthands I changed the CPU offline | code to software disable the local APIC instead of just masking it. | That's done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV | register. | | Failure: | | When the CPU comes back online the startup code triggers occasionally | the warning in apic_pending_intr_clear(). That complains that the IRRs | are not empty. | | The offending vector is the local APIC timer vector who's IRR bit is set | and stays set. | | It took me quite some time to reproduce the issue locally, but now I can | see what happens. | | It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1 | (and hardware support) it behaves correctly. | | Here is the series of events: | | Guest CPU | | goes down | | native_cpu_disable() | | apic_soft_disable(); | | play_dead() | | .... | | startup() | | if (apic_enabled()) | apic_pending_intr_clear() <- Not taken | | enable APIC | | apic_pending_intr_clear() <- Triggers warning because IRR is stale | | When this happens then the deadline timer or the regular APIC timer - | happens with both, has fired shortly before the APIC is disabled, but the | interrupt was not serviced because the guest CPU was in an interrupt | disabled region at that point. | | The state of the timer vector ISR/IRR bits: | | ISR IRR | before apic_soft_disable() 0 1 | after apic_soft_disable() 0 1 | | On startup 0 1 | | Now one would assume that the IRR is cleared after the INIT reset, but this | happens only on CPU0. | | Why? | | Because our CPU0 hotplug is just for testing to make sure nothing breaks | and goes through an NMI wakeup vehicle because INIT would send it through | the boots-trap code which is not really working if that CPU was not | physically unplugged. | | Now looking at a real world APIC the situation in that case is: | | ISR IRR | before apic_soft_disable() 0 1 | after apic_soft_disable() 0 1 | | On startup 0 0 | | Why? | | Once the dying CPU reenables interrupts the pending interrupt gets | delivered as a spurious interupt and then the state is clear. | | While that CPU0 hotplug test case is surely an esoteric issue, the APIC | emulation is still wrong, Even if the play_dead() code would not enable | interrupts then the pending IRR bit would turn into an ISR .. interrupt | when the APIC is reenabled on startup. From SDM 10.4.7.2 Local APIC State After It Has Been Software Disabled * Pending interrupts in the IRR and ISR registers are held and require masking or handling by the CPU. In Thomas's testing, hardware cpu will not respect soft disable LAPIC when IRR has already been set or APICv posted-interrupt is in flight, so we can skip soft disable APIC checking when clearing IRR and set ISR, continue to respect soft disable APIC when attempting to set IRR. Reported-by:
Rong Chen <rong.a.chen@intel.com> Reported-by:
Feng Tang <feng.tang@intel.com> Reported-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Wanpeng Li <wanpengli@tencent.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
commit 3f16a5c3 upstream. This warning can be triggered easily by userspace, so it should certainly not cause a panic if panic_on_warn is set. Reported-by: syzbot+c03f30b4f4c46bdf8575@syzkaller.appspotmail.com Suggested-by:
Alexander Potapenko <glider@google.com> Acked-by:
-
Guillaume Nault authored
[ Upstream commit 8a3dca63 ] When fixing the skb leak introduced by the conversion to rbtree, I forgot about the special case of duplicate fragments. The condition under the 'insert_error' label isn't effective anymore as nf_ct_frg6_gather() doesn't override the returned value anymore. So duplicate fragments now get NF_DROP verdict. To accept duplicate fragments again, handle them specially as soon as inet_frag_queue_insert() reports them. Return -EINPROGRESS which will translate to NF_STOLEN verdict, like any accepted fragment. However, such packets don't carry any new information and aren't queued, so we just drop them immediately. Fixes: a0d56cb9 ("netfilter: ipv6: nf_defrag: fix leakage of unqueued fragments") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit fdadd049 ] Michael and Sandipan report: Commit ede95a63 introduced a bpf_jit_limit tuneable to limit BPF JIT allocations. At compile time it defaults to PAGE_SIZE * 40000, and is adjusted again at init time if MODULES_VADDR is defined. For ppc64 kernels, MODULES_VADDR isn't defined, so we're stuck with the compile-time default at boot-time, which is 0x9c400000 when using 64K page size. This overflows the signed 32-bit bpf_jit_limit value: root@ubuntu:/tmp# cat /proc/sys/net/core/bpf_jit_limit -1673527296 and can cause various unexpected failures throughout the network stack. In one case `strace dhclient eth0` reported: setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x105dd27f8}, 16) = -1 ENOTSUPP (Unknown error 524) and similar failures can be seen with tools like tcpdump. This doesn't always reproduce however, and I'm not sure why. The more consistent failure I've seen is an Ubuntu 18.04 KVM guest booted on a POWER9 host would time out on systemd/netplan configuring a virtio-net NIC with no noticeable errors in the logs. Given this and also given that in near future some architectures like arm64 will have a custom area for BPF JIT image allocations we should get rid of the BPF_JIT_LIMIT_DEFAULT fallback / default entirely. For 4.21, we have an overridable bpf_jit_alloc_exec(), bpf_jit_free_exec() so therefore add another overridable bpf_jit_alloc_exec_limit() helper function which returns the possible size of the memory area for deriving the default heuristic in bpf_jit_charge_init(). Like bpf_jit_alloc_exec() and bpf_jit_free_exec(), the new bpf_jit_alloc_exec_limit() assumes that module_alloc() is the default JIT memory provider, and therefore in case archs implement their custom module_alloc() we use MODULES_{END,_VADDR} for limits and otherwise for vmalloc_exec() cases like on ppc64 we use VMALLOC_{END,_START}. Additionally, for archs supporting large page sizes, we should change the sysctl to be handled as long to not run into sysctl restrictions in future. Fixes: ede95a63 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations") Reported-by:
Sandipan Das <sandipan@linux.ibm.com> Reported-by:
Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit ea401685 ] Currently mskid is unsigned and hence comparisons with negative error return values are always false. Fix this by making mskid an int. Fixes: f058e468 ("net: hns: fix ICMP6 neighbor solicitation messages discard problem") Addresses-Coverity: ("Operands don't affect result") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Guoqing Jiang authored
[ Upstream commit e00164a0 ] err_spi is used when SERIAL_SC16IS7XX_SPI is enabled, so make the label only available under SERIAL_SC16IS7XX_SPI option. Otherwise, the below warning appears. drivers/tty/serial/sc16is7xx.c:1523:1: warning: label ‘err_spi’ defined but not used [-Wunused-label] err_spi: ^~~~~~~ Signed-off-by:
Guoqing Jiang <gqjiang@suse.com> Fixes: ac0cdb3d ("sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit a0d56cb9 ] With commit 997dd964 ("net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c"), nf_ct_frag6_reasm() is now called from nf_ct_frag6_queue(). With this change, nf_ct_frag6_queue() can fail after the skb has been added to the fragment queue and nf_ct_frag6_gather() was adapted to handle this case. But nf_ct_frag6_queue() can still fail before the fragment has been queued. nf_ct_frag6_gather() can't handle this case anymore, because it has no way to know if nf_ct_frag6_queue() queued the fragment before failing. If it didn't, the skb is lost as the error code is overwritten with -EINPROGRESS. Fix this by setting -EINPROGRESS directly in nf_ct_frag6_queue(), so that nf_ct_frag6_gather() can propagate the error as is. Fixes: 997dd964 ("net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c") Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 47d3d7fd ] Since ip6frag_expire_frag_queue() now pulls the head skb from frag queue, we should no longer use skb_get(), since this leads to an skb leak. Stefan Bader initially reported a problem in 4.4.stable [1] caused by the skb_get(), so this patch should also fix this issue. 296583.091021] kernel BUG at /build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207! [296583.091734] Call Trace: [296583.091749] [<ffffffff81740e50>] __pskb_pull_tail+0x50/0x350 [296583.091764] [<ffffffff8183939a>] _decode_session6+0x26a/0x400 [296583.091779] [<ffffffff817ec719>] __xfrm_decode_session+0x39/0x50 [296583.091795] [<ffffffff818239d0>] icmpv6_route_lookup+0xf0/0x1c0 [296583.091809] [<ffffffff81824421>] icmp6_send+0x5e1/0x940 [296583.091823] [<ffffffff81753238>] ? __netif_receive_skb+0x18/0x60 [296583.091838] [<ffffffff817532b2>] ? netif_receive_skb_internal+0x32/0xa0 [296583.091858] [<ffffffffc0199f74>] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe] [296583.091876] [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [296583.091893] [<ffffffff8183d431>] icmpv6_send+0x21/0x30 [296583.091906] [<ffffffff8182b500>] ip6_expire_frag_queue+0xe0/0x120 [296583.091921] [<ffffffffc04eb27f>] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6] [296583.091938] [<ffffffff810f3b57>] call_timer_fn+0x37/0x140 [296583.091951] [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [296583.091968] [<ffffffff810f5464>] run_timer_softirq+0x234/0x330 [296583.091982] [<ffffffff8108a339>] __do_softirq+0x109/0x2b0 Fixes: d4289fcc ("net: IP6 defrag: use rbtrees for IPv6 defrag") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Stefan Bader <stefan.bader@canonical.com> Cc: Peter Oskolkov <posk@google.com> Cc: Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
[ Upstream commit d84e7bc0 ] >> net/rds/send.c:1109:42: warning: Using plain integer as NULL pointer Fixes: ea010070 ("net/rds: fix warn in rds_message_alloc_sgs") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 183ab39e ] The recent commit 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls") made the HD-audio driver to store the PM state in power_state field. This forgot, however, the initialization at power up. Although the codec drivers usually don't need to refer to this field in the normal operation, let's initialize it properly for consistency. Fixes: 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls") Signed-off-by:
-
Salil Mehta authored
[ Upstream commit 4d96e13e ] This patch fixes the missing device reference release-after-use in the positive leg of the roce reset API of the HNS DSAF. Fixes: c969c6e7 ("net: hns: Fix object reference leaks in hns_dsaf_roce_reset()") Reported-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Kirill A. Shutemov authored
[ Upstream commit 45b13b42 ] RDMSR in the trampoline code overwrites EDX but that register is used to indicate whether 5-level paging has to be enabled and if clobbered, leads to failure to boot on a 5-level paging machine. Preserve EDX on the stack while we are dealing with EFER. Fixes: b677dfae ("x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning to long mode") Reported-by:
Kyle D Pelton <kyle.d.pelton@intel.com> Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: dave.hansen@linux.intel.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wei Huang <wei@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190206115253.1907-1-kirill.shutemov@linux.intel.comSigned-off-by:
-
David Ahern authored
[ Upstream commit 15d55bae ] A recent commit returns an error if icmp is used as the ip-proto for IPv6 fib rules. Update fib_rule_tests to send ipv6-icmp instead of icmp. Fixes: 5e1a99ea ("ipv4: Add ICMPv6 support when parse route ipproto") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Xiubo Li authored
[ Upstream commit 40d883b0 ] Fixes: a94a2572 ("scsi: tcmu: avoid cmd/qfull timers updated whenever a new cmd comes") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Mike Christie <mchristi@redhat.com> Signed-off-by:
Xiubo Li <xiubli@redhat.com> Reviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit f2ffff08 ] spin_lock_bh() is used in table_path_del() but rcu_read_unlock() is used for unlocking. Fix it by using spin_unlock_bh() instead of rcu_read_unlock() in the error handling case. Fixes: b4c3fbe6 ("mac80211: Use linked list instead of rhashtable walk for mesh tables") Acked-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
