| Summary: | txtwrite: use after free in 9.51 on some files (regression from 9.50) | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | James R Barlow <james> |
| Component: | Other Driver | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bernhardu |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: | mallocissue.pdf | ||
Running with memento, with paranoidAt=396200 shows that txt_add_fragment
devices/vector/gdevtxtw.c line 2126:
memcpy(penum->text_state->Widths, penum->Widths, penum->text.size *
sizeof(float));
writes past the end of penum->text_state->Widths since it was allocated as
4 floats, but penum->text.size is 8
penum->TextBufferIndex is 4 which was used for the allocation at line 2121.
It may be that all that is needed is to allocate text.size floats, but this
should be examined by someone that knows what it's trying to do.
*** Bug 702346 has been marked as a duplicate of this bug. *** I believe this is fixed in commit 8c7bd787defa071c96289b7da9397f673fddb874 Certainly I don't see any problems with address sanitizer/valgrind when running either this file, the one from bug 702346 or the one from 701877 |
Created attachment 19003 [details] mallocissue.pdf On macOS the error looks like: $ gs -dQUIET -dSAFER -dBATCH -dNOPAUSE -sDEVICE=txtwrite -dTextFormat=0 -o - mallocissue.pdf -stddout=%stderr gs(98147,0x11082a5c0) malloc: Incorrect checksum for freed object 0x7fa850d096d8: probably modified after being freed. Corrupt value: 0x6000000000000 gs(98147,0x11082a5c0) malloc: *** set a breakpoint in malloc_error_break to debug fish: Job 2, 'gs -dQUIET -dSAFER -dBATCH -dNO…' terminated by signal SIGABRT (Abort) A similar error was also reproduced on Debian Linux.