On Tue, 2015-10-06 at 11:55 -0500, Jonathon Jongsma wrote:
> On Tue, 2015-10-06 at 15:33 +0200, Pavel Grunt wrote:
> > Hi Jonathon,
> >
> > thanks for the work, the user should have a way to cancel & monitor the file
> > transfer progress.
> >
> > Ack from me, just a few comments below.
> >
> >
On Tue, 2015-10-06 at 15:23 -0500, Jonathon Jongsma wrote:
> On Fri, 2015-09-25 at 08:53 -0500, Jonathon Jongsma wrote:
> > On Fri, 2015-09-25 at 10:51 +0200, Christophe Fergeau wrote:
> > > On Thu, Sep 24, 2015 at 05:20:25PM -0500, Jonathon Jongsma wrote:
> > > > This is a second approach suggeste
On Fri, 2015-09-25 at 08:53 -0500, Jonathon Jongsma wrote:
> On Fri, 2015-09-25 at 10:51 +0200, Christophe Fergeau wrote:
> > On Thu, Sep 24, 2015 at 05:20:25PM -0500, Jonathon Jongsma wrote:
> > > This is a second approach suggested by Marc-Andre to fix up some of the
> > > issues
> > > with circ
There were several shortcomings to the existing file transfer API,
particularly in terms of monitoring ongoing file transfers. The major
issue is that spice_main_file_copy_async() allows you to pass an array
of files, but the progress callback does not provide a way to
identify which file the callb
spice_main_file_copy_async() allows you to pass a NULL-terminated array
of files to transfer to the guest. It also allows you to pass a
progress_callback function to monitor the progress of the transfer, but
this progress callback is called separately for each file that is
transferred, and there ar
On Tue, 2015-10-06 at 15:33 +0200, Pavel Grunt wrote:
> Hi Jonathon,
>
> thanks for the work, the user should have a way to cancel & monitor the file
> transfer progress.
>
> Ack from me, just a few comments below.
>
> On Mon, 2015-10-05 at 13:39 -0500, Jonathon Jongsma wrote:
> > There were sev
Hey everyone,
At long last, I've rolled out a new spice 0.12.6 release.
Major changes in 0.12.6:
* Removed spicec client code, it has been superseded by remote-viewer and other
spice-gtk based clients
* Unix socket support
* LZ4 support
* Let clients specify their prefe
Hi Jonathon,
thanks for the work, the user should have a way to cancel & monitor the file
transfer progress.
Ack from me, just a few comments below.
On Mon, 2015-10-05 at 13:39 -0500, Jonathon Jongsma wrote:
> There were several shortcomings to the existing file transfer API,
> particularly in t
On Tue, Oct 06, 2015 at 06:38:06AM -0400, Frediano Ziglio wrote:
> >
> > See https://access.redhat.com/security/cve/CVE-2015-5260,
> > https://access.redhat.com/security/cve/CVE-2015-5261 and
> > http://openwall.com/lists/oss-security/2015/10/06/4 for some
> > details on the security problems disc
>
> See https://access.redhat.com/security/cve/CVE-2015-5260,
> https://access.redhat.com/security/cve/CVE-2015-5261 and
> http://openwall.com/lists/oss-security/2015/10/06/4 for some
> details on the security problems discovered.
>
> These patches were already be sended to different distribution
Free linked list if client tries to do nasty things
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index
Check format is valid.
Check stride is at least the size of required bytes for a row.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/server/red_parse_q
Do not read multiple time an array size that can be changed.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index 40c1c99..a9f3ca1
The overflow may lead to buffer overflow as the row size computed from
width (bitmap->x) can be bigger than the size in bytes (bitmap->stride).
This can make spice-server accept the invalid sizes.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 7 ---
Not security risk as just for read.
However, this could be used to attempt integer overflows in the
following lines.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/server/red_pars
Limit number of chunks to a given amount to avoid guest trying to
allocate too much memory. Using circular or nested chunks lists
guest could try to allocate huge amounts of memory.
Considering the list can be infinite and guest can change data this
also prevents strange security attacks from guest
Do not just give warning and continue to use an invalid index into
an array.
Resolves: CVE-2015-5260
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_worker.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/serve
This limit will prevent guest trying to do nasty things and DoS to host.
Signed-off-by: Frediano Ziglio
---
server/red_parse_qxl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index 5b1befa..3ffa57b 100644
--- a/server/red_parse
The guest can attempt to increase the number of segments while
spice-server is reading them.
Make sure we don't copy more then the allocated segments.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Prevent integer overflow when computing image sizes.
Image index computations are done using 32 bit so this can cause easily
security issues. MAX_DATA_CHUNK is larger than the virtual
card limit, so this is not going to cause change in behaviours.
Comparing size calculation results with MAX_DATA_CH
start pointer points to a QXLPathSeg structure.
Before reading from the structure, make sure the structure is contained
in the memory range checked.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Do not read multiple times data from guest as this could be changed
by other vcpu threads.
This causes races and security problems if these data are used for
buffer allocation or checks.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 18 ++--
Signed-off-by: Frediano Ziglio
---
server/red_parse_qxl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index 3ce4431..dd52602 100644
--- a/server/red_parse_qxl.c
+++ b/server/red_parse_qxl.c
@@ -526,6 +526,7 @@ static SpiceImage *red_get_im
Do not read multiple time an array size that can be changed.
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index 5656bfb..
See https://access.redhat.com/security/cve/CVE-2015-5260,
https://access.redhat.com/security/cve/CVE-2015-5261 and
http://openwall.com/lists/oss-security/2015/10/06/4 for some
details on the security problems discovered.
These patches were already be sended to different distribution
and updates ar
If bpp is int the formula can lead to weird overflows. width and height
are uint16_t so the formula is:
size_t = u16 * (u16 * int + const_int) / const_int;
so it became
size_t = (int) u16 * ((int) u16 * int + const_int) / const_int;
However the (int) u16 * (int) u16 can then became negative
Signed-off-by: Frediano Ziglio
Acked-by: Christophe Fergeau
---
server/red_parse_qxl.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/server/red_parse_qxl.c b/server/red_parse_qxl.c
index 5513e82..f21bfa5 100644
--- a/server/red_parse_qxl.c
+++ b/server/red_parse_qxl.
A driver can overwrite surface state creating a surface with the same
id of a previous one.
Also can try to destroy surfaces that are not created.
Both requests cause invalid internal states that could lead to crashes
or memory corruptions.
Signed-off-by: Frediano Ziglio
---
server/red_worker.c
There was not check for data_size field so one could set data to
a small set of data and data_size much bigger than size of data
leading to buffer overflow.
Signed-off-by: Frediano Ziglio
---
server/red_parse_qxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/server/red_parse_qxl.c b/serv
Do not read multiple times data from guest as this can be changed by
other guest vcpus. This causes races and security problems if these
data are used for buffer allocation or checks.
Actually, the 'data' member can't change during read as it is just a
pointer to a fixed array contained in qxl. Ho
On Mon, 2015-10-05 at 18:39 +0200, Christophe Fergeau wrote:
> On Thu, Oct 01, 2015 at 05:19:23PM +0200, Pavel Grunt wrote:
> > Resolves:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1061942
> > ---
> > server/red_worker.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
Hi,
On Mon, Oct 05, 2015 at 01:39:54PM -0500, Jonathon Jongsma wrote:
> spice_main_file_copy_async() allows you to pass a NULL-terminated array
> of files to transfer to the guest. It also allows you to pass a
> progress_callback function to monitor the progress of the transfer, but
> this progres
32 matches
Mail list logo
