Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.
Showing the changes to kernel/debug (1 of 1 file). Show all
Unified · Split
| @@ -367,14 +367,19 @@ poll_again: · 366 unmodified lines | ||
| 367 | 367 | kdb_printf(kdb_prompt_str); |
| 368 | 368 | kdb_printf("%s", buffer); |
| 369 | 369 | } else if (tab != 2 && count > 0) { |
| 370 | − len_tmp = strlen(p_tmp); | |
| 371 | − strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); | |
| 372 | − len_tmp = strlen(p_tmp); | |
| 373 | − strncpy(cp, p_tmp+len, len_tmp-len + 1); | |
| 374 | − len = len_tmp - len; | |
| 375 | − kdb_printf("%s", cp); | |
| 376 | − cp += len; | |
| 377 | − lastchar += len; | |
| 370 | + /* How many new characters do we want from tmpbuffer? */ | |
| 371 | + len_tmp = strlen(p_tmp) - len; | |
| 372 | + if (lastchar + len_tmp >= bufend) | |
| 373 | + len_tmp = bufend - lastchar; | |
| 374 | + | |
| 375 | + if (len_tmp) { | |
| 376 | + /* + 1 ensures the '\0' is memmove'd */ | |
| 377 | + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); | |
| 378 | + memcpy(cp, p_tmp+len, len_tmp); | |
| 379 | + kdb_printf("%s", cp); | |
| 380 | + cp += len_tmp; | |
| 381 | + lastchar += len_tmp; | |
| 382 | + } | |
| 378 | 383 | } |
| 379 | 384 | kdb_nextline = 1; /* reset output line number */ |
| 380 | 385 | break; |