bound ft2font stream read to the requested count#31857
Conversation
|
I used AI tools (Claude and ChatGPT) to help with code navigation, repository research, and understanding the relevant code paths. The investigation, validation, testing, and final code changes were performed and verified manually by me. I understand the change and can answer questions about the implementation and reasoning behind it. |
|
Neither triggered through a normal code path, no. I was reading the file-object path in ft2font_wrapper.cpp by hand and noticed the callback memcpy'd len(file.read(count)) bytes into a buffer FreeType had sized for count, so the bound depended entirely on the file object behaving. I then confirmed it under ASAN with a file object whose read() returns more than requested: before the fix that's a heap write past the end of FreeType's buffer, after it the read is rejected and FT2Font raises. You can't hit it from the filename path or any well-behaved stream; it takes a file-like object that over-returns (say, a wrapper that transparently decompresses), which is also why the fix treats it as a broken object rather than trying to use the extra bytes. #31860 isn't mine, so I can't speak to how that one was found. |

read_from_file_callback copies len(file.read(count)) bytes into the buffer FreeType hands it, but that buffer is only sized for count. When a font is opened from a binary-mode file object (the io.BinaryIO path), nothing obliges the object's read() to honor the requested size, so a read() that returns more than count walks past the end of the FreeType buffer and corrupts the heap.
Cap n_read at count before the memcpy so both the copy and the returned length stay inside the allocated buffer. Before, an over-long read wrote out of bounds; after, the surplus bytes are dropped and FreeType just sees a full-buffer read. The bound sits in the callback because FreeType owns the buffer size, not the caller; the only tradeoff is that a file object returning more than it was asked for loses the bytes past count, which were never going to be used.