Bug#222073: reassigning to libgtop

Loïc Minier Loïc Minier <lool@dooz.org>, 222073@bugs.debian.org
Fri, 3 Jun 2005 22:04:22 +0200


reassign 222073 libgtop2-5
tags 222073 + fixed-upstream fixed-in-experimental
thanks

On mer, déc 08, 2004, bugs.debian.org@mukesh.agrawals.org wrote:
> 
> I went hunting for the bug, and found it is actually in libgtop.
> 
> libgtop incorrectly parses /proc/<pid>/maps files. The bug is in
> sysdeps/linux/procmap.c, in the glibtop_get_proc_map_s function.
> 
> Here is the errant code:
> 
> 		fn [0] = fgetc (maps);
> 
> 		if (fn [0] != '\n' && fn [0] != EOF) {
> 
> 			fscanf (maps, "%*[ ]%[^\n]\n", fn);
> 
> 		} else fn [0] = 0;
> 
> At this point, glibtop_get_proc_map_s has read all of the fields from
> the current entry in /proc/<pid>/maps, except for the filename. (These
> fields are start, end, flags, offset, dev_major, dev_minor, and inode.)
> 
> The function reads on more character, and if it is not a newline, or EO=
F,
> sucks up any whitespace, and reads the rest of the line as the name of =
the
> mapped file.
> 
> The problem is that, at least with my kernel version (2.6.4) the format=
 of
> the maps entry is
> 
> for regular mappings:
> 	<other fields><space><space><space><space><space><space><filename>
> for anonymous mappings:
> 	<other fields><space>\n
> 
> So the function reads the space into fn[0], then decides that since fn[=
0]
> is not a newline or EOF, there must be a valid filename in the entry. I=
n
> fact, the next character is a newline, and there is no valid filename. =
The
> fscanf will read no valid fields, and leave fn unmodified.
> 
> So the filename associated with this entry will be whatever the
> previous entry's filename was, except that the first character will be
> overwritten with a space.
> 
> (Too bad they didn't the author didn't check the return value of fscanf=
...
> That would have caught this bug.)
> 
> The quick fix would be to call fgetc twice -- one to suck up the
> always-present space, and then a second time to implement the current
> check. I don't know, however, if this would work with other kernel
> versions.
> 
> A better solution might be found by consulting pmap.c in procps.
> 
> This bug is present in both libgtop 1.0.13-8, and libgtop2 2.6.0-4.
> (Including the diffs.)
> 
> 
> 

-- 
Loïc Minier <lool@dooz.org>
"Neutral President: I have no strong feelings one way or the other."