norfanin
There are a few potential buffer overflows in the Windows IME code located in the SDL_windowskeyboard.c file. [1] They mainly happen because the code passes the number of bytes instead of the number of characters to the wide-character string functions wcslcpy and wcslcat. In another place, the code assumes that the composition cursor position can never go beyond the size of the composition string buffer.
Some of these overflows and overruns can occur with the Japanese IME on Vista and simplified Chinese IME on XP. I don't actually speak those languages and it's my first time using the IMEs, so I probably pushed them to the limit where nobody would still be compositing proper words. They don't cause any immediate access violation, although the possibility of trashing the SDL_VideoData structure is never good.
I've attached a patch that fixes those I found, but because I'm very new to the code it may be worthwhile if someone else also has a look over the code.
I'll go over the changes in my patch and explain what, why and how.
In the function IME_GetReadingString, there is a wcslcpy to copy the reading string from the IMC memory to the SDL reading string buffer. [2] This assumes that the length of the reading string never exceeds the SDL buffer size. I guess that is possible and I wasn't able to get a long reading string in my tests, but the patch adds a simple check anyway.
In the function IME_GetCompositionString, the first line calls ImmGetCompositionStringW to get the composition string. [3] The Microsoft documentation states that the fourth argument is for the destination buffer size in bytes (even with unicode) and the code correctly passes the value of sizeof. However, at the end of IME_GetCompositionString, the string is terminated by setting the element at index 'length' to 0. 'length' is calculated by dividing the number of bytes (those written by ImmGetCompositionStringW) by 2. If it managed to write 64 bytes, the code sets element 32 to 0, which would be the beginning of the reading string if the alignment places it there. My patch adds a subtraction to the fourth argument, essentially making it always pass 62 instead.
In the same function, the code assumes that the composition cursor position doesn't go beyond the buffer size. [4] My patch adds a simple range check in front of the indirection.
In the function IME_SendEditingEvent, the size for the wide-character string functions is passed in bytes instead of characters. [5] Oddly, the current code subtracts 'len' from the size in one function call. This results in truncation in certain situations as the third argument is the number of characters available in the destination buffer. If I'm understanding it correctly, this is supposed to copy x characters of the composition buffer, then concatenate the whole reading string buffer, and then the rest of the composition buffer (where x is the composition cursor position). I don't see how a truncation of the rest would be helpful here. Perhaps this is just an error? My patch removes the subtraction.
In the function UIElementSink_UpdateUIElement, bytes instead of characters is used again for a wcslcpy call. [6]
PoopiSan
GLES2_RenderReadPixels, GLES_RenderReadPixels, GL_RenderReadPixels and possibly other backends is incorrectly implemented.
If the current target viewport is different than window size the function is reading garbage and according to the function documentation should work with any rendering target "Read pixels from the current rendering target.".
this seems to be caused by this line:
...
SDL_GetWindowSize(window, &w, &h);
The SDL OpenGL context code is now properly thread aware. There are two new functions which return the current OpenGL window and context for the current thread.
There are still places in the cocoa driver where the OpenGL context needs to be updated when the view changes. These will need a different solution and still use the last globally set context to avoid changing behavior.
Ryan C. Gordon
We have this in Cocoa_GL_SwapWindow()...
/* FIXME: Do we need to get the context for the window? */
[[NSOpenGLContext currentContext] flushBuffer];
...which means if the current GL context is not the one in (window), we swap a different one than requested.
Right now, we don't store information about which context is assigned to which window, and the OS doesn't give you a way to retrieve it from an NSView. We would have to track this per-window during SDL_GL_MakeCurrent() (and SDL_GL_CreateContext) calls.
This is what SDL 1.2 did; we'll do this properly (add a method for the target
driver to pause) when I rewrite all this code after the official 2.0 release.
Fixes Bugzilla #1857.
We now do FULL or NO accel based on the app's preference. If the app didn't
specify, we do FULL then fall back to NO.
(Not specifying anything--a true "don't care" scenario--breaks some ATI
drivers, so we try to keep to the spirit of it while forcing a specific
state.)
Previously, it would always do FULL, and try NO if it failed and the app
had requested NO or DONTCARE.
This is a transplant of hg changesets a04171d6fa11 and d0b7c45e982e from the
SDL-1.2 branch.
Fixes Bugzilla #1254.
--HG--
extra : rebase_source : db951d96e685e17a4d71fe2aa3d65043661ccccc
Matt Scheirer
Pulse has supported (since version 0.8, at least) 32 bit audio formats that are now becoming available in SDL2. This patch adds those format conversions to the switch clause in the pulseaudio backend.
Nitz
In Function X11_DispatchEvent(_THIS), case SelectionNotify :
static void
X11_DispatchEvent(_THIS)
{
// Some Code
case SelectionNotify: {
//Some Code
SDL_bool expect_lf = SDL_FALSE;
char *start = NULL; // Initialised with NULL
char *scan = (char*)p.data;
char *fn;
char *uri;
int length = 0;
while (p.count--) {
if (!expect_lf) {
if (*scan==0x0D) {
expect_lf = SDL_TRUE;
} else if(start == NULL) {
start = scan;
length = 0;
}
length++;
} else {
if (*scan==0x0A && length>0) {
uri = malloc(length--);
memcpy(uri, start, length); // Problem is Here, start is still NULL if control comes to else statement without initialising the start pointer, which is wrong
uri[length] = 0;
fn = X11_URIToLocal(uri);
if (fn) SDL_SendDropFile(fn);
free(uri);
}
expect_lf = SDL_FALSE;
start = NULL;
}
scan++;
}
}
As shown above how start pointer remains NULL, Patch for this issue would be:
if (*scan==0x0D) {
expect_lf = SDL_TRUE;
}
if(start == NULL) {
start = scan;
length = 0;
}
Just replace else if statement with if.
* Added a destructor to clean up TLS memory at thread shutdown
* Refactored the TLS code to have platform independent code and a small platform dependent core with a fallback to generic code if platform dependent functions fail.
* Fixed recursion issues with SDL_GetErrBuf()
