sysfs_get_link doesn't handle directory symlinks (except as last arc)

Binary package hint: libsysfs2

Involved packages:
pmount 0.9.17-2
libsysfs2 2.1.0-4
linux-image-2.6.27-6-generic 2.6.27-6.9

I observed this problem while trying to use pmount. Relevant lines only:
$ pmount /dev/sdb1
Error: device /dev/sdb1 is not removable
$ pmount --debug /dev/sdb1
device_removable: could not find a sysfs device for /dev/sdb1
$ sudo ltrace -s 1024 pmount /dev/sdb1
sysfs_get_link("/sys/block/sdb/device", "/2:0:0:0", 1024) = 0
sysfs_open_device_path("/2:0:0:0") = 0
$ readlink /sys/block/sdb/device
../../../2:0:0:0
$ readlink /sys/block/sdb
../devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
$ ( cd /sys/block/sdb/device; pwd -P; )
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0

So the symlink does point to a valid device directory when all symlinks in the path are considered or, alternatively, when .. is treated like any subdirectroy and not canceled with the preceding arc. The sysfs_get_link function, however, cancels arcs without checking for symlinks. This leads to an incorrect absolute path, and thus causes pmount to fail.

I'm not perfectly sure whether sysfs_get_link is intended to deal with such issues. Looking at libsysfs.txt shipped with the sysfsutils sources I would guess so, though. And as sysfsutils is a probably security relevant piece of code, I'd rather play it safe, and have the library perform some extra checks instead of relying on applications to take care of such details. On the other hand, if this issue were to take longer to get fixed, pmount could probably work around it by simply not calling sysfs_get_link at all, but instead have the OS deal with symlinks.

Looking at the code of sysfs_get_link from sysfs_utils.c, it looks like this issue might cause more severe problems. This is the part where the path stripping actually happens, having detected the link path (d) to start with "..":

  while (*d == '/' || *d == '.') {
        if (*d == '/')
        slashes++;
        d++;
  }
  d--;
  s = &devdir[strlen(devdir)-1];
  while (s != NULL && count != (slashes+1)) {
        s--;
        if (*s == '/')
              count++;
  }
  safestrcpymax(s, d, (SYSFS_PATH_MAX-strlen(devdir)));

As you can see, the code moves backwards in the directory path. However, the beginning of string comparison seems to me completely bogus. So when there aren't enough slashes, this code will iterate before the beginning of the string. I guess it should be something like "s != devdir" instead of "s != NULL".

The assumption that there will be only arcs of the form ".." involved, no "." or "...." isn't completely justified either, although it should for the most part hold in sysfs.

I guess one could also modify this loop to replace every '/' by '\0' and check the thus truncated path recursively. I'm not perfectly sure whether one would have to take special care in order to prevent infinite loops; on sane file systems I wouldn't think so.

ProblemType: Bug
Architecture: i386
Dependencies:
 libgcc1 1:4.3.2-1ubuntu9
 gcc-4.3-base 4.3.2-1ubuntu9
 findutils 4.4.0-2ubuntu3
 libc6 2.8~20080505-0ubuntu7
DistroRelease: Ubuntu 8.10
Package: libsysfs2 2.1.0-4
ProcEnviron:
 LC_CTYPE=de_DE.utf8
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.utf8
 LC_MESSAGES=C
 SHELL=/bin/bash
SourcePackage: sysfsutils
Uname: Linux 2.6.27-6-generic i686