[PATCH 3/3] main_edit.c: Use strncpy() to eliminate potential buffer overflow.
Gedare Bloom
gedare at rtems.org
Thu Mar 14 13:50:23 UTC 2019
On Thu, Mar 14, 2019 at 9:22 AM Joel Sherrill <joel at rtems.org> wrote:
> ---
> cpukit/libmisc/shell/main_edit.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/libmisc/shell/main_edit.c
> b/cpukit/libmisc/shell/main_edit.c
> index 079e9ff..e43ff68 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env,
> char *filename) {
> struct editor *ed = env->current;
> struct editor *start = ed;
>
> - if (!realpath(filename, fn)) strcpy(fn, filename);
> + if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
>
> do {
> if (strcmp(fn, ed->filename) == 0) return ed;
> @@ -297,7 +297,7 @@ static struct editor *find_editor(struct env *env,
> char *filename) {
>
> static int new_file(struct editor *ed, char *filename) {
> if (*filename) {
> - strcpy(ed->filename, filename);
> + strncpy(ed->filename, filename, FILENAME_MAX);
>
if strlen(filename) > FILENAME_MAX, ed->filename will not be NUL-terminated.
> } else {
> sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
> ed->newfile = 1;
>
Unrelated: why doesn't 'ed->newfile = 1;' happen down the other code path
(when a filename is given)?
> @@ -1752,7 +1752,7 @@ static void read_from_stdin(struct editor *ed) {
> insert(ed, pos, (unsigned char*) buffer, n);
> pos += n;
> }
> - strcpy(ed->filename, "<stdin>");
> + strncpy(ed->filename, "<stdin>", FILENAME_MAX);
>
overkill -- "<stdin>" has a fixed known size.
> ed->newfile = 1;
> ed->dirty = 0;
> }
> @@ -1775,7 +1775,8 @@ static void save_editor(struct editor *ed) {
> return;
> }
> }
> - strcpy(ed->filename, (const char*) ed->env->linebuf);
> + strncpy(
> + ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
> ed->newfile = 0;
> }
>
> --
> 1.8.3.1
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190314/235072ff/attachment-0002.html>
More information about the devel
mailing list