[PATCH] libbb: Close up a potential DIR leak
Denys Vlasenko
vda.linux at googlemail.com
Wed Dec 29 00:05:10 UTC 2010
On Tuesday 28 December 2010 10:37, Lauri Kasanen wrote:
> > On Monday 27 December 2010 10:02, Lauri Kasanen wrote:
> > > Hi
> > >
> > > find_block_device_in_dir has a potential DIR leak.
> >
> > len = strlen(ap->devpath);
> > rem = DEVNAME_MAX-2 - len;
> > - if (rem <= 0)
> > + if (rem <= 0) {
> > + closedir(dir);
> > return NULL;
> > + }
> >
> > It can be achieved simply by moving this code block up
> > before opendir.
> >
> > Fixed in git.
>
> That's true, but it would cause worse performance IMHO. Isn't the check for being a proper dir more lightweight than the strlen one?
> Now there's a strlen done for every file, and then there's the dir check; before it was strlen only for the directories.
opendir() is way more expensive than strlen(), so it'll dwarf strlen overhead
in most cases anyway, ... but see this:
while ((entry = readdir(dir)) != NULL) {
safe_strncpy(ap->devpath + len, entry->d_name, rem);
/* lstat: do not follow links */
if (lstat(ap->devpath, &ap->st) != 0)
continue;
if (S_ISBLK(ap->st.st_mode) && ap->st.st_rdev == ap->dev) {
retpath = xstrdup(ap->devpath);
break;
}
if (S_ISDIR(ap->st.st_mode)) { <======================
/* Do not recurse for '.' and '..' */
if (DOT_OR_DOTDOT(entry->d_name))
continue;
retpath = find_block_device_in_dir(ap); <======
if (retpath)
break;
}
we call find_block_device_in_dir() resursively *on directories only*,
so opendir inside wasn't (usually, sans fs errors) returning NULL,
and we were falling into strlen anyway => swapping them doesn't
increase number of strlen calls.
--
vda
More information about the busybox
mailing list