[FIXED] UOX3 crashes if user opens crowded ADD-menu-section

[Xuri]

If a section of the ADD menu contains too many items ( length > 65536 ?), UOX3 will crash when someone tries opening that section of the menu.

[Maarc]

If Length is > 65536, then definitely, and there's nothing you can do about it. The packet header includes only a 2 byte length field, which means the packet just can't be physically that long. Break it up into smaller menus, though I thought that there were some placeholder checks in there to verify it wasn't too bad. Guess I was wrong

[Xuri]

This one?

Code: Select all

if( length > 65536 )
	throw std::runtime_error( "Packet 0xB0 is far too large" );

[Xuri]

*bump*

We need a working placeholder check to ensure that UOX3 won't crash if someone creates a too long add-menu section

[giwo]

We should work on incorporating zlib librarys and making use of the new packed gump packet. This should (to some extent) resolve this issue.

[Maarc]

Yes, it'll help somewhat. The zip lib compressed gumps gives us an excuse to use it elsewhere potentially, as well (saves, archives, compressed dirs of DFNs, that sort of thing).

But ultimately ... the user really shouldn't be making an add menu that long. And it's either crash and burn, or not send it at all. Because if you send it, you can lead to client crashes, lockups, or for more fun, you always run the risk of corrupted data.

[Xuri]

Invalidating this bug, since there's nothing we can do about it? and it's ultimately an issue that server admins can avoid with little effort in any case.