Bug #168

memory leak in DCERPC handling

Added by Victor Julien almost 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:05/26/2010
Priority:NormalDue date:06/21/2010
Assignee:Kirby Kuehl% Done:

100%

Category:-Estimated time:2.50 hours
Target version:1.0.0

Description

It seems the DCERPC parser doesn't always properly free the memory it's using.

18927 275,731 (273,472 direct, 2,259 indirect) bytes in 8,546 blocks are definitely lost in loss record 868 of 874
18927 at 0x4023F5B: calloc (vg_replace_malloc.c:418)
18927 by 0x824D292: DCERPCParseBINDCTXItem (app-layer-dcerpc.c:254)
18927 by 0x8251880: DCERPCParser (app-layer-dcerpc.c:1105)
18927 by 0x8243077: DataParser (app-layer-smb.c:584)
18927 by 0x82445E4: SMBParseByteCount (app-layer-smb.c:729)
18927 by 0x82479CA: SMBParse (app-layer-smb.c:1129)
18927 by 0x822BC32: AppLayerDoParse (app-layer-parser.c:655)
18927 by 0x822D3FB: AppLayerParse (app-layer-parser.c:861)
18927 by 0x821FF0E: AppLayerHandleMsg (app-layer.c:174)
18927 by 0x820304F: StreamTcpReassembleProcessAppLayer (stream-tcp-reassemble.c:1911)
18927 by 0x81EDE2B: StreamTcpPacket (stream-tcp.c:2509)
18927 by 0x81EE045: StreamTcp (stream-tcp.c:2527)

0004-fix-smb-leak.patch Magnifier (1.37 KB) Kirby Kuehl, 06/19/2010 05:50 PM

History

#1 Updated by Victor Julien almost 4 years ago

  • Due date changed from 06/04/2010 to 06/21/2010
  • Target version changed from 0.9.2 to 0.9.3

#2 Updated by Kirby Kuehl almost 4 years ago

Do you have a packet capture that generates this leak, or how was it produced? Starting to investigate with valgrind.

#3 Updated by Kirby Kuehl almost 4 years ago

Nevermind, found the leak just by looking. Patch coming soon.

#5 Updated by Victor Julien almost 4 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Applied, thanks Kirby.

#6 Updated by Victor Julien almost 4 years ago

  • Target version changed from 0.9.3 to 1.0.0

Also available in: Atom PDF