- 14 Jul, 2019 40 commits
-
-
Anson Huang authored
[ Upstream commit ce9a53eb ] There are several scenarios that keyboard can NOT wake up system from suspend, e.g., if a keyboard is depressed between system device suspend phase and device noirq suspend phase, the keyboard ISR will be called and both keyboard depress and release interrupts will be disabled, then keyboard will no longer be able to wake up system. Another scenario would be, if a keyboard is kept depressed, and then system goes into suspend, the expected behavior would be when keyboard is released, system will be waked up, but current implementation can NOT achieve that, because both depress and release interrupts are disabled in ISR, and the event check is still in progress. To fix these issues, need to make sure keyboard's depress or release interrupt is enabled after noirq device suspend phase, this patch moves the suspend/resume callback to noirq suspend/resume phase, and enable the corresponding interrupt according to current keyboard status. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nick Hu authored
[ Upstream commit d0e1f211 ] In RV32, udelay would delay the wrong cycle. When it shifts right "UDELAY_SHIFT" bits, it either delays 0 cycle or 1 cycle. It only works correctly in RV64. Because the 'ucycles' always needs to be 64 bits variable. Signed-off-by:
Nick Hu <nickhu@andestech.com> Reviewed-by:
Palmer Dabbelt <palmer@sifive.com> [paul.walmsley@sifive.com: fixed minor spelling error] Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by:
-
Qian Cai authored
[ Upstream commit 39916897 ] Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver forgot to set dma_parms appropriately. Set it just after vmw_dma_masks() in vmw_driver_load(). DMA-API: vmwgfx 0000:00:0f.0: mapping sg segment longer than device claims to support [len=2097152] [max=65536] WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232 debug_dma_map_sg+0x360/0x480 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018 RIP: 0010:debug_dma_map_sg+0x360/0x480 Call Trace: vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx] vmw_bo_map_dma+0x25/0x30 [vmwgfx] vmw_otables_setup+0x2a8/0x750 [vmwgfx] vmw_request_device_late+0x78/0xc0 [vmwgfx] vmw_request_device+0xee/0x4e0 [vmwgfx] vmw_driver_load.cold+0x757/0xd84 [vmwgfx] drm_dev_register+0x1ff/0x340 [drm] drm_get_pci_dev+0x110/0x290 [drm] vmw_probe+0x15/0x20 [vmwgfx] local_pci_probe+0x7a/0xc0 pci_device_probe+0x1b9/0x290 really_probe+0x1b5/0x630 driver_probe_device+0xa3/0x1a0 device_driver_attach+0x94/0xa0 __driver_attach+0xdd/0x1c0 bus_for_each_dev+0xfe/0x150 driver_attach+0x2d/0x40 bus_add_driver+0x290/0x350 driver_register+0xdc/0x1d0 __pci_register_driver+0xda/0xf0 vmwgfx_init+0x34/0x1000 [vmwgfx] do_one_initcall+0xe5/0x40a do_init_module+0x10f/0x3a0 load_module+0x16a5/0x1a40 __se_sys_finit_module+0x183/0x1c0 __x64_sys_finit_module+0x43/0x50 do_syscall_64+0xc8/0x606 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: fb1d9738 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU") Co-developed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
Thomas Hellstrom authored
[ Upstream commit bde15555 ] When building sg tables, honor the device sg list segment size limitation. Signed-off-by:
Deepak Rawat <drawat@vmware.com> Signed-off-by:
-
Kevin Hilman authored
[ Upstream commit 3b025f2b ] Enable PRCI clock driver and serial console by default, so the default upstream defconfig is bootable to a serial console. Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Heiko Carstens authored
[ Upstream commit f9364df3 ] Get rid of gcc9 warnings like this: arch/s390/boot/ipl_report.c: In function 'find_bootdata_space': arch/s390/boot/ipl_report.c:42:26: warning: taking address of packed member of 'struct ipl_rb_components' may result in an unaligned pointer value [-Waddress-of-packed-member] 42 | for_each_rb_entry(comp, comps) | ^~~~~ This is effectively the s390 variant of commit 20c6c189 ("x86/boot: Disable the address-of-packed-member compiler warning"). Reviewed-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Teresa Remmet authored
[ Upstream commit 8a0098c0 ] Active level of the mmc1 cd gpio needs to be low instead of high. Fix PCM-953 and phyBOARD-WEGA. Signed-off-by:
Teresa Remmet <t.remmet@phytec.de> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit 7c940b1a ] The return values for these memory allocations are unchecked, which may cause an oops if the driver does not handle them after a failure. Fix by checking the function's return code. Signed-off-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit be32a243 ] It was observed that multicast packets were no longer received after a device reset. The fix is to resend the current multicast list to the backing device after recovery. Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit 1f94608b ] Check driver state before halting it during a reset. If the driver is not running, do nothing. Otherwise, a request to deactivate a down link can cause an error and the reset will fail. Signed-off-by:
-
Michael Schmitz authored
[ Upstream commit a9520543 ] [Resent to net instead of net-next - may clash with Anders Roxell's patch series addressing duplicate module names] Commit 31dd83b9 ("net-next: phy: new Asix Electronics PHY driver") introduced a new PHY driver drivers/net/phy/asix.c that causes a module name conflict with a pre-existiting driver (drivers/net/usb/asix.c). The PHY driver is used by the X-Surf 100 ethernet card driver, and loaded by that driver via its PHY ID. A rename of the driver looks unproblematic. Rename PHY driver to ax88796b.c in order to resolve name conflict. Signed-off-by:
Michael Schmitz <schmitzmic@gmail.com> Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit eb503004 ] Currently the following message is observed when the flexcan driver is probed: flexcan 2090000.flexcan: device registered (reg_base=(ptrval), irq=23) The reason for printing 'ptrval' is explained at Documentation/core-api/printk-formats.rst: "Pointers printed without a specifier extension (i.e unadorned %p) are hashed to prevent leaking information about the kernel memory layout. This has the added benefit of providing a unique identifier. On 64-bit machines the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it gathers enough entropy." Instead of passing %pK, which can print the correct address, simply remove the entire message as it is not really that useful. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
YueHaibing authored
[ Upstream commit c5a3aed1 ] This patch add error path for can_init() to avoid possible crash if some error occurs. Fixes: 0d66548a ("[CAN]: Add PF_CAN core module") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Eugen Hristev authored
[ Upstream commit 3e82f2f3 ] During frame reception while the MCAN is in Error Passive state and the Receive Error Counter has thevalue MCAN_ECR.REC = 127, it may happen that MCAN_IR.MRAF is set although there was no Message RAM access failure. If MCAN_IR.MRAF is enabled, an interrupt to the Host CPU is generated. Work around: The Message RAM Access Failure interrupt routine needs to check whether MCAN_ECR.RP = '1' and MCAN_ECR.REC = '127'. In this case, reset MCAN_IR.MRAF. No further action is required. This affects versions older than 3.2.0 Errata explained on Sama5d2 SoC which includes this hardware block: http://ww1.microchip.com/downloads/en/DeviceDoc/SAMA5D2-Family-Silicon-Errata-and-Data-Sheet-Clarification-DS80000803B.pdf chapter 6.2 Reproducibility: If 2 devices with m_can are connected back to back, configuring different bitrate on them will lead to interrupt storm on the receiving side, with error "Message RAM access failure occurred". Another way is to have a bad hardware connection. Bad wire connection can lead to this issue as well. This patch fixes the issue according to provided workaround. Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Sean Nyekjaer authored
[ Upstream commit 35b7fa4d ] Fully compatible with mcp2515, the mcp25625 have integrated transceiver. This patch adds support for the mcp25625 to the existing mcp251x driver. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Signed-off-by:
-
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:
-
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:
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:
-
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:
-
