0004544: cut reads/writes invalid memory for certain inputs

[Cristian Cadar]

  Hello, I already reported about a dozen bugs on the Busybox bug
tracking system, all of which Denys confirmed and fixed promptly.
Thanks again.  I understand that I should also report the bugs entered
in the bug tracking system to this list, which I'll do for the new bugs
we find.  As mentioned before, these bugs are found by an automatic
tool, which we are currently developing at Stanford.

  Here is a bug in cut reported at
  http://bugs.busybox.net/view.php?id=4544

  I think the problem occurs when you have lines containing only
delimiters.

Here is a simple example:

cut -f- A

where A contains "\t\n" (one tab, one newline)


 53: char *printed = xzalloc(linelen * sizeof(char));
...
125:                    for (; cl_pos < nlists && line; cl_pos++) {
126:                            spos = cut_lists[cl_pos].startpos;
127:                            do {
128:                                    /* find the field we're looking
for */
129:                                    while (line && ndelim < spos) {
130:                                            field = strsep(&line,
delimiter)
;
131:                                            ndelim++;
132:                                    }
133:
134:                                    /* we found it, and it hasn't
been printed yet */
135:                                    if (field && ndelim == spos && !
printed[ndelim]) {
...
142:                                            printed[ndelim] = 'X';

On cut.c:53, the buffer printed is allocated.  In our example it has
size 1.  On the first iteration through the loop on line 125, line is
"\t".  The call to strsep on line 130 returns "" and sets line to "".

Since line is not NULL, a second iteration through the do-while loop
is performed.  This time the call to strsep sets line to NULL.  When
line 135 is executed again, printed is indexed by ndelim, which now
has value 1, and so printed[ndelim] reads past the buffer printed.
Later, on line 142, this invalid location is also written.

I think the fix might be to simply increase the size of printed by 1,
but I haven't looked closely enough at the code.

Thanks,
Cristian