similar to: [PATCH net] vhost_net: validate sock before trying to put its fd

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in vhost_net_ubuf_put_and_wait, add an new API for callers that want to free ubufs.

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in vhost_net_ubuf_put_and_wait, add an new API for callers that want to free ubufs.

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

On 13.02.20 17:29, Eugenio P?rez wrote: > Can we try with this traces? Does not apply on eccb852f1fe6bede630e2e4f1a121a81e34354ab, can you double check? > > From b793b4106085ab1970bdedb340e49f37843ed585 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Eugenio=20P=C3=A9rez?= <eperezma at redhat.com> > Date: Thu, 13 Feb 2020 17:27:05 +0100 > Subject: [PATCH] vhost: Add debug in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

I did ping -c 20 -f ... ; reboot twice The ping after the first reboot showed .......E this was on the host console [ 55.951885] CPU: 34 PID: 1908 Comm: CPU 0/KVM Not tainted 5.5.0+ #21 [ 55.951891] Hardware name: IBM 3906 M04 704 (LPAR) [ 55.951892] Call Trace: [ 55.951902] [<0000001ede114132>] show_stack+0x8a/0xd0 [ 55.951906] [<0000001edeb0672a>]

On 14.02.20 08:40, Eugenio Perez Martin wrote: > Hi. > > Were the vhost and vhost_net modules loaded with dyndbg='+plt'? I miss > all the others regular debug traces on that one. I did echo -n 'file drivers/vhost/vhost.c +plt' > control and echo -n 'file drivers/vhost/net.c +plt' > control but apparently it did not work...me hates dynamic debug.

On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: > > Hi! > > Recently I have been investigating some strange migration problems on > s390x. > > It turned out under certain circumstances vhost_net corrupts avail.idx by > using wrong endianness. > > I managed to track the problem down (I'm pretty sure). It boils down to > the following. > >

On Wed, 10 Feb 2016 13:48:09 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > > The way vring endianness is being handled currently obfuscates > > the code in vhost_init_used(). > > > > This patch tries to fix that by doing the following: > > - move the the code that adjusts

Hi! Recently I have been investigating some strange migration problems on s390x. It turned out under certain circumstances vhost_net corrupts avail.idx by using wrong endianness. I managed to track the problem down (I'm pretty sure). It boils down to the following. When stopping vhost userspace (QEMU) calls vhost_net_set_backend with the fd argument set to -1, this leads to is_le being

Hi! Recently I have been investigating some strange migration problems on s390x. It turned out under certain circumstances vhost_net corrupts avail.idx by using wrong endianness. I managed to track the problem down (I'm pretty sure). It boils down to the following. When stopping vhost userspace (QEMU) calls vhost_net_set_backend with the fd argument set to -1, this leads to is_le being

On 2019/6/6 ??10:40, Hillf Danton wrote: > > On Wed, 05 Jun 2019 16:42:05 -0700 (PDT) syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:??? 788a0249 Merge tag 'arc-5.2-rc4' of >> git://git.kernel.org/p.. >> git tree:?????? upstream >> console output:

On Wed, 05 Jun 2019 16:42:05 -0700 (PDT) syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: 788a0249 Merge tag 'arc-5.2-rc4' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15dc9ea6a00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=d5c73825cbdc7326

On Wed, 05 Jun 2019 16:42:05 -0700 (PDT) syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: 788a0249 Merge tag 'arc-5.2-rc4' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15dc9ea6a00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=d5c73825cbdc7326

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

Hello Syzbot On Fri, 14 Jun 2019 02:26:02 +0800 syzbot wrote: > > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered crash: > memory leak in vhost_net_ioctl > Oh sorry for my poor patch. > ANGE): hsr_slave_1: link becomes ready > 2019/06/13 18:24:57 executed programs: 18 > BUG: memory leak > unreferenced object 0xffff88811cbc6ac0

Hello Syzbot On Fri, 14 Jun 2019 02:26:02 +0800 syzbot wrote: > > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered crash: > memory leak in vhost_net_ioctl > Oh sorry for my poor patch. > ANGE): hsr_slave_1: link becomes ready > 2019/06/13 18:24:57 executed programs: 18 > BUG: memory leak > unreferenced object 0xffff88811cbc6ac0