linux-stable.git/drivers/virtio, branch v3.16.35

virtio_pci: fix use after free on release

2016-02-17T10:22:39+00:00

commit 2989be09a8a9d62a785137586ad941f916e08f83 upstream.

KASan detected a use-after-free error in virtio-pci remove code. In
virtio_pci_remove(), vp_dev is still used after being freed in
unregister_virtio_device() (in virtio_pci_release_dev() more
precisely).

To fix, keep a reference until cleanup is done.

Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback")
Reported-by: Jerome Marchand 
Cc: Sasha Levin 
Signed-off-by: Michael S. Tsirkin 
Tested-by: Jerome Marchand 
[ luis: backported to 3.16:
  - file rename: virtio_pci_legacy.c -> virtio_pci.c ]
Signed-off-by: Luis Henriques

virtio_balloon: fix race by fill and leak

2016-02-02T19:09:32+00:00

commit f68b992bbb474641881932c61c92dcfa6f5b3689 upstream.

During my compaction-related stuff, I encountered a bug
with ballooning.

With repeated inflating and deflating cycle, guest memory(
ie, cat /proc/meminfo | grep MemTotal) is decreased and
couldn't be recovered.

The reason is balloon_lock doesn't cover release_pages_balloon
so struct virtio_balloon fields could be overwritten by race
of fill_balloon(e,g, vb->*pfns could be critical).

This patch fixes it in my test.

Signed-off-by: Minchan Kim 
Signed-off-by: Michael S. Tsirkin 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

virtio: fix memory leak of virtio ida cache layers

2016-01-11T10:50:18+00:00

commit c13f99b7e945dad5273a8b7ee230f4d1f22d3354 upstream.

The virtio core uses a static ida named virtio_index_ida for
assigning index numbers to virtio devices during registration.
The ida core may allocate some internal idr cache layers and
an ida bitmap upon any ida allocation, and all these layers are
truely freed only upon the ida destruction. The virtio_index_ida
is not destroyed at present, leading to a memory leak when using
the virtio core as a module and atleast one virtio device is
registered and unregistered.

Fix this by invoking ida_destroy() in the virtio core module
exit.

Signed-off-by: Suman Anna 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Luis Henriques

virtio_pci: Clear stale cpumask when setting irq affinity

2015-06-30T16:15:20+00:00

commit 210d150e1f5da506875e376422ba31ead2d49621 upstream.

The cpumask vp_dev->msix_affinity_masks[info->msix_vector] may contain
staled information when vp_set_vq_affinity() gets called, so clear it
before setting the new cpu bit mask.

Signed-off-by: Jiang Liu 
Signed-off-by: Michael S. Tsirkin 
[ luis: backported to 3.16:
  - file rename: virtio_pci_common.c -> virtio_pci.c ]
Signed-off-by: Luis Henriques

virtio_pci: document why we defer kfree

2015-02-19T10:39:52+00:00

commit a1eb03f546d651a8f39c7d0692b1f7f5b4e7e3cd upstream.

The reason we defer kfree until release function is because it's a
general rule for kobjects: kfree of the reference counter itself is only
legal in the release function.

Previous patch didn't make this clear, document this in code.

Signed-off-by: Michael S. Tsirkin 
[ luis: backported to 3.16:
  - file rename: virtio_pci_legacy.c -> virtio_pci.c ]
Signed-off-by: Luis Henriques

virtio_pci: defer kfree until release callback

2015-02-19T10:36:36+00:00

commit 63bd62a08ca45a0c804c3c89777edc7f76a2d6da upstream.

A struct device which has just been unregistered can live on past the
point at which a driver decides to drop it's initial reference to the
kobject gained on allocation.

This implies that when releasing a virtio device, we can't free a struct
virtio_device until the underlying struct device has been released,
which might not happen immediately on device_unregister().

Unfortunately, this is exactly what virtio pci does:
it has an empty release callback, and frees memory immediately
after unregistering the device.

This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE
it enabled.

To fix, free the memory only once we know the device is gone in the release
callback.

Signed-off-by: Sasha Levin 
Signed-off-by: Michael S. Tsirkin 
[ luis: backported to 3.16:
  - file rename: virtio_pci_legacy.c -> virtio_pci.c ]
Signed-off-by: Luis Henriques

virtio_pci: fix virtio spec compliance on restore

2014-11-17T14:11:41+00:00

commit 6fbc198cf623944ab60a1db6d306a4d55cdd820d upstream.

On restore, virtio pci does the following:
+ set features
+ init vqs etc - device can be used at this point!
+ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits

This is in violation of the virtio spec, which
requires the following order:
- ACKNOWLEDGE
- DRIVER
- init vqs
- DRIVER_OK

This behaviour will break with hypervisors that assume spec compliant
behaviour.  It seems like a good idea to have this patch applied to
stable branches to reduce the support butden for the hypervisors.

Cc: Amit Shah 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell 
Signed-off-by: Luis Henriques

virtio: virtio_break_device() to mark all virtqueues broken.

2014-04-28T02:04:13+00:00

Good for post-apocalyptic scenarios, like S/390 hotplug.

Signed-off-by: Rusty Russell

virtio: fail adding buffer on broken queues.

2014-03-13T00:57:57+00:00

Heinz points out that adding buffers to a broken virtqueue (which
should "never happen") still works.  Failing allows drivers to detect
and complain about broken devices.

Now drivers are robust, we can add this extra check.

Reported-by: Heinz Graalfs 
Signed-off-by: Rusty Russell

virtio_balloon: don't crash if virtqueue is broken.

2014-03-13T00:57:56+00:00

A bad implementation of virtio might cause us to mark the virtqueue
broken: we'll dev_err() in that case, and the device is useless, but
let's not BUG().

Signed-off-by: Rusty Russell