Tk Source Code

View Ticket
Login
Ticket UUID: cc42cc18a57dabe9a50ce84060c999a6ff122c14
Title: A corrupted image can cause resource exhaustion
Type: Bug Version: tk8.6.7
Submitter: anonymous Created on: 2017-08-17 11:10:21
Subsystem: 41. Photo Images Assigned To: fvogel
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2017-08-24 19:44:22
Resolution: Fixed Closed By: fvogel
    Closed on: 2017-08-24 19:44:22
Description:
It is as in:

https://core.tcl.tk/tk/tktview?name=b601ce3ab1

Content of tmp. after 
"make test TESTFLAGS="-file imgPhoto.test -verbose bepst" > tmp." 
is:

>>
[...]
++++ imgPhoto-17.2 PASSED
---- imgPhoto-17.3 start
++++ imgPhoto-17.3 PASSED
++++ imgPhoto-18.1 SKIPPED: base64PackageNeeded
---- imgPhoto-18.2 start
*** Signal 9

Stop.
make: stopped in /usr/opt/tcl86/src/tk/unix
<<

I get System message:

>>
> swap_pager: out of swap space
> swap_pager_getswapspace(16): failed
<<

Although I have 2GB RAM and also so much swap space.
User Comments: fvogel added on 2017-08-24 19:44:22:
Merged to core-8-6-branch and trunk. Thanks!

fvogel added on 2017-08-23 21:13:13:

Thank you, Keith, for the patch!

Since it's a fix of the fix, I have applied it on the branch previously used to deal with this bug, that is branch bug-b601ce3ab1 (warning: this is a branch off core-8-5-branch).

I tried it on Linux Debian 8 and on Windows. I ran successfully the standard command (skipping nonPortable tests), and also just the nonPortable tests (to check they still passs on my systems), i.e. with:

TESTFLAGS="-file imgPhoto.test -verbose beps -constraints nonPortable -limitconstraints true"
and everything is OK on my machines.


fvogel added on 2017-08-23 14:13:37:
Thank you for your analysis and patch to come.

IMO the 'knownBug' constraint is inadequate here because (from tcltest man page) it means that the bug corresponding to the test is hot not yet fixed. This is not the case.

I wanted to suggest creation of a new constraint 'hasAtLeast4GBmem', or similarly named, that would be assessed at runtime from the available free system memory, but then I realized that there is no way I know of to get the necessary info at script level (without resorting to platform-dependent tricks at least).

So I suggest using 'nonPortable' instead of 'knownBug'. From its description in the tcltest tallest man page it seems adapted to the case.

kjnash (claiming to be k.j.nash@usa.net) added on 2017-08-23 12:13:04:
The bug is:
If there is insufficient memory, the error message
"not enough free memory for image buffer" should be returned.
Instead, some systems (e.g. FreeBSD 11.1) terminate the test interpreter.

This ticket relates to this bug report on c.l.t. -
https://groups.google.com/forum/#!topic/comp.lang.tcl/fuz94EZ04Ps
"Tcl8.6.7 failed Tests on FreeBSD 11.1"

@fvogel

I believe bug [b601ce3ab1] is fixed, the problem here is in the tests.  I will post a patch for the tests shortly.  Tests 18.1 to 18.3 will request much less memory.  Tests 18.7 to 18.9 will continue to request multi-Gb but will have the constraint "knownBug".

In detail:

The tests for [b601ce3ab1] accidentally expose a separate bug related to memory allocation.

Tk allocates a buffer according to the size requested by the header of the GIF image.  If the image is corrupt or malicious, it may request a very large size.  If the buffer is successfully allocated, and then the corrupt image fails to load, Tk then frees the memory, and the Tk command returns with error status as expected by the test.

When there is insufficient memory on Linux and Windows systems, the Tk command returns with error status and the message "not enough free memory for image buffer" - this error message is defined in generic/tkImgPhoto.c.

On FreeBSD 11.1 this allocation error appears not to be trapped, and the Tcl process is terminated.  I do not have sufficient knowledge of memory allocation in Tcl/Tk to determine whether this is a bug in Tk or a limitation of FreeBSD's malloc.

fvogel added on 2017-08-17 18:40:28:

Cannot reproduce this on Linux Debian 8 (real machine, not a VM) with 8 Gb memory.

Memory usage climbs to 3.4 Gb during these tests.

Hypotheses:

- Perhaps the test should be constrained to run only on machines featuring large amounts of memory

- Perhaps the test should be reworked to require less memory to run

- Perhaps bug [b601ce3ab1] is not fixed after all (I doubt)


Attachments: