ubuf info allocator uses guest controlled head as an index,
so a malicious guest could put the same head entry in the ring twice,
and we will get two callbacks on the same value.
To fix use upend_idx which is guaranteed to be unique.
Reported-by: Rusty Russell <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Cc: [email protected]
---
Rusty's working on switching to allocating ubufs dynamically
but that's not 3.9 material.
This patch is against latest net master,
needed for 3.9-rc2 and older kernels.
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 959b1cd..ec6fb3f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -339,7 +339,8 @@ static void handle_tx(struct vhost_net *net)
msg.msg_controllen = 0;
ubufs = NULL;
} else {
- struct ubuf_info *ubuf = &vq->ubuf_info[head];
+ struct ubuf_info *ubuf;
+ ubuf = vq->ubuf_info + vq->upend_idx;
vq->heads[vq->upend_idx].len =
VHOST_DMA_IN_PROGRESS;
--
MST
From: "Michael S. Tsirkin" <[email protected]>
Date: Sun, 17 Mar 2013 14:46:09 +0200
> ubuf info allocator uses guest controlled head as an index,
> so a malicious guest could put the same head entry in the ring twice,
> and we will get two callbacks on the same value.
> To fix use upend_idx which is guaranteed to be unique.
>
> Reported-by: Rusty Russell <[email protected]>
> Signed-off-by: Michael S. Tsirkin <[email protected]>
Applied and queued up for -stable, thanks.
And thankfully you got the stable URL wrong, please do not CC:
networking patches to stable, just make sure I apply them and in
your post-commit text explicitly ask me to queue it up to my
-stable queue.
Thanks.
On Sun, Mar 17, 2013 at 02:29:55PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <[email protected]>
> Date: Sun, 17 Mar 2013 14:46:09 +0200
>
> > ubuf info allocator uses guest controlled head as an index,
> > so a malicious guest could put the same head entry in the ring twice,
> > and we will get two callbacks on the same value.
> > To fix use upend_idx which is guaranteed to be unique.
> >
> > Reported-by: Rusty Russell <[email protected]>
> > Signed-off-by: Michael S. Tsirkin <[email protected]>
>
> Applied and queued up for -stable, thanks.
OK I'll drop it from my tree then.
On Sun, Mar 17, 2013 at 02:29:55PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <[email protected]>
> Date: Sun, 17 Mar 2013 14:46:09 +0200
>
> > ubuf info allocator uses guest controlled head as an index,
> > so a malicious guest could put the same head entry in the ring twice,
> > and we will get two callbacks on the same value.
> > To fix use upend_idx which is guaranteed to be unique.
> >
> > Reported-by: Rusty Russell <[email protected]>
> > Signed-off-by: Michael S. Tsirkin <[email protected]>
>
> Applied and queued up for -stable, thanks.
>
> And thankfully you got the stable URL wrong,
Yes I wrote [email protected] that's what an old copy
says here:
https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
I should have known better than look at it on the 'net. The top
'Everything you ever wanted to know about Linux 2.6 -stable releases.'
is a big hint that it's stale.
Any idea who maintains this? Better update it or remove it or redirect to git.
> please do not CC:
> networking patches to stable, just make sure I apply them and in
> your post-commit text explicitly ask me to queue it up to my
> -stable queue.
>
> Thanks.
On Thu, 2013-03-21 at 08:02 +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 17, 2013 at 02:29:55PM -0400, David Miller wrote:
> > From: "Michael S. Tsirkin" <[email protected]>
> > Date: Sun, 17 Mar 2013 14:46:09 +0200
> >
> > > ubuf info allocator uses guest controlled head as an index,
> > > so a malicious guest could put the same head entry in the ring twice,
> > > and we will get two callbacks on the same value.
> > > To fix use upend_idx which is guaranteed to be unique.
> > >
> > > Reported-by: Rusty Russell <[email protected]>
> > > Signed-off-by: Michael S. Tsirkin <[email protected]>
> >
> > Applied and queued up for -stable, thanks.
> >
> > And thankfully you got the stable URL wrong,
>
> Yes I wrote [email protected] that's what an old copy
> says here:
> https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
>
> I should have known better than look at it on the 'net. The top
> 'Everything you ever wanted to know about Linux 2.6 -stable releases.'
> is a big hint that it's stale.
> Any idea who maintains this? Better update it or remove it or redirect to git.
Rob Landley maintains it, but he's been having trouble updating it since
all the upload mechanisms were changed on kernel.org.
(My stable maintenance scripts still match the old address, anyway. Not
sure about Greg's.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
On Thu, Mar 21, 2013 at 04:23:48PM +0000, Ben Hutchings wrote:
> On Thu, 2013-03-21 at 08:02 +0200, Michael S. Tsirkin wrote:
> > On Sun, Mar 17, 2013 at 02:29:55PM -0400, David Miller wrote:
> > > From: "Michael S. Tsirkin" <[email protected]>
> > > Date: Sun, 17 Mar 2013 14:46:09 +0200
> > >
> > > > ubuf info allocator uses guest controlled head as an index,
> > > > so a malicious guest could put the same head entry in the ring twice,
> > > > and we will get two callbacks on the same value.
> > > > To fix use upend_idx which is guaranteed to be unique.
> > > >
> > > > Reported-by: Rusty Russell <[email protected]>
> > > > Signed-off-by: Michael S. Tsirkin <[email protected]>
> > >
> > > Applied and queued up for -stable, thanks.
> > >
> > > And thankfully you got the stable URL wrong,
> >
> > Yes I wrote [email protected] that's what an old copy
> > says here:
> > https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
> >
> > I should have known better than look at it on the 'net. The top
> > 'Everything you ever wanted to know about Linux 2.6 -stable releases.'
> > is a big hint that it's stale.
> > Any idea who maintains this? Better update it or remove it or redirect to git.
>
> Rob Landley maintains it, but he's been having trouble updating it since
> all the upload mechanisms were changed on kernel.org.
>
> (My stable maintenance scripts still match the old address, anyway. Not
> sure about Greg's.)
>
> Ben.
I hope you mean it will match both the old and the new address?
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
On Thu, 2013-03-21 at 18:28 +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 04:23:48PM +0000, Ben Hutchings wrote:
> > On Thu, 2013-03-21 at 08:02 +0200, Michael S. Tsirkin wrote:
> > > On Sun, Mar 17, 2013 at 02:29:55PM -0400, David Miller wrote:
> > > > From: "Michael S. Tsirkin" <[email protected]>
> > > > Date: Sun, 17 Mar 2013 14:46:09 +0200
> > > >
> > > > > ubuf info allocator uses guest controlled head as an index,
> > > > > so a malicious guest could put the same head entry in the ring twice,
> > > > > and we will get two callbacks on the same value.
> > > > > To fix use upend_idx which is guaranteed to be unique.
> > > > >
> > > > > Reported-by: Rusty Russell <[email protected]>
> > > > > Signed-off-by: Michael S. Tsirkin <[email protected]>
> > > >
> > > > Applied and queued up for -stable, thanks.
> > > >
> > > > And thankfully you got the stable URL wrong,
> > >
> > > Yes I wrote [email protected] that's what an old copy
> > > says here:
> > > https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
> > >
> > > I should have known better than look at it on the 'net. The top
> > > 'Everything you ever wanted to know about Linux 2.6 -stable releases.'
> > > is a big hint that it's stale.
> > > Any idea who maintains this? Better update it or remove it or redirect to git.
> >
> > Rob Landley maintains it, but he's been having trouble updating it since
> > all the upload mechanisms were changed on kernel.org.
> >
> > (My stable maintenance scripts still match the old address, anyway. Not
> > sure about Greg's.)
> >
> > Ben.
>
> I hope you mean it will match both the old and the new address?
Yes, of course!
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.