linuxdcpp-team team mailing list archive

[Big Muscle <901237@xxxxxxxxxxxxxxxxxx>]

Same crash in similar situation:

Remote user is in more hubs with different nicks. I ask for his partial
filelist from one hub so it is added with 1st nick.CID into the queue.
Before the list is finished, user leaves this hub so only 2nd nick
remain valid. Although user is still online, partial filelist will
normally be downloaded and same wrong behaviour (described above)
appears after that.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/901237

Title:
  Possible crash by remote client when downloading partial filelist

Status in DC++:
  Confirmed

Bug description:
  This report is just about the bug we discussed in DCDev yesterday.

  * when client wants to download full/partial filelist, the list name is generated as <current_nick>.<CID>
  * when partial filelist is finished, it must be found in queue so it is deleted from there. However, the list name is generated again as <current_nick>.<CID>
  * if remote user's nick is changed before the list is finished, the item will not be found in the queue and stay there forever
  * problem is that object responsible for downloading (class Download) is deallocated correctly which result that non-deleted queue item holds info about invalid Download object.
  * when operation above this object is performed (e.g. item is deleted from queue later), it will end up with access violation

  Possible remote exploit:
  When partial list request is received, send BINF with new nick to hub, wait a second and then normally provide partial list to the client.

  Behaviour:
  Client requesting partial list will end up in infinite downloading of partial list.. Assertion in QueueManager::addDownload is hit on every request in debug build.
  When deleting the list from queue manually, it can crash. It does not crash always but I think it depends whether the "invalid" memory has already been reused or not.

  Possible solutions:
  a) generate filelist name as <CID> only (I guess on-the-fly CID change is not allowed)
  b) do not perform queue search by new generation of list name but use different method.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/901237/+subscriptions