Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UBJSON] Possible stream size exceeds QByteArray #343

Closed
svenpilz opened this issue May 26, 2015 · 2 comments
Closed

[UBJSON] Possible stream size exceeds QByteArray #343

svenpilz opened this issue May 26, 2015 · 2 comments
Labels

Comments

@svenpilz
Copy link

Regarding the new UBJSON implementation.

The readSize function returns a size_t, while the resulting QByteArray takes an int as parameter. If size is greater then 2^31-1, then the constructor of QByteArray segfaults, because the int is negative.

See: gui/qubjson.cpp:160.

@jrfonseca
Copy link
Member

I'll add a few checks.

But there's not much we can do to cope with that ATM. This is not the sole QByteArray use case of in qapitrace. QByteArray is used in a several places. So it will not cope with more than INT_MAX in neither of them.

Hopefully this won't happen in practice for a little longer.

But I can see this being a problem down the line -- sometimes we expand smaller pixels to 4xfloat when duping, which multiplies their size.

@jrfonseca jrfonseca added the GUI label May 26, 2015
jrfonseca added a commit that referenced this issue May 27, 2015
To prevent dump size explosion as reported on issue #344 and #343.
jrfonseca added a commit that referenced this issue May 27, 2015
Sooner or later this issue will become important. But hopefully in the
meanwhile it should be rare.
@jrfonseca
Copy link
Member

I added an assert, and an URL to this issue. I'm sure this will happen again in the future, but now that we don't explode unsized internal formats so much, it should be OK for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants