linux.git/drivers/char/virtio_console.c, branch v3.12

virtio: console: prevent use-after-free of port name in port unplug

2013-08-09T03:32:16+00:00

Remove the debugfs path before freeing port->name, to prevent a possible
use-after-free.

Reported-by: Jason Wang 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

Merge branch 'master' into virtio-next

2013-08-09T03:30:39+00:00

The next commit gets conflicts because it relies on patches which were
cc:stable and thus had to be merged into Linus' tree before the coming
merge window.  So pull in master now.

Signed-off-by: Rusty Russell

virtio: console: cleanup an error message

2013-07-30T06:24:30+00:00

The PTR_ERR(NULL) here is not useful.

Signed-off-by: Dan Carpenter 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: fix locking around send_sigio_to_port()

2013-07-29T05:20:49+00:00

send_sigio_to_port() checks the value of guest_connected, which we
always modify under the inbuf_lock; make sure invocations of
send_sigio_to_port() have take the inbuf_lock around the call.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: add locking in port unplug path

2013-07-29T05:20:48+00:00

Port unplug can race with close() in port_fops_release().
port_fops_release() already takes the necessary locks, ensure
unplug_port() does that too.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: add locks around buffer removal in port unplug path

2013-07-29T05:20:47+00:00

The removal functions act on the vqs, and the vq operations need to be
locked.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: return -ENODEV on all read operations after unplug

2013-07-29T05:13:58+00:00

If a port gets unplugged while a user is blocked on read(), -ENODEV is
returned.  However, subsequent read()s returned 0, indicating there's no
host-side connection (but not indicating the device went away).

This also happened when a port was unplugged and the user didn't have
any blocking operation pending.  If the user didn't monitor the SIGIO
signal, they won't have a chance to find out if the port went away.

Fix by returning -ENODEV on all read()s after the port gets unplugged.
write() already behaves this way.

CC: 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: fix raising SIGIO after port unplug

2013-07-29T05:13:57+00:00

SIGIO should be sent when a port gets unplugged.  It should only be sent
to prcesses that have the port opened, and have asked for SIGIO to be
delivered.  We were clearing out guest_connected before calling
send_sigio_to_port(), resulting in a sigio not getting sent to
processes.

Fix by setting guest_connected to false after invoking the sigio
function.

CC: 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: clean up port data immediately at time of unplug

2013-07-29T05:13:56+00:00

We used to keep the port's char device structs and the /sys entries
around till the last reference to the port was dropped.  This is
actually unnecessary, and resulted in buggy behaviour:

1. Open port in guest
2. Hot-unplug port
3. Hot-plug a port with the same 'name' property as the unplugged one

This resulted in hot-plug being unsuccessful, as a port with the same
name already exists (even though it was unplugged).

This behaviour resulted in a warning message like this one:

-------------------8<---------------------------------------
WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
Hardware name: KVM
sysfs: cannot create duplicate filename
'/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1'

Call Trace:
 [] ? warn_slowpath_common+0x87/0xc0
 [] ? warn_slowpath_fmt+0x46/0x50
 [] ? sysfs_add_one+0xc9/0x130
 [] ? create_dir+0x68/0xb0
 [] ? sysfs_create_dir+0x39/0x50
 [] ? kobject_add_internal+0xb9/0x260
 [] ? kobject_add_varg+0x38/0x60
 [] ? kobject_add+0x44/0x70
 [] ? get_device_parent+0xf4/0x1d0
 [] ? device_add+0xc9/0x650

-------------------8<---------------------------------------

Instead of relying on guest applications to release all references to
the ports, we should go ahead and unregister the port from all the core
layers.  Any open/read calls on the port will then just return errors,
and an unplug/plug operation on the host will succeed as expected.

This also caused buggy behaviour in case of the device removal (not just
a port): when the device was removed (which means all ports on that
device are removed automatically as well), the ports with active
users would clean up only when the last references were dropped -- and
it would be too late then to be referencing char device pointers,
resulting in oopses:

-------------------8<---------------------------------------
PID: 6162   TASK: ffff8801147ad500  CPU: 0   COMMAND: "cat"
 #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b
 #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322
 #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50
 #3 [ffff88011b9d5bf0] die at ffffffff8100f26b
 #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2
 #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5
    [exception RIP: strlen+2]
    RIP: ffffffff81272ae2  RSP: ffff88011b9d5d00  RFLAGS: 00010246
    RAX: 0000000000000000  RBX: ffff880118901c18  RCX: 0000000000000000
    RDX: ffff88011799982c  RSI: 00000000000000d0  RDI: 3a303030302f3030
    RBP: ffff88011b9d5d38   R8: 0000000000000006   R9: ffffffffa0134500
    R10: 0000000000001000  R11: 0000000000001000  R12: ffff880117a1cc10
    R13: 00000000000000d0  R14: 0000000000000017  R15: ffffffff81aff700
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d
 #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551
 #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb
 #9 [ffff88011b9d5de0] device_del at ffffffff813440c7

-------------------8<---------------------------------------

So clean up when we have all the context, and all that's left to do when
the references to the port have dropped is to free up the port struct
itself.

CC: 
Reported-by: chayang 
Reported-by: YOGANANTH SUBRAMANIAN 
Reported-by: FuXiangChun 
Reported-by: Qunfang Zhang 
Reported-by: Sibiao Luo 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: console: fix race in port_fops_open() and port unplug

2013-07-29T05:13:55+00:00

Between open() being called and processed, the port can be unplugged.
Check if this happened, and bail out.

A simple test script to reproduce this is:

while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done;

This opens and closes the port a lot of times; unplugging the port while
this is happening triggers the bug.

CC: 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell