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

ipmi:bt: Set the timeout before doing a capabilities check

2018-07-03T09:21:28+00:00

commit fe50a7d0393a552e4539da2d31261a59d6415950 upstream.

There was one place where the timeout value for an operation was
not being set, if a capabilities request was done from idle.  Move
the timeout value setting to before where that change might be
requested.

IMHO the cause here is the invisible returns in the macros.  Maybe
that's a job for later, though.

Reported-by: Nordmark Claes 
Signed-off-by: Corey Minyard 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

2018-06-16T07:54:24+00:00

commit 362f924b64ba0f4be2ee0cb697690c33d40be721 upstream.

Those are stupid and code should use static_cpu_has_safe() or
boot_cpu_has() instead. Kill the least used and unused ones.

The remaining ones need more careful inspection before a conversion can
happen. On the TODO.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1449481182-27541-4-git-send-email-bp@alien8.de
Cc: David Sterba 
Cc: Herbert Xu 
Cc: Peter Zijlstra 
Cc: Matt Mackall 
Cc: Chris Mason 
Cc: Josef Bacik 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

tpm: self test failure should not cause suspend to fail

2018-06-13T14:15:27+00:00

commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream.

The Acer Acer Veriton X4110G has a TPM device detected as:
  tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)

After the first S3 suspend, the following error appears during resume:
  tpm tpm0: A TPM error(38) occurred continue selftest

Any following S3 suspend attempts will now fail with this error:
  tpm tpm0: Error (38) sending savestate before suspend
  PM: Device 00:0b failed to suspend: error 38

Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.

The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.

The platform behaviour seems broken here, but we should not break
suspend/resume because of this.

When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.

Cc: stable@vger.kernel.org
Signed-off-by: Chris Chiu 
Signed-off-by: Daniel Drake 
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm: do not suspend/resume if power stays on

2018-06-13T14:15:27+00:00

commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream.

The suspend/resume behavior of the TPM can be controlled by setting
"powered-while-suspended" in the DTS. This is useful for the cases
when hardware does not power-off the TPM.

Signed-off-by: Sonny Rao 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

hwrng: stm32 - add reset during probe

2018-05-30T05:49:14+00:00

[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ]

Avoid issue when probing the RNG without
reset if bad status has been detected previously

Signed-off-by: Lionel Debieve 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ipmi_ssif: Fix kernel panic at msg_done_handler

2018-05-30T05:49:12+00:00

[ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ]

This happens when BMC doesn't return any data and the code is trying
to print the value of data[2].

Getting following crash:
[  484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002
[  484.736496] pgd = ffff0000094a2000
[  484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000
[  484.748158] Internal error: Oops: 96000005 [#1] SMP
[...]
[  485.101451] Call trace:
[...]
[  485.188473] [] msg_done_handler+0x668/0x700 [ipmi_ssif]
[  485.195249] [] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif]
[  485.202038] [] kthread+0x108/0x138
[  485.206994] [] ret_from_fork+0x10/0x30
[  485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)

Adding a check to validate the data len before printing data[2] to fix this issue.

Signed-off-by: Kamlakant Patel 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ipmi/powernv: Fix error return code in ipmi_powernv_probe()

2018-05-30T05:48:54+00:00

[ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]

Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.

Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
Signed-off-by: Wei Yongjun 
Reviewed-by: Alexey Kardashevskiy 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

virtio_console: free buffers after reset

2018-05-02T14:53:40+00:00

commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b upstream.

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: Greg Kroah-Hartman

random: use a tighter cap in credit_entropy_bits_safe()

2018-04-24T07:32:07+00:00

commit 9f886f4d1d292442b2f22a0a33321eae821bde40 upstream.

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: Greg Kroah-Hartman

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

2018-04-13T17:50:24+00:00

commit 92e75428ffc90e2a0321062379f883f3671cfebe upstream.

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 
Cc: Michael Schmitz 
Signed-off-by: Greg Kroah-Hartman