| Summary: | mmap()/alloc()ing 6.3GB when parsing certain .mp3 | ||
|---|---|---|---|
| Product: | [Unmaintained] taglib | Reporter: | Hans Ecke <hans> |
| Component: | general | Assignee: | Scott Wheeler <wheeler> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
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. |