commit e4b618abfdb771996e069335d8a648c43fb61643 Author: Ben Hutchings Date: Sat May 11 15:22:50 2019 +0100 Linux 3.16.67 commit 14c2d9209a135872def8508e3f19c74f0f3fee52 Author: Matteo Croce Date: Mon Mar 18 02:32:36 2019 +0100 percpu: stop printing kernel addresses commit 00206a69ee32f03e6f40837684dcbe475ea02266 upstream. Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"), at boot "____ptrval____" is printed instead of actual addresses: percpu: Embedded 38 pages/cpu @(____ptrval____) s124376 r0 d31272 u524288 Instead of changing the print to "%px", and leaking kernel addresses, just remove the print completely, cfr. e.g. commit 071929dbdd865f77 ("arm64: Stop printing the virtual memory layout"). Signed-off-by: Matteo Croce Signed-off-by: Dennis Zhou Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 07efa228ff7bfadaf50f0daa63a228d055f232ce Author: Ben Hutchings Date: Mon Feb 11 19:07:32 2019 +0000 timer/debug: Change /proc/timer_stats from 0644 to 0600 The timer_stats facility should filter and translate PIDs if opened from a non-initial PID namespace, to avoid leaking information about the wider system. It should also not show kernel virtual addresses. Unfortunately it has now been removed upstream (as redundant) instead of being fixed. For stable, fix the leak by restricting access to root only. A similar change was already made for the /proc/timer_list file. Signed-off-by: Ben Hutchings commit 971081984266d7934b2f0253215e3f31f9337915 Author: David Herrmann Date: Tue Jan 8 13:58:52 2019 +0100 fork: record start_time late commit 7b55851367136b1efd84d98fea81ba57a98304cf upstream. This changes the fork(2) syscall to record the process start_time after initializing the basic task structure but still before making the new process visible to user-space. Technically, we could record the start_time anytime during fork(2). But this might lead to scenarios where a start_time is recorded long before a process becomes visible to user-space. For instance, with userfaultfd(2) and TLS, user-space can delay the execution of fork(2) for an indefinite amount of time (and will, if this causes network access, or similar). By recording the start_time late, it much closer reflects the point in time where the process becomes live and can be observed by other processes. Lastly, this makes it much harder for user-space to predict and control the start_time they get assigned. Previously, user-space could fork a process and stall it in copy_thread_tls() before its pid is allocated, but after its start_time is recorded. This can be misused to later-on cycle through PIDs and resume the stalled fork(2) yielding a process that has the same pid and start_time as a process that existed before. This can be used to circumvent security systems that identify processes by their pid+start_time combination. Even though user-space was always aware that start_time recording is flaky (but several projects are known to still rely on start_time-based identification), changing the start_time to be recorded late will help mitigate existing attacks and make it much harder for user-space to control the start_time a process gets assigned. Reported-by: Jann Horn Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: start_time initialisation code is different] Signed-off-by: Ben Hutchings commit 1348f9af79db25e4e0c6475c5511e11969e82abc Author: Joerg Roedel Date: Thu Feb 21 15:30:48 2019 +0000 KVM: VMX: Fix x2apic check in vmx_msr_bitmap_mode() The stable backport of upstream commit 904e14fb7cb96 KVM: VMX: make MSR bitmaps per-VCPU has a bug in vmx_msr_bitmap_mode(). It enables the x2apic MSR-bitmap when the kernel emulates x2apic for the guest in software. The upstream version of the commit checkes whether the hardware has virtualization enabled for x2apic emulation. Since KVM emulates x2apic for guests even when the host does not support x2apic in hardware, this causes the intercept of at least the X2APIC_TASKPRI MSR to be disabled on machines not supporting that MSR. The result is undefined behavior, on some machines (Intel Westmere based) it causes a crash of the guest kernel when it tries to access that MSR. Change the check in vmx_msr_bitmap_mode() to match the upstream code. This fixes the guest crashes observed with stable kernels starting with v4.4.168 through v4.4.175. Signed-off-by: Joerg Roedel Signed-off-by: Ben Hutchings commit 73bbb7ec88d4b277691daa9c846f83a546dfa2b0 Author: Eric Dumazet Date: Wed Sep 3 22:21:56 2014 -0700 ipv4: fix a race in update_or_create_fnhe() commit caa415270c732505240bb60171c44a7838c555e8 upstream. nh_exceptions is effectively used under rcu, but lacks proper barriers. Between kzalloc() and setting of nh->nh_exceptions(), we need a proper memory barrier. Signed-off-by: Eric Dumazet Fixes: 4895c771c7f00 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 142dcb12448f4e0826d6bb0b5a4e870270f5458a Author: Ben Hutchings Date: Tue May 7 19:17:39 2019 +0100 vxlan: Fix big-endian declaration of VNI In this version of the driver, VNIs are consistently kept in host order. However vxlan_fdb_create() erroneously declares its vni parameter as __be32, which sparse warns about. Change it to __u32. This was resolved upstream by commit 54bfd872bf16 "vxlan: keep flags and vni in network byte order". Signed-off-by: Ben Hutchings commit 4534e6e7ffd81ec5ceb782d44e45f295391568d4 Author: Nick Krause Date: Wed Aug 6 13:53:17 2014 -0400 spi: omap-100k: Remove unused definitions commit 9f5b8b4f56dd194fd33021810636879036d2acdd upstream. Remove unused definition which cause the following warnings drivers/spi/spi-omap-100k.c:73:0: warning: "WRITE" redefined [enabled by default] include/linux/fs.h:193:0: note: this is the location of the previous definition drivers/spi/spi-omap-100k.c:74:0: warning: "READ" redefined [enabled by default] include/linux/fs.h:192:0: note: this is the location of the previous definition Signed-off-by: Nick Krause Acked-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 8b197d3ce585d6777197e0633d71e5af7d98cb35 Author: Amit Klein Date: Thu Apr 18 21:07:11 2019 +0000 inet: update the IP ID generation algorithm to higher standards. Commit 355b98553789 ("netns: provide pure entropy for net_hash_mix()") makes net_hash_mix() return a true 32 bits of entropy. When used in the IP ID generation algorithm, this has the effect of extending the IP ID generation key from 32 bits to 64 bits. However, net_hash_mix() is only used for IP ID generation starting with kernel version 4.1. Therefore, earlier kernels remain with 32-bit key no matter what the net_hash_mix() return value is. This change addresses the issue by explicitly extending the key to 64 bits for kernels older than 4.1. Signed-off-by: Amit Klein Signed-off-by: Ben Hutchings commit 725e0dd2d3d036a6bfb170e307ca231228ddddd0 Author: Arend Van Spriel Date: Thu Apr 6 13:14:40 2017 +0100 brcmfmac: add length checks in scheduled scan result handler commit 4835f37e3bafc138f8bfa3cbed2920dd56fed283 upstream. Assure the event data buffer is long enough to hold the array of netinfo items and that SSID length does not exceed the maximum of 32 characters as per 802.11 spec. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo [bwh: Backported to 3.16: - Move the assignment to "data" along with the assignment to "netinfo_start" that depends on it - Adjust filename, context, indentation] Signed-off-by: Ben Hutchings commit c3a07631735bbfc2d099e89dc6bea85c8eb38a52 Author: Ben Hutchings Date: Tue May 7 18:46:58 2019 +0100 Revert "brcmfmac: assure SSID length from firmware is limited" This reverts commit 9657f3abd17772d3290a3545dfb4811d945e84e1, which was similar to commit 1b5e2423164b3670e8bc9174e4762d297990deff upstream. The function fixed upstream doesn't exist in 3.16 and the similar bug that does exist here needs a different fix. Signed-off-by: Ben Hutchings