linux-stable.git/drivers/char, branch linux-3.10.y

virtio-console: avoid DMA from stack

2017-06-20T12:04:47+00:00

commit c4baad50297d84bde1a7ad45e50c73adae4a2192 upstream.

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 
Cc: Ben Hutchings 
Cc: Brad Spengler 
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

mm: Tighten x86 /dev/mem with zeroing reads

2017-06-20T12:04:46+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

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 
Cc: Brad Spengler 
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

char: lack of bool string made CONFIG_DEVPORT always on

2017-06-20T12:04:45+00:00

commit f2cfa58b136e4b06a9b9db7af5ef62fbb5992f62 upstream.

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: Jiri Slaby 
Signed-off-by: Willy Tarreau

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

2017-06-07T22:47:12+00:00

commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 upstream.

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 
Signed-off-by: Willy Tarreau

char: Drop bogus dependency of DEVPORT on !M68K

2017-06-07T22:47:07+00:00

commit 309124e2648d668a0c23539c5078815660a4a850 upstream.

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: Jiri Slaby 
Signed-off-by: Willy Tarreau

hwrng: omap - Only fail if pm_runtime_get_sync returns < 0

2017-02-10T10:03:33+00:00

commit ad8529fde9e3601180a839867a8ab041109aebb5 upstream.

Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.

Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach 
Signed-off-by: Herbert Xu 
Signed-off-by: Willy Tarreau

hwrng: omap - Fix assumption that runtime_get_sync will always succeed

2017-02-10T10:03:33+00:00

commit 61dc0a446e5d08f2de8a24b45f69a1e302bb1b1b upstream.

pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.

Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]

After the proper checks:
[   94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[   94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[   94.382351] omap_rng 48090000.rng: initialization failed.

Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley 
Signed-off-by: Nishanth Menon 
Signed-off-by: Herbert Xu 
[wt: adjusted context for pre-3.12-rc1 kernels]

Signed-off-by: Willy Tarreau

hwrng: exynos - Disable runtime PM on probe failure

2017-02-10T10:03:33+00:00

commit 48a61e1e2af8020f11a2b8f8dc878144477623c6 upstream.

Add proper error path (for disabling runtime PM) when registering of
hwrng fails.

Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Willy Tarreau

x86/mm/pat, /dev/mem: Remove superfluous error message

2017-02-06T22:32:51+00:00

commit 39380b80d72723282f0ea1d1bbf2294eae45013e upstream.

Currently it's possible for broken (or malicious) userspace to flood a
kernel log indefinitely with messages a-la

	Program dmidecode tried to access /dev/mem between f0000->100000

because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on
dumps this information each and every time devmem_is_allowed() fails.

Reportedly userspace that is able to trigger contignuous flow of these
messages exists.

It would be possible to rate limit this message, but that'd have a
questionable value; the administrator wouldn't get information about all
the failing accessess, so then the information would be both superfluous
and incomplete at the same time :)

Returning EPERM (which is what is actually happening) is enough indication
for userspace what has happened; no need to log this particular error as
some sort of special condition.

Signed-off-by: Jiri Kosina 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pm
Signed-off-by: Ingo Molnar 
Signed-off-by: Willy Tarreau

vTPM: fix memory allocation flag for rtce buffer at kernel boot

2016-02-19T22:22:38+00:00

commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream.

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman