What is the version of your mount.cifs file ("/sbin/mount.cifs -V")?

Does the user or password contain a comma (',') ?

Created attachment 1891 [details]
mount.cifs with debug printf inserted

I hate to debug this the boring, old fashioned way but is seems easiest since I did not spot the problem yet the other ways.  I have created a mount.cifs.c with additional print statements before the five or six frees.  Although this is a harmless error (free of an already exiting process) I would like to fix this.

You can "gcc mount.cifs.c -o mount.cifs"  and run ./mount.cifs directly out of that directory or move it into sbin (saving your existing mount.cifs first of course) so it can be executed by "mount -t cifs" without having to run "mount.cifs //server/share /mnt" directly

If you add MALLOC_CHECK_=2 to the environment, it'll probably abort() as root as well.

I experienced a similiar problem with the mount.cifs shipped with ubuntu (not sure if it's breezy badger), my version of mount.cifs says 1.6, installed version of samba is 3.0.14a. A closer inspection of trunk, with mount.cifs v. 1.10 seems to have the same problem.

Ran this trough gdb and got it to crash around line 960-something of mount.cifs.c

if(mount_user) {
  if(getuid() != 0) {
    strcat(mountent.mnt_opts,",user=");
    strcat(mountent.mnt_opts,mount_user);
  }
  free(mount_user); // Here bad malloc-mojo occurs, and with MALLOC_CHECK_=2
                    // will abort().
}

Backtracking a bit, mount_user is a char * pointer returned by the function getusername (which exists in mount.cifs.c).

The comment to this function is "caller frees username if necessary", which is sort of misleading, as it should never need to be freed (if I've understood getpwnam correctly).

getusername calls getpwuid, and the returned pointer is from the struct resulting from a successful call of getpwuid. Here the fun starts, the posix-standard says that it may be stored in a static area which may be overwritten by further calls to getpwuid, which sort of leads me to believe that the programmer shouldn't worry about freeing what it returns. The man-pages for getpwnam seems to be vague enough to interpret it both for and against freeing. Somebody with better UNIX-fu than me might know the definitive answear.

This was the most authorative-looking I found on getpwuid:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html

If your libc supports it, a temporary fix is to make sure MALLOC_CHECK_=0 is set in the environment when mount.cifs get run (altough I think some systems ignores this for suid-root  executables).

Cheers!
Kjetil Jørgensen <kjetijor@pvv.ntnu.no>

Created attachment 1956 [details]
Replace comment for getusername with something that's correct, and removal of the offending call to free.

Uploaded a patch with two minor changes to mount.cifs.c, fixing the comment for getusername and removed the offending call to free. It fixes mount.cifs aborting on my systems at least. :)

After testing some more, it seems it's more hard to reproduce than I first thought. That is, MALLOC_CHECK_ is not going to help reproduce it in all cases :(

I do however still stand by that calling free on something returned by getpwuid/getpwnam is wrong.

-- 
Kjetil Jørgensen

The fix in the attachment in comment #5 is in mount.cifs.c.
I do not see anymore of such issues, free() of the user names returned by
getpwuid and getpwnam system calls.
Ran mount.cifs with MALLOC_CHECK_=2 many times without encountering any
aborts and error stack.

I think this issue is fixed and this bug can be closed.

fixed, as Shirish notes