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

virtio_console: free buffers after reset

2018-05-23T01:36:37+00:00

[ Upstream commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b ]

Console driver is out of spec. The spec says:
	A driver MUST NOT decrement the available idx on a live
	virtqueue (ie. there is no way to “unexpose” buffers).
and it does exactly that by trying to detach unused buffers
without doing a device reset first.

Defer detaching the buffers until device unplug.

Of course this means we might get an interrupt for
a vq without an attached port now. Handle that by
discarding the consumed buffer.

Reported-by: Tiwei Bie 
Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach")
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

random: use a tighter cap in credit_entropy_bits_safe()

2018-05-23T01:36:33+00:00

[ Upstream commit 9f886f4d1d292442b2f22a0a33321eae821bde40 ]

This fixes a harmless UBSAN where root could potentially end up
causing an overflow while bumping the entropy_total field (which is
ignored once the entropy pool has been initialized, and this generally
is completed during the boot sequence).

This is marginal for the stable kernel series, but it's a really
trivial patch, and it fixes UBSAN warning that might cause security
folks to get overly excited for no reason.

Signed-off-by: Theodore Ts'o 
Reported-by: Chen Feng 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

random: use lockless method of accessing and updating f->reg_idx

2018-05-23T01:36:30+00:00

[ Upstream commit 92e75428ffc90e2a0321062379f883f3671cfebe ]

Linus pointed out that there is a much more efficient way of avoiding
the problem that we were trying to address in commit 9dfa7bba35ac0:
"fix race in drivers/char/random.c:get_reg()".

Signed-off-by: Theodore Ts'o 
Signed-off-by: Sasha Levin

fix race in drivers/char/random.c:get_reg()

2018-05-23T01:36:25+00:00

[ Upstream commit 9dfa7bba35ac08a63565d58c454dccb7e1bb0a08 ]

get_reg() can be reentered on architectures with prioritized interrupts
(m68k in this case), causing f->reg_index to be incremented after the
range check. Out of bounds memory access past the pt_regs struct results.
This will go mostly undetected unless access is beyond end of memory.

Prevent the race by disabling interrupts in get_reg().

Tested on m68k (Atari Falcon, and ARAnyM emulator).

Kudos to Geert Uytterhoeven for helping to trace this race.

Signed-off-by: Michael Schmitz 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Sasha Levin

ipmi_ssif: unlock on allocation failure

2018-05-23T01:36:23+00:00

[ Upstream commit cf9806f32ef63b745f2486e0dbb2ac21f4ca44f0 ]

We should unlock and re-enable IRQs if this allocation fails.

Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF) ")
Signed-off-by: Dan Carpenter 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

ipmi/watchdog: fix wdog hang on panic waiting for ipmi response

2018-05-23T01:33:50+00:00

[ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]

Commit c49c097610fe ("ipmi: Don't call receive handler in the
panic context") means that the panic_recv_free is not called during a
panic and the atomic count does not drop to 0.

Fix this by only expecting one decrement of the atomic variable
which comes from panic_smi_free.

Signed-off-by: Robert Lippert 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

tpm_tis: fix potential buffer overruns caused by bit glitches on the bus

2018-05-23T01:33:48+00:00

[ Upstream commit 6bb320ca4a4a7b5b3db8c8d7250cc40002046878 ]

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Tested-by: Jarkko Sakkinen 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin

agp/intel: Flush all chipset writes after updating the GGTT

2018-05-23T01:33:47+00:00

[ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]

Before accessing the GGTT we must flush the PTE writes and make them
visible to the chipset, or else the indirect access may end up in the
wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes
after updating a single PTE"), we noticed corruption of the uploads for
pwrite and for capturing GPU error states, but it was presumed that the
explicit calls to intel_gtt_chipset_flush() were sufficient for the
execbuffer path. However, we have not been flushing the chipset between
the PTE writes and access via the GTT itself.

For simplicity, do the flush after any PTE update rather than try and
batch the flushes on a just-in-time basis.

References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: drm-intel-fixes@lists.freedesktop.org
Reviewed-by: Joonas Lahtinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20171208214616.30147-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin

tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus

2018-03-21T03:49:46+00:00

[ Upstream commit f9d4d9b5a5ef2f017bc344fb65a58a902517173b ]

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin

tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus

2018-03-21T03:49:46+00:00

[ Upstream commit 9b8cb28d7c62568a5916bdd7ea1c9176d7f8f2ed ]

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin