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

Linux 4.9.145

2018-12-13T08:20:30Z

kbuild: allow to use GCC toolchain not in Clang search path

2018-12-13T08:20:30Z

(commit ef8c4ed9db80261f397f0c0bf723684601ae3b52 upstream) When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching assembler or linker. Make sure that Clang picks up the correct assembler or linker by passing the cross compilers bin directory as search path. This allows to use Clang provided by distributions with GCC toolchains not in /usr/bin. Link: https://github.com/ClangBuiltLinux/linux/issues/78 Signed-off-by: Stefan Agner Reviewed-and-tested-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [ND: adjusted to context, due to adjusting the context of my previous backport of upstream's ae6b289a3789] Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

kbuild: fix linker feature test macros when cross compiling with Clang

2018-12-13T08:20:30Z

(commit 86a9df597cdd564d2d29c65897bcad42519e3678 upstream) I was not seeing my linker flags getting added when using ld-option when cross compiling with Clang. Upon investigation, this seems to be due to a difference in how GCC vs Clang handle cross compilation. GCC is configured at build time to support one backend, that is implicit when compiling. Clang is explicit via the use of `-target ` and ships with all supported backends by default. GNU Make feature test macros that compile then link will always fail when cross compiling with Clang unless Clang's triple is passed along to the compiler. For example: $ clang -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: unknown architecture of input file `temp.o' is incompatible with aarch64 output aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078 $ echo $? 1 $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004002e4 $ echo $? 0 This causes conditional checks that invoke $(CC) without the target triple, then $(LD) on the result, to always fail. Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Reviewed-by: Matthias Kaehlcke Signed-off-by: Masahiro Yamada [ND: readjusted for context] Signed-off-by: Greg Kroah-Hartman

mac80211: ignore NullFunc frames in the duplicate detection

2018-12-13T08:20:30Z

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix reordering of buffered broadcast packets

2018-12-13T08:20:30Z

commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream. If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext

2018-12-13T08:20:30Z

commit a317e65face482371de30246b6494feb093ff7f9 upstream. Make it behave like regular ieee80211_tx_status calls, except for the lack of filtered frame processing. This fixes spurious low-ack triggered disconnections with powersave clients connected to an AP. Fixes: f027c2aca0cf4 ("mac80211: add ieee80211_tx_status_noskb") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: Clear beacon_int in ieee80211_do_stop

2018-12-13T08:20:30Z

commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream. This fixes stale beacon-int values that would keep a netdev from going up. To reproduce: Create two VAP on one radio. vap1 has beacon-int 100, start it. vap2 has beacon-int 240, start it (and it will fail because beacon-int mismatch). reconfigure vap2 to have beacon-int 100 and start it. It will fail because the stale beacon-int 240 will be used in the ifup path and hostapd never gets a chance to set the new beacon interval. Cc: stable@vger.kernel.org Signed-off-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211_hwsim: Timer should be initialized before device registered

2018-12-13T08:20:30Z

commit a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 upstream. Otherwise if network manager starts configuring Wi-Fi interface immidiatelly after getting notification of its creation, we will get NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] hrtimer_active+0x28/0x50 ... Call Trace: [] ? hrtimer_try_to_cancel+0x27/0x110 [] ? hrtimer_cancel+0x15/0x20 [] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim] Cc: stable@vger.kernel.org Signed-off-by: Vasyl Vavrychuk Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()

2018-12-13T08:20:30Z

commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream. This patch is trying to fix KE issue due to "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198" reported by Syzkaller scan." [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198 [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364 [26364:syz-executor0][name:report&] [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0 [26364:syz-executor0]Call trace: [26364:syz-executor0][] dump_bacIctrace+Ox0/0x470 [26364:syz-executor0][] show_stack+0x20/0x30 [26364:syz-executor0][] dump_stack+Oxd8/0x128 [26364:syz-executor0][] print_address_description +0x80/0x4a8 [26364:syz-executor0][] kasan_report+Ox178/0x390 [26364:syz-executor0][] _asan_report_loadi_noabort+Ox18/0x20 [26364:syz-executor0][] param_set_kgdboc_var+Ox194/0x198 [26364:syz-executor0][] param_attr_store+Ox14c/0x270 [26364:syz-executor0][] module_attr_store+0x60/0x90 [26364:syz-executor0][] sysfs_kl_write+Ox100/0x158 [26364:syz-executor0][] kernfs_fop_write+0x27c/0x3a8 [26364:syz-executor0][] do_loop_readv_writev+0x114/0x1b0 [26364:syz-executor0][] do_readv_writev+0x4f8/0x5e0 [26364:syz-executor0][] vfs_writev+0x7c/Oxb8 [26364:syz-executor0][] SyS_writev+Oxcc/0x208 [26364:syz-executor0][] elO_svc_naked +0x24/0x28 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]The buggy address belongs to the variable: [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]Memory state around the buggy address: [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 [26364:syz-executor0][name:report&] ^ [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [26364:syz-executor0][name:report&] [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint [26364:syz-executor0]------------[cut here]------------ After checking the source code, we've found there might be an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. Signed-off-by: Macpaul Lin Acked-by: Daniel Thompson Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

tty: do not set TTY_IO_ERROR flag if console port

2018-12-13T08:20:30Z

commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream. Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial console crash on port shutdown), a serial port which is used as console can be stuck when logging out if there is a remained process. After logged out, agetty will try to grab the serial port but it will be failed because the previous process did not release the port correctly. To fix this, TTY_IO_ERROR bit should not be enabled of tty_port_close if the port is console port. Reproduce step: - Run background processes from serial console $ while true; do sleep 10; done & - Log out $ logout -> Stuck - Read journal log by journalctl | tail Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0. Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0. Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: Geert Uytterhoeven Cc: Rob Herring Cc: Jiri Slaby Signed-off-by: Chanho Park Cc: stable Signed-off-by: Greg Kroah-Hartman