Confidential Security Report: DoS in TagLib ASF (.wma) handling

[Ximena Molina Portilla]

Hello,


I'm writing to report a denial-of-service vulnerability I found in TagLib's ASF (.wma) handling.


Summary

When saving a .wma file, ASF::File::save() does not validate the header's headerSize field before using it in arithmetic. If an attacker sets headerSize to a value below 30, an unsigned underflow and a subsequent integer overflow cause FileStream::removeBlock() to compute a corrupted target offset, resulting in an unbounded copy loop that fills all available disk space.


Affected component

- File: taglib/asf/asffile.cpp, function ASF::File::save()

- File: toolkit/tfilestream.cpp, function FileStream::removeBlock()

- TagLib version/commit tested: 2.0.2

- OS/package tested: Debian Linux 13


Root cause

headerSize is read directly from the file and stored as an unsigned long long. save() computes headerSize - 30 without checking headerSize >= 30. If headerSize < 30, this subtraction underflows to a value near 2^64 (CWE-191: Integer Underflow). That value is later used in an address calculation inside removeBlock() (header size + new data size + this underflowed value), which itself overflows back past 2^64 (CWE-190: Integer Overflow/Wraparound). The resulting "end of empty space" offset points near the start of the file instead of its actual location, so removeBlock()'s copy loop never reaches a valid end.


Impact

The copy loop keeps writing until the disk is full, at which point the user cannot create or modify any file on the system. This is a resource-exhaustion denial of service (CWE-400), not memory corruption or code execution. Applications that open untrusted .wma files and write/save tags via TagLib (media tag editors, library managers, media servers) would be affected.


I have a minimal crafted .wma file reproducing this and a screen recording of the disk-fill behavior in a sandboxed VM. I'm holding both back from this initial message and can send them privately once we've agreed on a secure way to share them (e.g. a private GitHub security advisory).


Suggested fix

Validate headerSize >= 30 before performing the subtraction, and reject or safely handle files where this invariant does not hold, in both save() and any downstream consumer of the value.


CVE request

Once the issue is confirmed, GitHub's Security Advisory system can assign a CVE ID directly. If you're able to enable private vulnerability reporting on the repo, I'm glad to file the full report there. If you'd rather handle the CVE request yourselves, that's fine too.


Please list the reporter as: Ximena Molina Portilla, Software Engineering student at Instituto Tecnológico de Costa Rica (GitHub: @ximemolina).


I'm following a responsible disclosure timeline and would appreciate acknowledgment within a reasonable window (I'm proposing 40 days) before I consider any further disclosure steps.


Happy to answer any questions or provide additional detail. Looking forward to your reply.


Best regards,

Ximena Molina Portilla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20260909/c0a4d5d4/attachment.htm>