3.16.67-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Ben Hutchings ben@decadent.org.uk

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 ben@decadent.org.uk --- --- a/kernel/time/timer_stats.c +++ b/kernel/time/timer_stats.c @@ -417,7 +417,7 @@ static int __init init_tstats_procfs(voi { struct proc_dir_entry *pe;

- pe = proc_create("timer_stats", 0644, NULL, &tstats_fops); + pe = proc_create("timer_stats", 0600, NULL, &tstats_fops); if (!pe) return -ENOMEM; return 0;

3.16.67-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: David Herrmann dh.herrmann@gmail.com

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 jannh@google.com Signed-off-by: Tom Gundersen teg@jklm.no Signed-off-by: David Herrmann dh.herrmann@gmail.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org [bwh: Backported to 3.16: start_time initialisation code is different] Signed-off-by: Ben Hutchings ben@decadent.org.uk --- kernel/fork.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/kernel/fork.c +++ b/kernel/fork.c @@ -1265,9 +1265,6 @@ static struct task_struct *copy_process(

posix_cpu_timers_init(p);

- do_posix_clock_monotonic_gettime(&p->start_time); - p->real_start_time = p->start_time; - monotonic_to_bootbased(&p->real_start_time); p->io_context = NULL; p->audit_context = NULL; if (clone_flags & CLONE_THREAD) @@ -1423,6 +1420,18 @@ static struct task_struct *copy_process( p->task_works = NULL;

/* + * From this point on we must avoid any synchronous user-space + * communication until we take the tasklist-lock. In particular, we do + * not want user-space to be able to predict the process start-time by + * stalling fork(2) after we recorded the start_time but before it is + * visible to the system. + */ + + do_posix_clock_monotonic_gettime(&p->start_time); + p->real_start_time = p->start_time; + monotonic_to_bootbased(&p->real_start_time); + + /* * Make it visible to the rest of the system, but dont wake it up yet. * Need tasklist lock for parent etc handling! */

3.16.67-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Arend Van Spriel arend.vanspriel@broadcom.com

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 hante.meuleman@broadcom.com Reviewed-by: Pieter-Paul Giesberts pieter-paul.giesberts@broadcom.com Reviewed-by: Franky Lin franky.lin@broadcom.com Signed-off-by: Arend van Spriel arend.vanspriel@broadcom.com Signed-off-by: Kalle Valo kvalo@codeaurora.org [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 ben@decadent.org.uk --- drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c @@ -3033,6 +3033,7 @@ brcmf_notify_sched_scan_results(struct b struct brcmf_pno_scanresults_le *pfn_result; u32 result_count; u32 status; + u32 datalen;

brcmf_dbg(SCAN, "Enter\n");

@@ -3059,6 +3060,14 @@ brcmf_notify_sched_scan_results(struct b if (result_count > 0) { int i;

+ data += sizeof(struct brcmf_pno_scanresults_le); + netinfo_start = (struct brcmf_pno_net_info_le *)data; + datalen = e->datalen - ((void *)netinfo_start - (void *)pfn_result); + if (datalen < result_count * sizeof(*netinfo)) { + brcmf_err("insufficient event data\n"); + goto out_err; + } + request = kzalloc(sizeof(*request), GFP_KERNEL); ssid = kcalloc(result_count, sizeof(*ssid), GFP_KERNEL); channel = kcalloc(result_count, sizeof(*channel), GFP_KERNEL); @@ -3068,9 +3077,6 @@ brcmf_notify_sched_scan_results(struct b }

request->wiphy = wiphy; - data += sizeof(struct brcmf_pno_scanresults_le); - netinfo_start = (struct brcmf_pno_net_info_le *)data; - for (i = 0; i < result_count; i++) { netinfo = &netinfo_start[i]; if (!netinfo) { @@ -3080,6 +3086,8 @@ brcmf_notify_sched_scan_results(struct b goto out_err; }

+ if (netinfo->SSID_len > IEEE80211_MAX_SSID_LEN) + netinfo->SSID_len = IEEE80211_MAX_SSID_LEN; brcmf_dbg(SCAN, "SSID:%s Channel:%d\n", netinfo->SSID, netinfo->channel); memcpy(ssid[i].ssid, netinfo->SSID, netinfo->SSID_len);

3.16.67-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet edumazet@google.com

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 edumazet@google.com Fixes: 4895c771c7f00 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Ben Hutchings ben@decadent.org.uk --- include/net/ip_fib.h | 2 +- net/ipv4/fib_semantics.c | 8 +++++--- net/ipv4/route.c | 6 +++--- 3 files changed, 9 insertions(+), 7 deletions(-)

--- a/include/net/ip_fib.h +++ b/include/net/ip_fib.h @@ -89,7 +89,7 @@ struct fib_nh { int nh_saddr_genid; struct rtable __rcu * __percpu *nh_pcpu_rth_output; struct rtable __rcu *nh_rth_input; - struct fnhe_hash_bucket *nh_exceptions; + struct fnhe_hash_bucket __rcu *nh_exceptions; };

/* --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -157,9 +157,12 @@ static void rt_fibinfo_free(struct rtabl

static void free_nh_exceptions(struct fib_nh *nh) { - struct fnhe_hash_bucket *hash = nh->nh_exceptions; + struct fnhe_hash_bucket *hash; int i;

+ hash = rcu_dereference_protected(nh->nh_exceptions, 1); + if (!hash) + return; for (i = 0; i < FNHE_HASH_SIZE; i++) { struct fib_nh_exception *fnhe;

@@ -206,8 +209,7 @@ static void free_fib_info_rcu(struct rcu change_nexthops(fi) { if (nexthop_nh->nh_dev) dev_put(nexthop_nh->nh_dev); - if (nexthop_nh->nh_exceptions) - free_nh_exceptions(nexthop_nh); + free_nh_exceptions(nexthop_nh); rt_fibinfo_free_cpus(nexthop_nh->nh_pcpu_rth_output); rt_fibinfo_free(&nexthop_nh->nh_rth_input); } endfor_nexthops(fi); --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -635,12 +635,12 @@ static void update_or_create_fnhe(struct

spin_lock_bh(&fnhe_lock);

- hash = nh->nh_exceptions; + hash = rcu_dereference(nh->nh_exceptions); if (!hash) { hash = kzalloc(FNHE_HASH_SIZE * sizeof(*hash), GFP_ATOMIC); if (!hash) goto out_unlock; - nh->nh_exceptions = hash; + rcu_assign_pointer(nh->nh_exceptions, hash); }

hash += hval; @@ -1293,7 +1293,7 @@ static void ip_del_fnhe(struct fib_nh *n

static struct fib_nh_exception *find_exception(struct fib_nh *nh, __be32 daddr) { - struct fnhe_hash_bucket *hash = nh->nh_exceptions; + struct fnhe_hash_bucket *hash = rcu_dereference(nh->nh_exceptions); struct fib_nh_exception *fnhe; u32 hval;

3.16.67-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel jroedel@suse.de

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 jroedel@suse.de Signed-off-by: Ben Hutchings ben@decadent.org.uk --- arch/x86/kvm/vmx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4224,7 +4224,9 @@ static u8 vmx_msr_bitmap_mode(struct kvm { u8 mode = 0;

- if (irqchip_in_kernel(vcpu->kvm) && apic_x2apic_mode(vcpu->arch.apic)) { + if (cpu_has_secondary_exec_ctrls() && + (vmcs_read32(SECONDARY_VM_EXEC_CONTROL) & + SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE)) { mode |= MSR_BITMAP_MODE_X2APIC; if (enable_apicv) mode |= MSR_BITMAP_MODE_X2APIC_APICV;