>>> Moin Moin, >>> >>> So it seems that the "buffer exploit" that's running around UrT >>> servers is related to the QVM, at least from what I can tell that's >>> where it segfaults for the x86 QVM (using the interpreted QVM I get >>> "VM program counter out of range in OP_LEAVE" instead, still a crash). >>> This brings up the following question: Is the QVM designed to be safe >>> or not? It seems that a bug in the game code running on the VM will >>> happily crash a server. If the QVM is "by design" unsafe then the only >>> good fix for this will have to come from FrozenSand or whatever they >>> are called these days. On the other hand, if the QVM is supposed to be >>> safe, then I guess it's a VM bug. Advice? >>> >> >> Yes, this is absolutely a QVM bug. You can patch this via ioq3 code, >> which is what I have done. It's a dirty little patch but it works. >> The patch has been available for many months now: >> >> http://forums.urbanterror.info/topic/18495-svn-repository-for-iourbanterror-exploit-fixes/ > > Patches that aren't submitted to this list or bugzilla will (nearly) never be > applied. > > In this case, though, I'm inclined to blame urt for being closed-source > toilet brushes about everything. >
My patch isn't worthy of being included in ioquake3; it's a total hack job to get around a UrT QVM bug. So yes, what you said about toilets is probably true. _______________________________________________ ioquake3 mailing list [email protected] http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
