[ADC] crash on invalid utf-8 string (linux)

Bug #300268 reported by E_zombie
2
Affects Status Importance Assigned to Milestone
DC++
Fix Released
High
Unassigned
LinuxDC++
Fix Released
High
Steven Sheehy

Bug Description

linuxdcpp rev 28 crashed when connect to ADC hub when hub sent MOTD to client. See in attachment. I think it connected with encoding MOTD file on hub.
ADC hub uhub 0.2.3 . adc://adc.volsk.san.ru:12000

$ linuxdcpp
Thrown: FileException: Could not open file
Thrown: FileException: Could not open file
Loading: Hash database
Loading: Shared Files
UnBZFilter end, 1597021/510485 = 3,1284
Loading: Download Queue
Skipping secure port: 0
BufferedSocket::run() start 0x7f53f4042f50
BufferedSocket::connect() 0x7f53f4042f50
threadConnect adc.san.ru:10000
Thrown: SocketException: Connection closed
BufferedSocket::run() start 0x7f53f4086150
BufferedSocket::connect() 0x7f53f4086150
threadConnect adchub.death-squad.ro:1111
BufferedSocket::run() start 0x7f53f40ae1d0
BufferedSocket::connect() 0x7f53f40ae1d0
threadConnect adc2.san.ru:10000
Thrown: SocketException: В соединении отказано
BufferedSocket::run() start 0x7f53f40b8ea0
BufferedSocket::connect() 0x7f53f40b8ea0
threadConnect adc3.san.ru:10000
BufferedSocket::run() start 0x7f53f416f290
BufferedSocket::connect() 0x7f53f416f290
threadConnect adc.volsk.san.ru:1411
Thrown: ParseException: Too short
Invalid ADC command:
BufferedSocket::run() start 0x7f53f43b3d30
BufferedSocket::connect() 0x7f53f43b3d30
threadConnect adc.volsk.san.ru:12000
segmentation error

Revision history for this message
E_zombie (lv77) wrote :
Revision history for this message
qwertitis (qwertitis-deactivatedaccount) wrote :

[New Thread 0xb462db90 (LWP 7666)]
BufferedSocket::run() start 0x870b7d8
BufferedSocket::connect() 0x870b7d8
threadConnect adc.volsk.san.ru:12000

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb57ccb90 (LWP 7659)]
0xb788f067 in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0
(gdb) bt full
#0 0xb788f067 in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#1 0xb7c96b5f in gtk_widget_set_property (object=0x86d7ad8, prop_id=21,
    value=0xb57cc214, pspec=0x83164c0)
    at /build/buildd/gtk+2.0-2.12.9/gtk/gtkwidget.c:2447
 saved_flags = <value optimized out>
 tooltip_markup = (gchar *) 0x0
 tooltip_text = (const gchar *) 0x86e9e50 "\b0\203��>\n"
 widget = <value optimized out>
#2 0xb7918c26 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#3 0xb79191e6 in g_object_set () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#4 0xb7c8b031 in IA__gtk_widget_set_tooltip_text (widget=0x86d7ad8,
    text=0x86ca1d4 "Hub: VOLSK - �������� ���")
    at /build/buildd/gtk+2.0-2.12.9/gtk/gtkwidget.c:9609
 __PRETTY_FUNCTION__ = "IA__gtk_widget_set_tooltip_text"
#5 0x080558d5 in BookEntry::setLabel_gui (this=0x86e33a0, text=@0xb57cc340)
    at linux/bookentry.cc:87
 child = (GtkWidget *) 0x8708810
 len = -1250114808
#6 0x080aaaaf in Func1<Hub, std::string>::call (this=0x869b818)
    at linux/func.hh:70
---Type <return> to continue, or q <return> to quit---
No locals.
#7 0x0814e4be in WulforManager::processGuiQueue (this=0x8317e08)
    at linux/wulformanager.cc:181
 func = (FuncBase *) 0x869b818
#8 0x0814e567 in WulforManager::threadFunc_gui (data=0x8317e08)
    at linux/wulformanager.cc:148
 man = (WulforManager *) 0x8317e08
#9 0xb78b2d2f in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#10 0xb7f5d4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
#11 0xb76b6e5e in clone () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
(gdb)

Changed in linuxdcpp:
assignee: nobody → individ
status: New → Confirmed
Revision history for this message
qwertitis (qwertitis-deactivatedaccount) wrote :

There could be a bug in the hub, since it seems like invalid utf-8 is transferred as hub description.

GTK crashes because it receives an invalid utf-8 string. The code in hub.cc assumes that dcpp checks this, which happens for NMDC but not for ADC, at least not for the hub description.

Revision history for this message
Razzloss (razzloss) wrote :

Shouldn't this be fixed in the dcpp/ instead? In AdcHub::on(Line) maybe before anything else is done? I assume that the adchub should only send (valid) UTF-8 and not binary data or use any other encoding. Validating it when it comes in would save us the trouble later.

--RZ

Revision history for this message
qwertitis (qwertitis-deactivatedaccount) wrote :

Yes, changing dcpp would be better, and ADC is limited to utf8. Do you know a non-glib function to validate utf-8? There's iconv, but it would be better if we could avoid making a copy of each string.

Changed in linuxdcpp:
assignee: individ → nobody
Revision history for this message
Steven Sheehy (steven-sheehy) wrote :

This needs to be fixed in the DC++ core. The core should always validate data it receives from external sources before sending on to the GUI. In this case, the core needs to validate that the text sent from an ADC hub or client is actually UTF-8; it cannot assume it is UTF-8 just because that is what the protocol expects.

Changed in linuxdcpp:
importance: Undecided → High
Revision history for this message
Jacek Sieka (arnetheduck) wrote :

fixing in core indeed makes sense

Changed in dcplusplus:
importance: Undecided → High
status: New → Confirmed
Changed in dcplusplus:
status: Confirmed → Fix Committed
eMTee (realprogger)
Changed in dcplusplus:
status: Fix Committed → Fix Released
Changed in linuxdcpp:
assignee: nobody → Steven Sheehy (steven-sheehy)
milestone: none → 1.1.0
status: Confirmed → Fix Committed
Changed in linuxdcpp:
status: Fix Committed → Fix Released
tags: added: adc charset core crash
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.