Summary: | mmap()/alloc()ing 6.3GB when parsing certain .mp3 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] taglib | Reporter: | Hans Ecke <hans> |
Component: | general | Assignee: | Scott Wheeler <wheeler> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Hans Ecke
2007-01-23 22:00:42 UTC
SVN commit 633123 by wheeler: Add another sanity check -- don't let invalid frames try to allocate anything larger than the tag size. BUG:140515 M +4 -1 id3v2framefactory.cpp --- trunk/kdesupport/taglib/taglib/mpeg/id3v2/id3v2framefactory.cpp #633122:633123 @@ -73,7 +73,10 @@ // A quick sanity check -- make sure that the frameID is 4 uppercase Latin1 // characters. Also make sure that there is data in the frame. - if(!frameID.size() == (version < 3 ? 3 : 4) || header->frameSize() <= 0) { + if(!frameID.size() == (version < 3 ? 3 : 4) || + header->frameSize() <= 0 || + header->frameSize() > data.size()) + { delete header; return 0; } My personal guess is that the problem is not in frame size reading code, but in data length (for compressed frames) reading code. According to the spec it's a synch-safe integer, TagLib reads it as a regular 32-bit integer. I had the demo file here and verified the fix. The frame wasn't actually compressed -- there was an invalid frame length, which landed the tag parser in a funny spot that looked close enough to a frame that TagLib tried to parse it as one. Fix verified. Thank you very much. Now amarok works again for me. |