- 14 Jul, 2019 29 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>
-
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:
-
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:
-
Srinivas Kandagatla authored
[ Upstream commit 9315d904 ] the msg lock is taken for multi-link cases only but released unconditionally, leading to an unlock balance warning for single-link usages This patch fixes this. ===================================== WARNING: bad unlock balance detected! 5.1.0-16506-gc1c383a6f0a2-dirty #1523 Tainted: G W ------------------------------------- aplay/2954 is trying to release lock (&bus->msg_lock) at: do_bank_switch+0x21c/0x480 but there are no more locks to release! Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by:
Sanyog Kale <sanyog.r.kale@intel.com> [vkoul: edited the change log as suggested by Pierre] Signed-off-by:
-
Krzesimir Nowak authored
[ Upstream commit 1884c066 ] In commit 9a5ab8bf ("tools: bpftool: turn err() and info() macros into functions") one case of error reporting was special cased, so it could report a lookup error for a specific key when dumping the map element. What the code forgot to do is to wrap the key and value keys into a JSON object, so an example output of pretty JSON dump of a sockhash map (which does not support looking up its values) is: [ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00" ], "value": { "error": "Operation not supported" }, "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01" ], "value": { "error": "Operation not supported" } ] Note the key-value pairs inside the toplevel array. They should be wrapped inside a JSON object, otherwise it is an invalid JSON. This commit fixes this, so the output now is: [{ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00" ], "value": { "error": "Operation not supported" } },{ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01" ], "value": { "error": "Operation not supported" } } ] Fixes: 9a5ab8bf ("tools: bpftool: turn err() and info() macros into functions") Cc: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by:
Krzesimir Nowak <krzesimir@kinvolk.io> Acked-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> 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:
-
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:
-
Matt Chen authored
[ Upstream commit b17dc063 ] When try to bring up the AX201 2 killer sku, we run into: [81261.392463] iwlwifi 0000:01:00.0: loaded firmware version 46.8c20f243.0 op_mode iwlmvm [81261.407407] iwlwifi 0000:01:00.0: Detected Intel(R) Dual Band Wireless AX 22000, REV=0x340 [81262.424778] iwlwifi 0000:01:00.0: Collecting data: trigger 16 fired. [81262.673359] iwlwifi 0000:01:00.0: Start IWL Error Log Dump: [81262.673365] iwlwifi 0000:01:00.0: Status: 0x00000000, count: -906373681 [81262.673368] iwlwifi 0000:01:00.0: Loaded firmware version: 46.8c20f243.0 [81262.673371] iwlwifi 0000:01:00.0: 0x507C015D | ADVANCED_SYSASSERT Fix this issue by adding 2 more cfg to avoid modifying the original cfg configuration. Signed-off-by:
Matt Chen <matt.chen@intel.com> Signed-off-by:
-
Shahar S Matityahu authored
[ Upstream commit 44f61b5c ] The driver attempts to clear persistence bit on any device familiy even though only 9000 and 22000 families require it. Clear the bit only on the relevant device families. Each HW has different address to the write protection register. Use the right register for each HW Signed-off-by:
Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: 8954e1eb ("iwlwifi: trans: Clear persistence bit when starting the FW") Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit b3500b47 ] When we have a single image (same firmware image for INIT and OPERATIONAL), we couldn't load the driver and register to the stack if we had hardware RF-Kill asserted. Fix this. This required a few changes: 1) Run the firmware as part of the INIT phase even if its ucode_type is not IWL_UCODE_INIT. 2) Send the commands that are sent to the unified image in INIT flow even in RF-Kill. 3) Don't ask the transport to stop the hardware upon RF-Kill interrupt if the RF-Kill is asserted. 4) Allow the RF-Kill interrupt to take us out of L1A so that the RF-Kill interrupt will be received by the host (to enable the radio). Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Luke Nelson authored
[ Upstream commit 1e692f09 ] In BPF, 32-bit ALU operations should zero-extend their results into the 64-bit registers. The current BPF JIT on RISC-V emits incorrect instructions that perform sign extension only (e.g., addw, subw) on 32-bit add, sub, lsh, rsh, arsh, and neg. This behavior diverges from the interpreter and JITs for other architectures. This patch fixes the bugs by performing zero extension on the destination register of 32-bit ALU operations. Fixes: 2353ecc6 ("bpf, riscv: add BPF JIT for RV64G") Cc: Xi Wang <xi.wang@gmail.com> Signed-off-by:
Luke Nelson <luke.r.nels@gmail.com> Acked-by:
Song Liu <songliubraving@fb.com> Acked-by:
Björn Töpel <bjorn.topel@gmail.com> Reviewed-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> 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:
-
Tony Lindgren authored
[ Upstream commit 34f61de8 ] There is no CLKSEL for timer12 on dra7 unlike for timer1. This causes issues on booting the device that Tomi noticed if DEBUG_SLAB is enabled and the clkctrl clock does not properly handle non-existing clock. Let's drop the bogus CLKSEL clock, the clkctrl clock handling gets fixed separately. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Fixes: 4ed0dfe3 ("ARM: dts: dra7: Move l4 child devices to probe them with ti-sysc") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-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:
-
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:
-
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:
-
Jakub Sitnicki authored
[ Upstream commit 186bcc3d ] Once psock gets unlinked from its sock (sk_psock_drop), user-space can still trigger a call to sk->sk_write_space by setting TCP_NOTSENT_LOWAT socket option. This causes a null-ptr-deref because we try to read psock->saved_write_space from sk_psock_write_space: ================================================================== BUG: KASAN: null-ptr-deref in sk_psock_write_space+0x69/0x80 Read of size 8 at addr 00000000000001a0 by task sockmap-echo/131 CPU: 0 PID: 131 Comm: sockmap-echo Not tainted 5.2.0-rc1-00094-gf49aa1de #81 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014 Call Trace: ? sk_psock_write_space+0x69/0x80 __kasan_report.cold.2+0x5/0x3f ? sk_psock_write_space+0x69/0x80 kasan_report+0xe/0x20 sk_psock_write_space+0x69/0x80 tcp_setsockopt+0x69a/0xfc0 ? tcp_shutdown+0x70/0x70 ? fsnotify+0x5b0/0x5f0 ? remove_wait_queue+0x90/0x90 ? __fget_light+0xa5/0xf0 __sys_setsockopt+0xe6/0x180 ? sockfd_lookup_light+0xb0/0xb0 ? vfs_write+0x195/0x210 ? ksys_write+0xc9/0x150 ? __x64_sys_read+0x50/0x50 ? __bpf_trace_x86_fpu+0x10/0x10 __x64_sys_setsockopt+0x61/0x70 do_syscall_64+0xc5/0x520 ? vmacache_find+0xc0/0x110 ? syscall_return_slowpath+0x110/0x110 ? handle_mm_fault+0xb4/0x110 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ? trace_hardirqs_off_caller+0x4b/0x120 ? trace_hardirqs_off_thunk+0x1a/0x3a entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f2e5e7cdcce Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b1 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 36 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a 11 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffed011b778 EFLAGS: 00000206 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2e5e7cdcce RDX: 0000000000000019 RSI: 0000000000000006 RDI: 0000000000000007 RBP: 00007ffed011b790 R08: 0000000000000004 R09: 00007f2e5e84ee80 R10: 00007ffed011b788 R11: 0000000000000206 R12: 00007ffed011b78c R13: 00007ffed011b788 R14: 0000000000000007 R15: 0000000000000068 ================================================================== Restore the saved sk_write_space callback when psock is being dropped to fix the crash. Signed-off-by:
-
Björn Töpel authored
[ Upstream commit fe121ee5 ] When using 32-bit subregisters (ALU32), the RISC-V JIT would not clear the high 32-bits of the target register and therefore generate incorrect code. E.g., in the following code: $ cat test.c unsigned int f(unsigned long long a, unsigned int b) { return (unsigned int)a & b; } $ clang-9 -target bpf -O2 -emit-llvm -S test.c -o - | \ llc-9 -mattr=+alu32 -mcpu=v3 .text .file "test.c" .globl f .p2align 3 .type f,@function f: r0 = r1 w0 &= w2 exit .Lfunc_end0: .size f, .Lfunc_end0-f The JIT would not clear the high 32-bits of r0 after the and-operation, which in this case might give an incorrect return value. After this patch, that is not the case, and the upper 32-bits are cleared. Reported-by:
Jiong Wang <jiong.wang@netronome.com> Fixes: 2353ecc6 ("bpf, riscv: add BPF JIT for RV64G") 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>
-
Eric Biggers authored
commit 20a0f976 upstream. Commit c778f96b ("crypto: lrw - Optimize tweak computation") incorrectly reduced the alignmask of LRW instances from '__alignof__(u64) - 1' to '__alignof__(__be32) - 1'. However, xor_tweak() and setkey() assume that the data and key, respectively, are aligned to 'be128', which has u64 alignment. Fix the alignmask to be at least '__alignof__(be128) - 1'. Fixes: c778f96b ("crypto: lrw - Optimize tweak computation") Cc: <stable@vger.kernel.org> # v4.20+ Cc: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
- 10 Jul, 2019 11 commits
-
-
Greg Kroah-Hartman authored
-
Roman Bolshakov authored
commit 5676234f upstream. WRITE SAME corrupts data on the block device behind iblock if the command is emulated. The emulation code issues (M - 1) * N times more bios than requested, where M is the number of 512 blocks per real block size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a device with 4k blocks, 7 * N more LBAs gets written after the requested range. The issue happens because the number of 512 byte sectors to be written is decreased one by one while the real bios are typically from 1 to 8 512 byte sectors per bio. Fixes: c66ac9db ("[SCSI] target: Add LIO target core v4.0.0-rc6") Cc: <stable@vger.kernel.org> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 75f2d86b upstream. CONFIG_VALIDATE_FS_PARSER is a debugging tool to check that the parser tables are vaguely sane. It was set to default to 'Y' for the moment to catch errors in upcoming fs conversion development. Make sure it is not enabled by default in the final release of v5.1. Fixes: 31d921c7 ("vfs: Add configuration parser helpers") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dan Carpenter authored
commit 4c89cc73 upstream. The "pending" variable was a u32 but we cast it to an unsigned long pointer when we do the for_each_set_bit() loop. The problem is that on big endian 64bit systems that results in an out of bounds read. Fixes: 4e4106f5 ("dmaengine: jz4780: Fix transfers being ACKed too soon") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
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:
-
