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

virtio_console: fix a crash in config_work_handler

2017-07-31T17:37:50+00:00

[ Upstream commit 8379cadf71c3ee8173a1c6fc1ea7762a9638c047 ]

Using control_work instead of config_work as the 3rd argument to
container_of results in an invalid portdev pointer. Indeed, the work
structure is initialized as below:

    INIT_WORK(&portdev->config_work, &config_work_handler);

It leads to a crash when portdev->vdev is dereferenced later. This
bug
is triggered when the guest uses a virtio-console without multiport
feature and receives a config_changed virtio interrupt.

Signed-off-by: G. Campana 
Reviewed-by: Amit Shah 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

random: properly align get_random_int_hash

2017-07-26T23:25:36+00:00

[ Upstream commit b1132deac01c2332d234fa821a70022796b79182 ]

get_random_long() reads from the get_random_int_hash array using an
unsigned long pointer.  For this code to be guaranteed correct on all
architectures, the array must be aligned to an unsigned long boundary.

Cc: stable@kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Sasha Levin

drivers: char: random: add get_random_long()

2017-07-26T23:25:36+00:00

[ Upstream commit ec9ee4acd97c0039a61c0ae4f12705767ae62153 ]

Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base
ASLR") added the ability to choose from a range of values to use for
entropy count in generating the random offset to the mmap_base address.

The maximum value on this range was set to 32 bits for 64-bit x86
systems, but this value could be increased further, requiring more than
the 32 bits of randomness provided by get_random_int(), as is already
possible for arm64.  Add a new function: get_random_long() which more
naturally fits with the mmap usage of get_random_int() but operates
exactly the same as get_random_int().

Also, fix the shifting constant in mmap_rnd() to be an unsigned long so
that values greater than 31 bits generate an appropriate mask without
overflow.  This is especially important on x86, as its shift instruction
uses a 5-bit mask for the shift operand, which meant that any value for
mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base
randomization.

Finally, replace calls to get_random_int() with get_random_long() where
appropriate.

This patch (of 2):

Add get_random_long().

Signed-off-by: Daniel Cashman 
Acked-by: Kees Cook 
Cc: "Theodore Ts'o" 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: David S. Miller 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Al Viro 
Cc: Nick Kralevich 
Cc: Jeff Vander Stoep 
Cc: Mark Salyzyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

drivers: char: mem: Fix wraparound check to allow mappings up to the end

2017-06-26T02:02:20+00:00

[ Upstream commit 32829da54d9368103a2f03269a5120aa9ee4d5da ]

A recent fix to /dev/mem prevents mappings from wrapping around the end
of physical address space. However, the check was written in a way that
also prevents a mapping reaching just up to the end of physical address
space, which may be a valid use case (especially on 32-bit systems).
This patch fixes it by checking the last mapped address (instead of the
first address behind that) for overflow.

Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()")
Cc: 
Reported-by: Nico Huber 
Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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