NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/48799: 32 bit ino_t bottleneck in interface of cd9660 to vfsops sabotages NFS



>Number:         48799
>Category:       kern
>Synopsis:       32 bit ino_t bottleneck in interface of cd9660 to vfsops 
>sabotages NFS
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 10 21:50:00 +0000 2014
>Originator:     Thomas Schmitt
>Release:        6.1.3
>Organization:
>Environment:
NetBSD netbsd 6.1.3 NetBSD 6.1.3 (GENERIC) i386
>Description:
During my assessment of the relation between struct iso_node and
ISO 9660 File Sections, i came to the definition of the cd9660
version of vsops struct fid.
struct ifid is declared in cd9660_vfsops.c with comment
"File handle to vnode":

  struct ifid {
        ushort  ifid_len;
        ushort  ifid_pad;
        int     ifid_ino;
        long    ifid_start;
  };

Function cd9660_vptofh() copies this struct over a struct fid
which is provided by the caller.
Before this copying ifid_ino gets filled with the lower 32 bit of
an ino_t value (ip is a struct iso_node, ip->i_number is ino_t):

        ifh.ifid_ino = ip->i_number;

The higher bits are thrown away, obviously.

Function cd9660_fhtovp() copies such bytes back from struct fid
into a local struct ifid and uses .ifid_ino with

        if ((error = VFS_VGET(mp, ifh.ifid_ino, &nvp)) != 0) {

VFS_VGET to my assessment is actually function cd9660_vget_internal().
It uses cd9660_ihashget() to look up a vnode.

man 9 vfsops mentions that VFS_FHTOVP is related to NFS.
Taylor R Campbell on tech-kern teached me how to get an NFS
server running.

The attempt to produce the problem shows a sufficiently
undesirable result.


>How-To-Repeat:
Test ISO is

    http://scdbackup.webframe.org/large.iso.bz2

4470 bytes, MD5 7d78dc3efaec8ea3f1801335329f410d.
It inflates to 4,329,897,984 bytes.

Do this only if the fix of kern/48787 is applied.
If not, you will not get rid of the /mnt/iso mount point until reboot !

If the ISO is submitted as /dev/cd0, do:

  mount_cd9660 /dev/cd0a /mnt/iso
  mount_nfs localhost:/mnt/iso /mnt/nfs

Situation afterwards:

  netbsd# mount
  ...
  /dev/cd0a on /mnt/iso type cd9660 (read-only, NFS exported, local)
  localhost:/mnt/iso on /mnt/nfs type nfs
  netbsd# ls -l /mnt/nfs
  -r-xr-xr-x  1 root  wheel  0 Jan  1  1970 /mnt/nfs

Other than with kern/48787, it is possible to umount /mnt/nfs.

After the fix, expect

  netbsd# ls -l /mnt/nfs
  total 4
  drwxr-xr-x  1 thomas  dbus  2048 May  6 15:30 my
  -rw-r--r--  1 thomas  dbus     6 May  6 15:34 small_file

>Fix:

Changing the type of .ifid_ino to ino_t fixes the problem.



Home | Main Index | Thread Index | Old Index