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

ipmi: fix hung processes in __get_guid()

2020-04-24T05:57:17+00:00

[ Upstream commit 32830a0534700f86366f371b150b17f0f0d140d7 ]

The wait_event() function is used to detect command completion.
When send_guid_cmd() returns an error, smi_send() has not been
called to send data. Therefore, wait_event() should not be used
on the error path, otherwise it will cause the following warning:

[ 1361.588808] systemd-udevd   D    0  1501   1436 0x00000004
[ 1361.588813]  ffff883f4b1298c0 0000000000000000 ffff883f4b188000 ffff887f7e3d9f40
[ 1361.677952]  ffff887f64bd4280 ffffc90037297a68 ffffffff8173ca3b ffffc90000000010
[ 1361.767077]  00ffc90037297ad0 ffff887f7e3d9f40 0000000000000286 ffff883f4b188000
[ 1361.856199] Call Trace:
[ 1361.885578]  [] ? __schedule+0x23b/0x780
[ 1361.951406]  [] schedule+0x36/0x80
[ 1362.010979]  [] get_guid+0x118/0x150 [ipmi_msghandler]
[ 1362.091281]  [] ? prepare_to_wait_event+0x100/0x100
[ 1362.168533]  [] ipmi_register_smi+0x405/0x940 [ipmi_msghandler]
[ 1362.258337]  [] try_smi_init+0x529/0x950 [ipmi_si]
[ 1362.334521]  [] ? std_irq_setup+0xd0/0xd0 [ipmi_si]
[ 1362.411701]  [] init_ipmi_si+0x492/0x9e0 [ipmi_si]
[ 1362.487917]  [] ? ipmi_pci_probe+0x280/0x280 [ipmi_si]
[ 1362.568219]  [] do_one_initcall+0x50/0x180
[ 1362.636109]  [] ? kmem_cache_alloc_trace+0x142/0x190
[ 1362.714330]  [] do_init_module+0x5f/0x200
[ 1362.781208]  [] load_module+0x1898/0x1de0
[ 1362.848069]  [] ? __symbol_put+0x60/0x60
[ 1362.913886]  [] ? security_kernel_post_read_file+0x6b/0x80
[ 1362.998514]  [] SYSC_finit_module+0xe5/0x120
[ 1363.068463]  [] ? SYSC_finit_module+0xe5/0x120
[ 1363.140513]  [] SyS_finit_module+0xe/0x10
[ 1363.207364]  [] do_syscall_64+0x74/0x180

Fixes: 50c812b2b951 ("[PATCH] ipmi: add full sysfs support")
Signed-off-by: Wen Yang 
Cc: Corey Minyard 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: openipmi-developer@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 2.6.17-
Message-Id: <20200403090408.58745-1-wenyang@linux.alibaba.com>
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

random: always use batched entropy for get_random_u{32,64}

2020-04-13T08:31:31+00:00

commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream.

It turns out that RDRAND is pretty slow. Comparing these two
constructions:

  for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))
    arch_get_random_long(&ret);

and

  long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
  extract_crng((u8 *)buf);

it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.

And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.

Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:

  do {
  	val = get_random_u32();
  } while (hash_table_contains_key(val));

That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.

So, this simplification seems better both from a security perspective
and from a performance perspective.

Signed-off-by: Jason A. Donenfeld 
Reviewed-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ipmi:ssif: Handle a possible NULL pointer reference

2020-03-11T06:51:11+00:00

[ Upstream commit 6b8526d3abc02c08a2f888e8c20b7ac9e5776dfe ]

In error cases a NULL can be passed to memcpy.  The length will always
be zero, so it doesn't really matter, but go ahead and check for NULL,
anyway, to be more precise and avoid static analysis errors.

Reported-by: kbuild test robot 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

ttyprintk: fix a potential deadlock in interrupt context issue

2020-02-05T13:03:40+00:00

commit 9a655c77ff8fc65699a3f98e237db563b37c439b upstream.

tpk_write()/tpk_close() could be interrupted when holding a mutex, then
in timer handler tpk_write() may be called again trying to acquire same
mutex, lead to deadlock.

Google syzbot reported this issue with CONFIG_DEBUG_ATOMIC_SLEEP
enabled:

BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:938
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/1
1 lock held by swapper/1/0:
...
Call Trace:
  
  dump_stack+0x197/0x210
  ___might_sleep.cold+0x1fb/0x23e
  __might_sleep+0x95/0x190
  __mutex_lock+0xc5/0x13c0
  mutex_lock_nested+0x16/0x20
  tpk_write+0x5d/0x340
  resync_tnc+0x1b6/0x320
  call_timer_fn+0x1ac/0x780
  run_timer_softirq+0x6c3/0x1790
  __do_softirq+0x262/0x98c
  irq_exit+0x19b/0x1e0
  smp_apic_timer_interrupt+0x1a3/0x610
  apic_timer_interrupt+0xf/0x20
  

See link https://syzkaller.appspot.com/bug?extid=2eeef62ee31f9460ad65 for
more details.

Fix it by using spinlock in process context instead of mutex and having
interrupt disabled in critical section.

Reported-by: syzbot+2eeef62ee31f9460ad65@syzkaller.appspotmail.com
Signed-off-by: Zhenzhong Duan 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20200113034842.435-1-zhenzhong.duan@gmail.com
Signed-off-by: Greg Kroah-Hartman

hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled

2020-01-04T12:34:09+00:00

[ Upstream commit eaecce12f5f0d2c35d278e41e1bc4522393861ab ]

When unloading omap3-rom-rng, we'll get the following:

WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable

This is because the clock may be already disabled by omap3_rom_rng_idle().
Let's fix the issue by checking for rng_idle on exit.

Cc: Aaro Koskinen 
Cc: Adam Ford 
Cc: Pali Rohár 
Cc: Sebastian Reichel 
Cc: Tero Kristo 
Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support")
Signed-off-by: Tony Lindgren 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

hwrng: stm32 - fix unbalanced pm_runtime_enable

2019-12-05T14:27:18+00:00

commit af0d4442dd6813de6e77309063beb064fa8e89ae upstream.

No remove function implemented yet in the driver.
Without remove function, the pm_runtime implementation
complains when removing and probing again the driver.

Signed-off-by: Lionel Debieve 
Signed-off-by: Herbert Xu 
Signed-off-by: Mathieu Poirier 
Signed-off-by: Greg Kroah-Hartman

virtio_console: move removal code

2019-11-28T17:26:23+00:00

[ Upstream commit aa44ec867030a72e8aa127977e37dec551d8df19 ]

Will make it reusable for error handling.

Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio_console: drop custom control queue cleanup

2019-11-28T17:26:23+00:00

[ Upstream commit 61a8950c5c5708cf2068b29ffde94e454e528208 ]

We now cleanup all VQs on device removal - no need
to handle the control VQ specially.

Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio_console: fix uninitialized variable use

2019-11-28T17:26:22+00:00

[ Upstream commit 2055997f983c6db7b5c3940ce5f8f822657d5bc3 ]

We try to disable callbacks on c_ivq even without multiport
even though that vq is not initialized in this configuration.

Fixes: c743d09dbd01 ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze")
Suggested-by: Mike Galbraith 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio_console: allocate inbufs in add_port() only if it is needed

2019-11-28T17:26:22+00:00

[ Upstream commit d791cfcbf98191122af70b053a21075cb450d119 ]

When we hot unplug a virtserialport and then try to hot plug again,
it fails:

(qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait
(qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                  chardev=serial0,id=serial0,name=serial0
(qemu) device_del serial0
(qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                  chardev=serial0,id=serial0,name=serial0
kernel error:
  virtio-ports vport2p2: Error allocating inbufs
qemu error:
  virtio-serial-bus: Guest failure in adding port 2 for device \
                     virtio-serial0.0

This happens because buffers for the in_vq are allocated when the port is
added but are not released when the port is unplugged.

They are only released when virtconsole is removed (see a7a69ec0d8e4)

To avoid the problem and to be symmetric, we could allocate all the buffers
in init_vqs() as they are released in remove_vqs(), but it sounds like
a waste of memory.

Rather than that, this patch changes add_port() logic to ignore ENOSPC
error in fill_queue(), which means queue has already been filled.

Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset")
Cc: mst@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Vivier 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin