search for: recvmsg

...on the vq from vhost side. This can be avoided by making sure we have got enough headcount before actually consuming a skb from the batched rx array while transmitting, which is simply done by moving checking the zero headcount a bit ahead. Also strengthen the small possibility of leak in case of recvmsg() fails by freeing the skb. Signed-off-by: Wei Xu <wexu at redhat.com> Reported-by: Matthew Rosato <mjrosato at linux.vnet.ibm.com> --- drivers/vhost/net.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) v2: - add Matthew as the reporter, thanks matthe...

...on the vq from vhost side. This can be avoided by making sure we have got enough headcount before actually consuming a skb from the batched rx array while transmitting, which is simply done by moving checking the zero headcount a bit ahead. Also strengthen the small possibility of leak in case of recvmsg() fails by freeing the skb. Signed-off-by: Wei Xu <wexu at redhat.com> Reported-by: Matthew Rosato <mjrosato at linux.vnet.ibm.com> --- drivers/vhost/net.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) v2: - add Matthew as the reporter, thanks matthe...

...ded by making sure we have got enough headcount >> before actually consuming a skb from the batched rx array while >> transmitting, which is simply done by moving checking the zero >> headcount a bit ahead. >> >> Also strengthen the small possibility of leak in case of recvmsg() >> fails by freeing the skb. >> >> Signed-off-by: Wei Xu<wexu at redhat.com> >> Reported-by: Matthew Rosato<mjrosato at linux.vnet.ibm.com> >> --- >> drivers/vhost/net.c | 23 +++++++++++++---------- >> 1 file changed, 13 insertions(+), 10...

...ded by making sure we have got enough headcount >> before actually consuming a skb from the batched rx array while >> transmitting, which is simply done by moving checking the zero >> headcount a bit ahead. >> >> Also strengthen the small possibility of leak in case of recvmsg() >> fails by freeing the skb. >> >> Signed-off-by: Wei Xu<wexu at redhat.com> >> Reported-by: Matthew Rosato<mjrosato at linux.vnet.ibm.com> >> --- >> drivers/vhost/net.c | 23 +++++++++++++---------- >> 1 file changed, 13 insertions(+), 10...

...t;>> because I have been doing work related with storage and file system. >>>> >>>> The problem as follows: >>>> we should monitor all of socket of vsock in handle_rx, when there are >>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to >>>> get data, it is different with socket. To vsock, I think host will >>>> not call ->recvmsg when it need to send message to guest. To net, >>>> vhost-net only as forwarding layer. >>> Know not much here, but is it possible to have a vsock(tap)...

...t;>> because I have been doing work related with storage and file system. >>>> >>>> The problem as follows: >>>> we should monitor all of socket of vsock in handle_rx, when there are >>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to >>>> get data, it is different with socket. To vsock, I think host will >>>> not call ->recvmsg when it need to send message to guest. To net, >>>> vhost-net only as forwarding layer. >>> Know not much here, but is it possible to have a vsock(tap)...

Userspace virtio server has the following hack so guests rely on it, and we have to replicate it, too: Use port number to detect incoming IPv4 DHCP response packets, and fill in the checksum for these. The issue we are solving is that on linux guests, some apps that use recvmsg with AF_PACKET sockets, don't know how to handle CHECKSUM_PARTIAL; The interface to return the relevant information was added in 8dc4194474159660d7f37c495e3fc3f10d0db8cc, and older userspace does not use it. One important user of recvmsg with AF_PACKET is dhclient, so we add a work-around just...

Userspace virtio server has the following hack so guests rely on it, and we have to replicate it, too: Use port number to detect incoming IPv4 DHCP response packets, and fill in the checksum for these. The issue we are solving is that on linux guests, some apps that use recvmsg with AF_PACKET sockets, don't know how to handle CHECKSUM_PARTIAL; The interface to return the relevant information was added in 8dc4194474159660d7f37c495e3fc3f10d0db8cc, and older userspace does not use it. One important user of recvmsg with AF_PACKET is dhclient, so we add a work-around just...

...know about virtio-net a little), >> because I have been doing work related with storage and file system. >> >> The problem as follows: >> we should monitor all of socket of vsock in handle_rx, when there are >> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to >> get data, it is different with socket. To vsock, I think host will >> not call ->recvmsg when it need to send message to guest. To net, >> vhost-net only as forwarding layer. > > Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net...

...know about virtio-net a little), >> because I have been doing work related with storage and file system. >> >> The problem as follows: >> we should monitor all of socket of vsock in handle_rx, when there are >> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to >> get data, it is different with socket. To vsock, I think host will >> not call ->recvmsg when it need to send message to guest. To net, >> vhost-net only as forwarding layer. > > Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net...

Author: ja97890 Repository: /hg/zfs-crypto/gate Revision: 4e8bdca5612d8e39ecb94db81ca5272fe9872d89 Log message: 6262586 truss should print data written/read for sendmsg/recvmsg Files: update: usr/src/cmd/truss/actions.c update: usr/src/cmd/truss/expound.c

When mergeable buffers are disabled, and the incoming packet is too large for the rx buffer, get_rx_bufs returns success. This was intentional in order for make recvmsg truncate the packet and then handle_rx would detect err != sock_len and drop it. Unfortunately we pass the original sock_len to recvmsg - which means we use parts of iov not fully validated. Fix this up by detecting this overrun and doing packet drop immediately. CVE-2014-0055 Signed-off-by: Mi...

When mergeable buffers are disabled, and the incoming packet is too large for the rx buffer, get_rx_bufs returns success. This was intentional in order for make recvmsg truncate the packet and then handle_rx would detect err != sock_len and drop it. Unfortunately we pass the original sock_len to recvmsg - which means we use parts of iov not fully validated. Fix this up by detecting this overrun and doing packet drop immediately. CVE-2014-0055 Signed-off-by: Mi...

Hi, I'm getting the following in my server log when I try to connect. to openssh-3.3p1 on linux 2.0.36 Jun 23 22:53:49 bart sshd[10702]: Accepted password for steve from 10.0.0.240 port 3867 ssh2 Jun 23 22:53:49 bart sshd[10704]: fatal: mm_receive_fd: expected type 1 got 1074202577 Sorry if this came up already, but the search engine seemed to ignore underscores and all the matches matched

Contrast http://cvsweb.mindrot.org/index.cgi/openssh/monitor_fdpass.c?r1=1.23;r2=1.24 with http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor_fdpass.c.diff?r1=1.14&r2=1.15 The original replaces cmsgbuf.tmp with cmsgbuf.buf, while the -portable version *adds* cmsgbuf.buf but retains cmsgbuf.tmp. I assume this was an oversight, and cmsgbuf.tmp should be removed? DES -- Dag-Erling

When mergeable buffers are disabled, and the incoming packet is too large for the rx buffer, get_rx_bufs returns success. This was intentional in order for make recvmsg truncate the packet and then handle_rx would detect err != sock_len and drop it. Unfortunately we pass the original sock_len to recvmsg - which means we use parts of iov not fully validated. Fix this up by detecting this overrun and doing packet drop immediately. CVE-2014-0077 Signed-off-by: Mi...

When mergeable buffers are disabled, and the incoming packet is too large for the rx buffer, get_rx_bufs returns success. This was intentional in order for make recvmsg truncate the packet and then handle_rx would detect err != sock_len and drop it. Unfortunately we pass the original sock_len to recvmsg - which means we use parts of iov not fully validated. Fix this up by detecting this overrun and doing packet drop immediately. CVE-2014-0077 Signed-off-by: Mi...

...se I have been doing work related with storage and file system. >>>>> >>>>> The problem as follows: >>>>> we should monitor all of socket of vsock in handle_rx, when there are >>>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to >>>>> get data, it is different with socket. To vsock, I think host will >>>>> not call ->recvmsg when it need to send message to guest. To net, >>>>> vhost-net only as forwarding layer. >>>> Know not much here, but is it possible to ha...

...gt; This can be avoided by making sure we have got enough headcount > before actually consuming a skb from the batched rx array while > transmitting, which is simply done by moving checking the zero > headcount a bit ahead. > > Also strengthen the small possibility of leak in case of recvmsg() > fails by freeing the skb. > > Signed-off-by: Wei Xu <wexu at redhat.com> > Reported-by: Matthew Rosato <mjrosato at linux.vnet.ibm.com> > --- > drivers/vhost/net.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > v2:...

...est I have a problem and difficult, mainly I know about virtio-net a little), because I have been doing work related with storage and file system. The problem as follows: we should monitor all of socket of vsock in handle_rx, when there are data coming, and copy data to vq desc. Vhost-net use ->recvmsg to get data, it is different with socket. To vsock, I think host will not call ->recvmsg when it need to send message to guest. To net, vhost-net only as forwarding layer.