linux-stable.git/drivers/misc, branch v3.16.63

misc: atmel-ssc: Fix section annotation on atmel_ssc_get_driver_data

2019-02-11T17:53:59+00:00

commit 7c97301285b62a41d6bceded7d964085fc8cc50f upstream.

After building the kernel with Clang, the following section mismatch
warning appears:

WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from
the function ssc_probe() to the function
.init.text:atmel_ssc_get_driver_data()
The function ssc_probe() references
the function __init atmel_ssc_get_driver_data().
This is often because ssc_probe lacks a __init
annotation or the annotation of atmel_ssc_get_driver_data is wrong.

Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch.

Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

drivers/misc/sgi-gru: fix Spectre v1 vulnerability

2019-02-11T17:53:59+00:00

commit fee05f455ceb5c670cbe48e2f9454ebc4a388554 upstream.

req.gid can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
potential spectre issue 'gru_base' [w]

Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
uses it to index gru_base.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

VMCI: Resource wildcard match fixed

2019-02-11T17:53:25+00:00

commit 11924ba5e671d6caef1516923e2bd8c72929a3fe upstream.

When adding a VMCI resource, the check for an existing entry
would ignore that the new entry could be a wildcard. This could
result in multiple resource entries that would match a given
handle. One disastrous outcome of this is that the
refcounting used to ensure that delayed callbacks for VMCI
datagrams have run before the datagram is destroyed can be
wrong, since the refcount could be increased on the duplicate
entry. This in turn leads to a use after free bug. This issue
was discovered by Hangbin Liu using KASAN and syzkaller.

Fixes: bc63dedb7d46 ("VMCI: resource object implementation")
Reported-by: Hangbin Liu 
Reviewed-by: Adit Ranadive 
Reviewed-by: Vishnu Dasa 
Signed-off-by: Jorgen Hansen 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: Drop the version change.]
Signed-off-by: Ben Hutchings

signal/GenWQE: Fix sending of SIGKILL

2019-02-11T17:53:18+00:00

commit 0ab93e9c99f8208c0a1a7b7170c827936268c996 upstream.

The genweq_add_file and genwqe_del_file by caching current without
using reference counting embed the assumption that a file descriptor
will never be passed from one process to another.  It even embeds the
assumption that the the thread that opened the file will be in
existence when the process terminates.   Neither of which are
guaranteed to be true.

Therefore replace caching the task_struct of the opener with
pid of the openers thread group id.  All the knowledge of the
opener is used for is as the target of SIGKILL and a SIGKILL
will kill the entire process group.

Rename genwqe_force_sig to genwqe_terminate, remove it's unncessary
signal argument, update it's ownly caller, and use kill_pid
instead of force_sig.

The work force_sig does in changing signal handling state is not
relevant to SIGKILL sent as SEND_SIG_PRIV.  The exact same processess
will be killed just with less work, and less confusion.  The work done
by force_sig is really only needed for handling syncrhonous
exceptions.

It will still be possible to cause genwqe_device_remove to wait
8 seconds by passing a file descriptor to another process but
the possible user after free is fixed.

Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Cc: Greg Kroah-Hartman 
Cc: Frank Haverkamp 
Cc: Joerg-Stephan Vogt 
Cc: Michael Jung 
Cc: Michael Ruettger 
Cc: Kleber Sacilotto de Souza 
Cc: Sebastian Ott 
Cc: Eberhard S. Amann 
Cc: Gabriel Krisman Bertazi 
Cc: Guilherme G. Piccoli 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Ben Hutchings

misc: hmc6352: fix potential Spectre v1

2018-12-16T22:09:16+00:00

commit de916736aaaadddbd6061472969f667b14204aa9 upstream.

val is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue
'map' [r]

Fix this by sanitizing val before using it to index map

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

mei: bus: type promotion bug in mei_nfc_if_version()

2018-12-16T22:08:14+00:00

commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream.

We accidentally removed the check for negative returns
without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv()
returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.

Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
Signed-off-by: Dan Carpenter 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

vmci: type promotion bug in qp_host_get_user_memory()

2018-12-16T22:08:12+00:00

commit 7fb2fd4e25fc1fb10dcb30b5519de257cfeae84c upstream.

The problem is that if get_user_pages_fast() fails and returns a
negative error code, it gets type promoted to a high positive value and
treated as a success.

Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ibmasm: don't write out of bounds in read handler

2018-11-20T18:05:38+00:00

commit a0341fc1981a950c1e902ab901e98f60e0e243f3 upstream.

This read handler had a lot of custom logic and wrote outside the bounds of
the provided buffer. This could lead to kernel and userspace memory
corruption. Just use simple_read_from_buffer() with a stack buffer.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jann Horn 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

lkdtm: fix handle_irq_event symbol for INT_HW_IRQ_EN

2018-06-16T21:22:00+00:00

commit 5be2a5011c039506e2862650c928acfb2e3d7b9c upstream.

Function handle_IRQ_event was retired in v2.6.39 and replaced with
handle_irq_event but nobody changed it in lkdtm so INT_HW_IRQ_EN has
been broken for a while.

Fixes: 33b054b867b8 ("genirq: Remove handle_IRQ_event")
Signed-off-by: Travis Brown 
Signed-off-by: Ivan Delalande 
Acked-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

eeprom: at24: check at24_read/write arguments

2018-03-03T15:51:38+00:00

commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream.

So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Ben Hutchings