user/sven/linux.git, branch v4.14.259

Linux 4.14.259

2021-12-22T08:18:02Z

Link: https://lore.kernel.org/r/20211220143022.266532675@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

xen/netback: don't queue unlimited number of packages

2021-12-22T08:18:02Z

commit be81992f9086b230623ae3ebbc85ecee4d00a3d3 upstream. In case a guest isn't consuming incoming network traffic as fast as it is coming in, xen-netback is buffering network packages in unlimited numbers today. This can result in host OOM situations. Commit f48da8b14d04ca8 ("xen-netback: fix unlimited guest Rx internal queue and carrier flapping") meant to introduce a mechanism to limit the amount of buffered data by stopping the Tx queue when reaching the data limit, but this doesn't work for cases like UDP. When hitting the limit don't queue further SKBs, but drop them instead. In order to be able to tell Rx packages have been dropped increment the rx_dropped statistics counter in this case. It should be noted that the old solution to continue queueing SKBs had the additional problem of an overflow of the 32-bit rx_queue_len value would result in intermittent Tx queue enabling. This is part of XSA-392 Fixes: f48da8b14d04ca8 ("xen-netback: fix unlimited guest Rx internal queue and carrier flapping") Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

xen/netback: fix rx queue stall detection

2021-12-22T08:18:02Z

commit 6032046ec4b70176d247a71836186d47b25d1684 upstream. Commit 1d5d48523900a4b ("xen-netback: require fewer guest Rx slots when not using GSO") introduced a security problem in netback, as an interface would only be regarded to be stalled if no slot is available in the rx queue ring page. In case the SKB at the head of the queued requests will need more than one rx slot and only one slot is free the stall detection logic will never trigger, as the test for that is only looking for at least one slot to be free. Fix that by testing for the needed number of slots instead of only one slot being available. In order to not have to take the rx queue lock that often, store the number of needed slots in the queue data. As all SKB dequeue operations happen in the rx queue kernel thread this is safe, as long as the number of needed slots is accessed via READ/WRITE_ONCE() only and updates are always done with the rx queue lock held. Add a small helper for obtaining the number of free slots. This is part of XSA-392 Fixes: 1d5d48523900a4b ("xen-netback: require fewer guest Rx slots when not using GSO") Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

xen/console: harden hvc_xen against event channel storms

2021-12-22T08:18:01Z

commit fe415186b43df0db1f17fa3a46275fd92107fe71 upstream. The Xen console driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using a lateeoi event channel. For the normal domU initial console this requires the introduction of bind_evtchn_to_irq_lateeoi() as there is no xenbus device available at the time the event channel is bound to the irq. As the decision whether an interrupt was spurious or not requires to test for bytes having been read from the backend, move sending the event into the if statement, as sending an event without having found any bytes to be read is making no sense at all. This is part of XSA-391 Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

xen/netfront: harden netfront against event channel storms

2021-12-22T08:18:01Z

commit b27d47950e481f292c0a5ad57357edb9d95d03ba upstream. The Xen netfront driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using lateeoi event channels. For being able to detect the case of no rx responses being added while the carrier is down a new lock is needed in order to update and test rsp_cons and the number of seen unconsumed responses atomically. This is part of XSA-391 Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

xen/blkfront: harden blkfront against event channel storms

2021-12-22T08:18:01Z

commit 0fd08a34e8e3b67ec9bd8287ac0facf8374b844a upstream. The Xen blkfront driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using lateeoi event channels. This is part of XSA-391 Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

Input: touchscreen - avoid bitwise vs logical OR warning

2021-12-22T08:18:01Z

commit a02dcde595f7cbd240ccd64de96034ad91cffc40 upstream. A new warning in clang points out a few places in this driver where a bitwise OR is being used with boolean types: drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This use of a bitwise OR is intentional, as bitwise operations do not short circuit, which allows all the calls to touchscreen_get_prop_u32() to happen so that the last parameter is initialized while coalescing the results of the calls to make a decision after they are all evaluated. To make this clearer to the compiler, use the '|=' operator to assign the result of each touchscreen_get_prop_u32() call to data_present, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen. Signed-off-by: Nathan Chancellor Reported-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Link: https://lore.kernel.org/r/20211014205757.3474635-1-nathan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Anders Roxell Signed-off-by: Greg Kroah-Hartman

ARM: 8800/1: use choice for kernel unwinders

2021-12-22T08:18:01Z

commit f9b58e8c7d031b0daa5c9a9ee27f5a4028ba53ac upstream. While in theory multiple unwinders could be compiled in, it does not make sense in practise. Use a choice to make the unwinder selection mutually exclusive and mandatory. Already before this commit it has not been possible to deselect FRAME_POINTER. Remove the obsolete comment. Furthermore, to produce a meaningful backtrace with FRAME_POINTER enabled the kernel needs a specific function prologue: mov ip, sp stmfd sp!, {fp, ip, lr, pc} sub fp, ip, #4 To get to the required prologue gcc uses apcs and no-sched-prolog. This compiler options are not available on clang, and clang is not able to generate the required prologue. Make the FRAME_POINTER config symbol depending on !clang. Suggested-by: Arnd Bergmann Signed-off-by: Stefan Agner Reviewed-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Anders Roxell Signed-off-by: Greg Kroah-Hartman

mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO

2021-12-22T08:18:01Z

commit 6a953dc4dbd1c7057fb765a24f37a5e953c85fb0 upstream. A new warning in clang points out when macro expansion might result in a GNU C statement expression. There is an instance of this in the mwifiex driver: drivers/net/wireless/marvell/mwifiex/cmdevt.c:217:34: warning: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Wcompound-token-split-by-macro] host_cmd->seq_num = cpu_to_le16(HostCmd_SET_SEQ_NO_BSS_INFO ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/marvell/mwifiex/fw.h:519:46: note: expanded from macro 'HostCmd_SET_SEQ_NO_BSS_INFO' (((type) & 0x000f) << 12); } ^ This does not appear to be a real issue. Removing the braces and replacing them with parentheses will fix the warning and not change the meaning of the code. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Link: https://github.com/ClangBuiltLinux/linux/issues/1146 Reported-by: Andy Lavr Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200901070834.1015754-1-natechancellor@gmail.com Signed-off-by: Anders Roxell Signed-off-by: Greg Kroah-Hartman

ARM: 8805/2: remove unneeded naked function usage

2021-12-22T08:18:01Z

commit b99afae1390140f5b0039e6b37a7380de31ae874 upstream. The naked attribute is known to confuse some old gcc versions when function arguments aren't explicitly listed as inline assembly operands despite the gcc documentation. That resulted in commit 9a40ac86152c ("ARM: 6164/1: Add kto and kfrom to input operands list."). Yet that commit has problems of its own by having assembly operand constraints completely wrong. If the generated code has been OK since then, it is due to luck rather than correctness. So this patch also provides proper assembly operand constraints, and removes two instances of redundant register usages in the implementation while at it. Inspection of the generated code with this patch doesn't show any obvious quality degradation either, so not relying on __naked at all will make the code less fragile, and avoid some issues with clang. The only remaining __naked instances (excluding the kprobes test cases) are exynos_pm_power_up_setup(), tc2_pm_power_up_setup() and cci_enable_port_for_self(. But in the first two cases, only the function address is used by the compiler with no chance of inlining it by mistake, and the third case is called from assembly code only. And the fact that no stack is available when the corresponding code is executed does warrant the __naked usage in those cases. Signed-off-by: Nicolas Pitre Reviewed-by: Stefan Agner Tested-by: Stefan Agner Signed-off-by: Russell King Signed-off-by: Anders Roxell Signed-off-by: Greg Kroah-Hartman