stack corruption in the webservice code

[Lubomir I. Ivanov]

On 9 December 2013 17:56, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> on win32 i'm getting some memory corruption. prepare_dives_for_divelogs() is
> based on the GTK code miiaka wrote (if i remember correctly) and it has a
> local variable named 'tempfile'. now, everything is fine, however at one point
> get_stylesheet() changes the contents of the local variable
> 'tempfile', which isn't a good sign. i suspect buffer overflow in parse-xml.c:
> get_stylesheet()/try_get_stylesheet(), but i haven't investigated that.
>

just investigated more into this,

this is stack corruption where calls in
subsurfacewebservices.cpp:prepare_dives_for_divelogs() override the
memory pointed by 'tempfile', *after* it already holds it's correct
value (e.g. /temp/somefile.dld). the only solution for now is to give
back 'tempfile' the sane value, as this is the actual function return.

the odd part comes from the fact that it is caused from one library on
win32 (libxslt-1.1.26), and from another on linux (libxml2-2.7.8) -
both fairly recent versions, but also related to the same authors and
the gnome project.

the faulting calls:
- for libxslt is xsltParseStylesheetFile(), which can be seen in
parse-xml.c:try_get_stylesheet()
- for libxml2 is xmlReadMemory() in :prepare_dives_for_divelogs() -
and more in particular xmlDictCreate()

here is the linux case:
-----
Hardware watchpoint 6: *0x1578c48
(gdb) print (char *)0x1578c48
$1 = 0x1578c48 "/tmp/import-86278918.dld"
...
Old value = 1886221359
New value = 0
0x00007ffff7b78ff1 in xmlDictCreate ()
   from /usr/lib/x86_64-linux-gnu/libxml2.so.2
Single stepping until exit from function xmlDictCreate,
which has no line number information.

(gdb) print (char *)0x1578c48
$2 = 0x1578c48 ""
-----

given these are two separate issues on two different os/compilers, i
don't have other explanations to why it happens and it looks like a
generic buffer overflow inside those library calls, which means we
can't do much about.

the strange part is why we never had a crash thus far?
also, i don't think i ever saw memory debuggers complain about that.

lubomir
--