commit e4b618abfdb771996e069335d8a648c43fb61643
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat May 11 15:22:50 2019 +0100
Linux 3.16.67
commit 14c2d9209a135872def8508e3f19c74f0f3fee52
Author: Matteo Croce <mcroce@redhat.com>
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 <mcroce@redhat.com>
Signed-off-by: Dennis Zhou <dennis@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 07efa228ff7bfadaf50f0daa63a228d055f232ce
Author: Ben Hutchings <ben@decadent.org.uk>
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 <ben@decadent.org.uk>
commit 971081984266d7934b2f0253215e3f31f9337915
Author: David Herrmann <dh.herrmann@gmail.com>
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 <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>
commit 1348f9af79db25e4e0c6475c5511e11969e82abc
Author: Joerg Roedel <jroedel@suse.de>
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 <jroedel@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 73bbb7ec88d4b277691daa9c846f83a546dfa2b0
Author: Eric Dumazet <edumazet@google.com>
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 <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>
commit 142dcb12448f4e0826d6bb0b5a4e870270f5458a
Author: Ben Hutchings <ben@decadent.org.uk>
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 <ben@decadent.org.uk>
commit 4534e6e7ffd81ec5ceb782d44e45f295391568d4
Author: Nick Krause <xerofoiffy@gmail.com>
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 <xerofoiffy@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 8b197d3ce585d6777197e0633d71e5af7d98cb35
Author: Amit Klein <aksecurity@gmail.com>
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 <aksecurity@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 725e0dd2d3d036a6bfb170e307ca231228ddddd0
Author: Arend Van Spriel <arend.vanspriel@broadcom.com>
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 <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>
commit c3a07631735bbfc2d099e89dc6bea85c8eb38a52
Author: Ben Hutchings <ben@decadent.org.uk>
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 <ben@decadent.org.uk>