1. 04 Aug, 2023 2 commits
    • Ian Kent's avatar
      autofs: use wake_up() instead of wake_up_interruptible(() · 17fce12e
      Ian Kent authored
      In autofs_wait_release() wake_up() is used to wake up processes waiting
      on a mount callback to complete which matches the wait_event_killable()
      in autofs_wait().
      
      But in autofs_catatonic_mode() the wake_up_interruptible() was not also
      changed at the time autofs_wait_release() was changed.
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Message-Id: <169112719813.7590.4971499386839952992.stgit@donald.themaw.net>
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      17fce12e
    • Fedor Pchelkin's avatar
      autofs: fix memory leak of waitqueues in autofs_catatonic_mode · ccbe77f7
      Fedor Pchelkin authored
      Syzkaller reports a memory leak:
      
      BUG: memory leak
      unreferenced object 0xffff88810b279e00 (size 96):
        comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff  ..........'.....
          08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00  ..'.............
        backtrace:
          [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
          [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
          [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
          [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
          [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
          [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
          [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
          [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
          [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
          [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline]
          [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856
          [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
          [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      autofs_wait_queue structs should be freed if their wait_ctr becomes zero.
      Otherwise they will be lost.
      
      In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new
      waitqueue struct is allocated in autofs_wait(), its initial wait_ctr
      equals 2. After that wait_event_killable() is interrupted (it returns
      -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not
      satisfied. Actually, this condition can be satisfied when
      autofs_wait_release() or autofs_catatonic_mode() is called and, what is
      also important, wait_ctr is decremented in those places. Upon the exit of
      autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process
      begins: kill_sb calls autofs_catatonic_mode(), which should have freed the
      waitqueues, but it only decrements its usage counter to zero which is not
      a correct behaviour.
      
      edit:imk
      This description is of course not correct. The umount performed as a result
      of an expire is a umount of a mount that has been automounted, it's not the
      autofs mount itself. They happen independently, usually after everything
      mounted within the autofs file system has been expired away. If everything
      hasn't been expired away the automount daemon can still exit leaving mounts
      in place. But expires done in both cases will result in a notification that
      calls autofs_wait_release() with a result status. The problem case is the
      summary execution of of the automount daemon. In this case any waiting
      processes won't be woken up until either they are terminated or the mount
      is umounted.
      end edit: imk
      
      So in catatonic mode we should free waitqueues which counter becomes zero.
      
      edit: imk
      Initially I was concerned that the calling of autofs_wait_release() and
      autofs_catatonic_mode() was not mutually exclusive but that can't be the
      case (obviously) because the queue entry (or entries) is removed from the
      list when either of these two functions are called. Consequently the wait
      entry will be freed by only one of these functions or by the woken process
      in autofs_wait() depending on the order of the calls.
      end edit: imk
      
      Reported-by: syzbot+5e53f70e69ff0c0a1c0c@syzkaller.appspotmail.com
      Suggested-by: default avatarTakeshi Misawa <jeliantsurux@gmail.com>
      Signed-off-by: default avatarFedor Pchelkin <pchelkin@ispras.ru>
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Andrei Vagin <avagin@gmail.com>
      Cc: autofs@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Message-Id: <169112719161.7590.6700123246297365841.stgit@donald.themaw.net>
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      ccbe77f7
  2. 09 Jul, 2023 10 commits
  3. 08 Jul, 2023 28 commits