]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
8168 NULL pointer dereference in zfs_create()
authoravg <avg@FreeBSD.org>
Fri, 9 Jun 2017 15:00:13 +0000 (15:00 +0000)
committeravg <avg@FreeBSD.org>
Fri, 9 Jun 2017 15:00:13 +0000 (15:00 +0000)
commit54d0cf08b158f0b604d631478d7b4d68b1d68a4f
treeb59ad6762a5247fa2abd589b52aa73be60eb3d1b
parent0d267de6593213737fd6b987d5d4ebc6e29fd44b
8168 NULL pointer dereference in zfs_create()

illumos/illumos-gate@690031d326342fa4ea28b5e80f1ad6a16281519d
https://github.com/illumos/illumos-gate/commit/690031d326342fa4ea28b5e80f1ad6a16281519d

https://www.illumos.org/issues/8168
  If we manage to export the pool on which we are creating a dataset (filesystem
  or zvol) between entering libzfs`zfs_create() and libzfs`zpool_open() call (for
  which we never check the return value) we end up dereferencing a NULL pointer
  in libzfs`zpool_close().
  This was discovered on ZFS on Linux. The same issue can be reproduced on
  Illumos running in parallel:
    while :; do zpool import -d /tmp testpool ; zpool export testpool ; done
    while :; do zfs create testpool/fs; zfs destroy testpool/fs ; done
  Eventually this will result in several core dumps like this one:
  [root@52-54-00-d3-7a-01 /cores]# mdb core.zfs.4244
  Loading modules: [ libumem.so.1 libc.so.1 libtopo.so.1 libavl.so.1
  libnvpair.so.1 ld.so.1 ]
  > ::stack
  libzfs.so.1`zpool_close+0x17(0, 0, 0, 8047450)
  libzfs.so.1`zfs_create+0x1bb(80905488047e6f, 1, 808cba8)
  zfs_do_create+0x545(2, 8047d7480778a0, 801, 0, 3)
  main+0x22c(8047d2cfef5c6e88047d648055a17, 3, 8047d70)
  _start+0x83(3, 8047e648047e688047e6f, 0, 8047e7b)
  >
  Fix and reproducer (systemtap): https://github.com/zfsonlinux/zfs/pull/6096

Reviewed by: Matt Ahrens <mahrens@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: loli10K <ezomori.nozomu@gmail.com>
lib/libzfs/common/libzfs_dataset.c