linux-stable.git/drivers/char, branch v4.1.41

virtio-console: avoid DMA from stack

2017-06-13T13:29:17+00:00

[ Upstream commit c4baad50297d84bde1a7ad45e50c73adae4a2192 ]

put_chars() stuffs the buffer it gets into an sg, but that buffer may be
on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
manifested as printks getting turned into NUL bytes).

Signed-off-by: Omar Sandoval 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Sasha Levin

mm: Tighten x86 /dev/mem with zeroing reads

2017-06-13T13:29:17+00:00

[ Upstream commit a4866aa812518ed1a37d8ea0c881dc946409de94 ]

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Kees Cook 
Signed-off-by: Sasha Levin

char: lack of bool string made CONFIG_DEVPORT always on

2017-06-13T13:29:16+00:00

[ Upstream commit f2cfa58b136e4b06a9b9db7af5ef62fbb5992f62 ]

Without a bool string present, using "# CONFIG_DEVPORT is not set" in
defconfig files would not actually unset devport. This esnured that
/dev/port was always on, but there are reasons a user may wish to
disable it (smaller kernel, attack surface reduction) if it's not being
used. Adding a message here in order to make this user visible.

Signed-off-by: Max Bires 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

char: Drop bogus dependency of DEVPORT on !M68K

2017-06-13T13:29:16+00:00

[ Upstream commit 309124e2648d668a0c23539c5078815660a4a850 ]

According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
defined.

However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional
on isa i/o support") accidentally changed an "||" into an "&&",
disabling it completely on m68k. This logic was retained when
introducing the DEVPORT symbol in commit 4f911d64e04a44c4 ("Make
/dev/port conditional on config symbol").

Drop the bogus dependency on !M68K to fix this.

Fixes: 153dcc54df826d2f ("[PATCH] mem driver: fix conditional on isa i/o support")
Signed-off-by: Geert Uytterhoeven 
Tested-by: Al Stone 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

drivers: char: mem: Check for address space wraparound with mmap()

2017-06-08T10:12:47+00:00

[ Upstream commit b299cde245b0b76c977f4291162cf668e087b408 ]

/dev/mem currently allows mmap() mappings that wrap around the end of
the physical address space, which should probably be illegal. It
circumvents the existing STRICT_DEVMEM permission check because the loop
immediately terminates (as the start address is already higher than the
end address). On the x86_64 architecture it will then cause a panic
(from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()).

This patch adds an explicit check to make sure offset + size will not
wrap around in the physical address type.

Signed-off-by: Julius Werner 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

char: lp: fix possible integer overflow in lp_setup()

2017-06-08T10:12:46+00:00

[ Upstream commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 ]

The lp_setup() code doesn't apply any bounds checking when passing
"lp=none", and only in this case, resulting in an overflow of the
parport_nr[] array. All versions in Git history are affected.

Reported-By: Roee Hay 
Cc: Ben Hutchings 
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

ipmi: Fix kernel panic at ipmi_ssif_thread()

2017-05-17T19:08:21+00:00

[ Upstream commit 6de65fcfdb51835789b245203d1bfc8d14cb1e06 ]

msg_written_handler() may set ssif_info->multi_data to NULL
when using ipmitool to write fru.

Before setting ssif_info->multi_data to NULL, add new local
pointer "data_to_send" and store correct i2c data pointer to
it to fix NULL pointer kernel panic and incorrect ssif_info->multi_pos.

Signed-off-by: Joeseph Chang 
Signed-off-by: Corey Minyard 
Cc: stable@vger.kernel.org # 3.19-
Signed-off-by: Sasha Levin

tpm: add sleep only for retry in i2c_nuvoton_write_status()

2017-05-17T19:08:20+00:00

[ Upstream commit 0afb7118ae021e80ecf70f5a3336e0935505518a ]

Currently, there is an unnecessary 1 msec delay added in
i2c_nuvoton_write_status() for the successful case. This
function is called multiple times during send() and recv(),
which implies adding multiple extra delays for every TPM
operation.

This patch calls usleep_range() only if retry is to be done.

Signed-off-by: Nayna Jain 
Cc: stable@vger.kernel.org (linux-4.8)
Reviewed-by: Mimi Zohar 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

tpm_crb: check for bad response size

2017-05-17T19:08:20+00:00

[ Upstream commit 8569defde8057258835c51ce01a33de82e14b148 ]

Make sure size of response buffer is at least 6 bytes, or
we will underflow and pass large size_t to memcpy_fromio().
This was encountered while testing earlier version of
locality patchset.

Cc: stable@vger.kernel.org
Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jerry Snitselaar 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

tpm: msleep() delays - replace with usleep_range() in i2c nuvoton driver

2017-05-17T19:08:20+00:00

[ Upstream commit a233a0289cf9a96ef9b42c730a7621ccbf9a6f98 ]

Commit 500462a9de65 "timers: Switch to a non-cascading wheel" replaced
the 'classic' timer wheel, which aimed for near 'exact' expiry of the
timers.  Their analysis was that the vast majority of timeout timers
are used as safeguards, not as real timers, and are cancelled or
rearmed before expiration.  The only exception noted to this were
networking timers with a small expiry time.

Not included in the analysis was the TPM polling timer, which resulted
in a longer normal delay and, every so often, a very long delay.  The
non-cascading wheel delay is based on CONFIG_HZ.  For a description of
the different rings and their delays, refer to the comments in
kernel/time/timer.c.

Below are the delays given for rings 0 - 2, which explains the longer
"normal" delays and the very, long delays as seen on systems with
CONFIG_HZ 250.

* HZ 1000 steps
 * Level Offset  Granularity            Range
 *  0      0         1 ms                0 ms - 63 ms
 *  1     64         8 ms               64 ms - 511 ms
 *  2    128        64 ms              512 ms - 4095 ms (512ms - ~4s)

* HZ  250
 * Level Offset  Granularity            Range
 *  0      0         4 ms                0 ms - 255 ms
 *  1     64        32 ms              256 ms - 2047 ms (256ms - ~2s)
 *  2    128       256 ms             2048 ms - 16383 ms (~2s - ~16s)

Below is a comparison of extending the TPM with 1000 measurements,
using msleep() vs. usleep_delay() when configured for 1000 hz vs. 250
hz, before and after commit 500462a9de65.

linux-4.7 | msleep() usleep_range()
1000 hz: 0m44.628s | 1m34.497s 29.243s
250 hz: 1m28.510s | 4m49.269s 32.386s

linux-4.7  | min-max (msleep)  min-max (usleep_range)
1000 hz: 0:017 - 2:760s | 0:015 - 3:967s    0:014 - 0:418s
250 hz: 0:028 - 1:954s | 0:040 - 4:096s    0:016 - 0:816s

This patch replaces the msleep() with usleep_range() calls in the
i2c nuvoton driver with a consistent max range value.

Signed-of-by: Mimi Zohar 
Cc: stable@vger.kernel.org (linux-4.8)
Signed-off-by: Nayna Jain 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin