|Anonymous | Login||02-21-2020 10:02 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0001070||[Squeak] VM||crash||always||04-13-05 03:12||06-07-05 21:01|
|Summary||0001070: Major holes in VM space security|
Whilst looking at the suggested fix for 0001041 (LowSpaceAndInterruptHandler-dtl) I noticed several nasty places where the VM space security can be violated (sounds cool, eh. Commander! Space Security has been violated! Launch all StarFuries!) and the vm crashed without it even having a chance to bleat.
The internal nasty (the bug under the rug) is primitiveClone. It doesn't bother to check at all for sufficient space! Make a big bitmap, clone it a few times and blammo; no checking for lowspace will even be attempted. If by chance this were done in aloop where some other allocation got done it might possibly survive since 'proper' allocations will in effect do the space checking for it.
An external bug resides in primitiveClipboardText. Again, no checking for sufficient space and if some dimwit (aka 'user') happens to copy the entire text of War and Peace then most machines will get upset. Worse yet, the EU directive on the transport of duck eggs by road.
There are other uncheck users of #instantiateClass:indexableSize: but they mainly seem fairly innocuous. Making a String for a directory path is unlikely to be a major issue but just maybe. Most others are pretty constrained.
Fixing primitveClone is pretty obvious. Althoug it might seem obvious to add space checking to all the others as well it would be nice to avoid the performance hit if possible.We could for example add the check inside the #instantiate code but that would require rewriting almost every sender to deal with a failure return.
(0001490 - 132 - 144 - 144 - 144 - 144 - 144)
primitiveClone cleaned up. primitiveClipboard ditto. At least they won't calmly blow the VM away anymore.
VMMaker updated for 3.8
(0001493 - 31 - 31 - 31 - 31 - 31 - 31)
|in VMMaker 3.8 release due soon|
(0001594 - 60 - 60 - 60 - 60 - 60 - 60)
|Changes added to VMMAker codebase. No further action needed.|
|04-13-05 03:12||tim||New Issue|
|04-13-05 03:12||tim||Relationship added||related to 0001041|
|04-20-05 22:56||tim||Status||new => assigned|
|04-20-05 22:56||tim||Assigned To||=> tim|
|05-15-05 06:29||tim||Note Added: 0001490|
|05-16-05 19:59||tim||Status||assigned => resolved|
|05-16-05 19:59||tim||Fixed in Version||=> 3.8|
|05-16-05 19:59||tim||Resolution||open => fixed|
|05-16-05 19:59||tim||Note Added: 0001493|
|06-07-05 21:01||tim||Status||resolved => closed|
|06-07-05 21:01||tim||Note Added: 0001594|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
51 total queries executed.|
37 unique queries executed.