After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 531236 - [0.11][gstvalue] Deserialization not correct
[0.11][gstvalue] Deserialization not correct
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-05-03 15:43 UTC by Sebastian Dröge (slomo)
Modified: 2013-07-17 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2008-05-03 15:43:54 UTC
Hi,
the deserialization in gstvalue.c is not correct in two places:

a) gst_value_deserialize_int_helper

There's *to = g_ascii_strtoull (s, &end, 0), which only works on unsigned strings. Later on the return value of this is even checked if it's smaller than zero ;)
IMHO this should be _strtoll() instead. Am I missing something?

Also there should probably be a check that checks if the deserialized value is in the [min,max] range...

b) gst_value_deserialize_u*

Here the _unsigned_ result of g_ascii_strtoull() is stored in a gint64, thus things like overflows can happen easily.

Checks if the value is between [min,max] should be added here too I guess...


Is my analysis correct? If so I'll prepare a patch later...
Comment 1 Sebastian Dröge (slomo) 2008-05-04 08:37:28 UTC
Ok, I'm looking closer at it now and there are actually a few problems with that code... will explain later with a patch :)
Comment 2 Sebastian Dröge (slomo) 2008-05-05 09:22:07 UTC
Ok, so we're currently deserializing "-1" into unsigned integer types and allow deserializing out of range values into several integer types.

Fixing this might break other things so we should probably wait for this until 0.11 and clean everything up and make it more strict then.

It might make sense to use a copy of GLib's internal g_parse_long_long() for this as it will give the magnitude of values and it's sign so we can reliably detect all kind of weird things that happen because of overflows currently.
Comment 3 Tim-Philipp Müller 2012-06-27 17:33:06 UTC
> Ok, I'm looking closer at it now and there are actually a few problems with
> that code... will explain later with a patch :)

Four years, and we're still waiting for that patch ;)
Comment 4 Tim-Philipp Müller 2012-08-13 23:20:24 UTC
Sebastian: now is the time - fix or WONTFIX please :-)

A unit test that shows the problem would be helpful too.
Comment 5 Sebastian Dröge (slomo) 2013-07-17 11:08:02 UTC
Let's just close it, there is no real bug caused by this and code is depending on the current behaviour.