Prevent possible buffer reading overflow.
Note that message pointer must be valid and data are checked
value by value so even on overflow you just get an error.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This vfunc only has a RedChannelClient * argument, and most of the time,
it operates on RedChannelClient, not on RedChannel. Moreover, the only
time it's used is from RedChannelClient. This commit moves the vfunc to
RedChannelClient, which seems like a better fit for it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Use a #define rather than a magic number to make the code a bit more
readable.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
InputsChannelClient::new and SmartcardChannelClient::new both accept a
"monitor_latency" argument, which is always FALSE. It can be removed.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This commit changes all functions returning TRUE/FALSE from having an
'int' return value to 'bool'.
This way it's obvious that such a function is not going to return
anything else than TRUE or FALSE.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These vfuncs are more appropriate in RedChannelClient.
The buffer they allocated are related to the client stream
which is managed directly by RedChannelClient.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
For each channel there are two set of capabilities, one
for the common ones and one for the specific ones.
A single set were almost always passed using 2 arguments,
a number of elements and an array but then before using
these were converted to a GArray.
Use a single structure (already available) to pass all
channel capabilites using a single argument.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Most channels don't need to do specific settings for the client socket
so avoid the need to do this setting making easier to setup the client
channnel.
Some improvements and commit subject suggested by Christophe Fergeau.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
TCP_NODELAY flag is set by default for all connection inside
reds.c so there's no need to set again for the single
client channel.
Note that there are still some calls to setsockopt to change this
option.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
red_channel_client_parse() currently does roughly:
if (klass->parser) {
parsed = klass->parser(msg, msg_size, &parsed_size);
klass->handle_parsed(rcc, parsed_size, msg_type, parsed);
} else {
klass->handle_message(rcc, msg_type, msg, msg_size);
}
The handle_parsed implementation expects a void * 'parsed' argument,
which will then be cast to the correct type. There is not really a need
to provide distinct handle_parsed/handle_message vfuncs, instead we can
say that if a RedChannel subclass provides a 'parser' vfunc, then it's
'handle_message' vfunc will be called with the parsed message, otherwise
it will be called with unparsed data (ie what handle_message currently
expects).
This makes the code slightly easier to follow as messages will always be
handled by the same vfunc.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This third argument (and the 'item' member of
RedChannelClient::priv::send_data) was a somewhat roundabout way to keep
the RedPipeItem alive until a message is sent, just in case some data
owned by that pipeitem was added to the marshaller by reference. This
was a rather confusing mechanism, however, since it did not have any
obvious connection to the _add_by_ref() call. It was never very clear
whether you needed to pass an item to this function or not. The previous
series of patches made this parameter unnecessary since the referencing
of the pipe item (or other related structure) is now more explicitly
connected to the calls to spice_marshaller_add_by_ref_full().
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The only time that the pipe item needs to be passed as the third
argument to red_channel_client_init_send_data() is when the pipe item
holds a data buffer that has been added to the marshaller by reference
(spice_marshaller_add_by_ref()) and needs to be kept alive until the
data has been sent. In all other cases, the item does not need to be
kept alive, so we can safely pass NULL for this third parameter.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Most of the times the check is done externally
so moving inside the function reduce the code.
This is similar to the way free(3) works.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Also move the RedClient struct out of the header to avoid accessing the
internals from other files.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In preparation for converting RedChannel to GObject, switch to using
RED_CHANNEL()-type macros for casting. For now they just do a regular
cast, but it helps reduce the size of the GObject patch to make it
easier to review.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In anticipation of porting to GObject, use casting macros (e.g.
MAIN_CHANNEL_CLIENT()) to cast RedChannelClient types. This will help
reduce the changeset slightly porting to GObject and thus make it easier
to review those upcoming changes.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Don't poke into the structure to get the channel
This prepares for encapsulating RedChannelClient a bit more and
separating it into its own source file.
Do not handle them as normal keys.
State is not saved for these keys.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
key and key_ext in SpiceKbdState are indexed using
state[scan & 0x7f]
where scan is a 8 bit value got from client. In theory client can send
any value causing scan & 0x7f to be 0x7f. However these arrays contains
only 0x7f values so 0x7f cause a off one overflow.
This potentially cause key_ext to overflow in reds pointer following.
Happily this is not exploitable in either 32 or 64 bit environment.
On 64 bit key_ext is followed by a 4 byte (sizeof(bool) == 4) padding
which is written by the possible overflow.
On 32 bit reds will be overwritten with either 0 or 1 which will cause
a SIGSEGV leading to a DoS. Considering that you have to have access
to the machine with a client you are just shutting down only guests you
can access to.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This was proposed by Christophe as improvement over some typesafe
patches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Remove the need to release the item inside send_item callbacks.
This looks like a partial rollback of previous patch but is
to make clear the intention of the change.
The lifetime of items could extend a bit further but there
are no cases this small lag should cause problems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This is quite confusing and prone to errors.
Use RedPipeItem reference counting instead.
To compensate for the additional reference due to red_pipe_item_ref
in RedChannel sub class with empty hold_item have to add a
red_pipe_item_unref call in send_item.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid having to provide a lot of empty implementations
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The include directory is specified with the -I which is the directory
used directly by #include<>.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
It's always called at the same time as red_channel_register_client_cbs()
and the data is used by the callbacks, so we can pass the data as an
argument to red_channel_register_client_cbs().
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The RedChannel argument is not used by pipe_item_init. Removing it
will make code simpler in places where we don't have a RedChannel
directly available.
This is acting on a PipeItem object so correct name is pipe_item_init.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
