1. 02 Aug, 2018 1 commit
  2. 29 Jul, 2018 1 commit
  3. 21 Jul, 2018 2 commits
  4. 07 Jul, 2018 1 commit
    • Rajat Jain's avatar
      sysfs: Fix internal_create_group() for named group updates · c855cf27
      Rajat Jain authored
      There are a couple of problems with named group updates in the code
      * sysfs_update_group() will always fail for a named group, because
        internal_create_group() will try to create a new sysfs directory
        unconditionally, which will ofcourse fail with -EEXIST.
      * We can leak the kernfs_node for grp->name if some one tries to:
        - rename a group (change grp->name), or
        - update a named group, to an unnamed group
      It appears that the whole purpose of sysfs_update_group() was to
      allow changing the permissions or visibility of attributes and not
      the names. So make it clear in the comments, and allow it to update
      an existing named group.
      Signed-off-by: default avatarRajat Jain <rajatja@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 21 May, 2018 1 commit
    • Al Viro's avatar
      unfuck sysfs_mount() · 7b745a4e
      Al Viro authored
      new_sb is left uninitialized in case of early failures in kernfs_mount_ns(),
      and while IS_ERR(root) is true in all such cases, using IS_ERR(root) || !new_sb
      is not a solution - IS_ERR(root) is true in some cases when new_sb is true.
      Make sure new_sb is initialized (and matches the reality) in all cases and
      fix the condition for dropping kobj reference - we want it done precisely
      in those situations where the reference has not been transferred into a new
      super_block instance.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  6. 20 Mar, 2018 1 commit
  7. 23 Jan, 2018 2 commits
  8. 22 Jan, 2018 1 commit
    • Greg Kroah-Hartman's avatar
      sysfs: turn WARN() into pr_warn() · 5d54f948
      Greg Kroah-Hartman authored
      It's not good to crash the machine if panic_on_warn() is set just
      because someone made a stupid mistake of trying to create a sysfs file
      with the same name of an existing one.  This makes the automated testing
      tools a lot harder to find the real bugs in the kernel.
      So just print a warning out and dump the stack to get the attention of
      the developer that they did something foolish.  Then keep on trucking,
      as this should not be a fatal error at all.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 05 Jan, 2018 1 commit
    • Sergey Senozhatsky's avatar
      sysfs: do not use print_symbol() · 9e6d35ff
      Sergey Senozhatsky authored
      print_symbol() is a very old API that has been obsoleted by %pS format
      specifier in a normal printk() call.
      Replace print_symbol() with a direct printk("%pS") call.
      Link: http://lkml.kernel.org/r/20171211125025.2270-11-sergey.senozhatsky@gmail.com
      To: Andrew Morton <akpm@linux-foundation.org>
      To: Russell King <linux@armlinux.org.uk>
      To: Catalin Marinas <catalin.marinas@arm.com>
      To: Mark Salter <msalter@redhat.com>
      To: Tony Luck <tony.luck@intel.com>
      To: David Howells <dhowells@redhat.com>
      To: Yoshinori Sato <ysato@users.sourceforge.jp>
      To: Guan Xuetao <gxt@mprc.pku.edu.cn>
      To: Borislav Petkov <bp@alien8.de>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      To: Thomas Gleixner <tglx@linutronix.de>
      To: Peter Zijlstra <peterz@infradead.org>
      To: Vineet Gupta <vgupta@synopsys.com>
      To: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-sh@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: x86@kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: sergey-senozhatsky's avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      [pmladek@suse.com: updated commit message]
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
  10. 18 Dec, 2017 1 commit
  11. 27 Nov, 2017 1 commit
    • Linus Torvalds's avatar
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds authored
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      The script to do this was:
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
                ACTIVE NOUSER"
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  12. 08 Apr, 2017 1 commit
    • NeilBrown's avatar
      sysfs: be careful of error returns from ops->show() · c8a139d0
      NeilBrown authored
      ops->show() can return a negative error code.
      Commit 65da3484 ("sysfs: correctly handle short reads on PREALLOC attrs.")
      (in v4.4) caused this to be stored in an unsigned 'size_t' variable, so errors
      would look like large numbers.
      As a result, if an error is returned, sysfs_kf_read() will return the
      value of 'count', typically 4096.
      Commit 17d0774f ("sysfs: correctly handle read offset on PREALLOC attrs")
      (in v4.8) extended this error to use the unsigned large 'len' as a size for
      Consequently, if ->show returns an error, then the first read() on the
      sysfs file will return 4096 and could return uninitialized memory to
      If the application performs a subsequent read, this will trigger a memmove()
      with extremely large count, and is likely to crash the machine is bizarre ways.
      This bug can currently only be triggered by reading from an md
      sysfs attribute declared with __ATTR_PREALLOC() during the
      brief period between when mddev_put() deletes an mddev from
      the ->all_mddevs list, and when mddev_delayed_delete() - which is
      scheduled on a workqueue - completes.
      Before this, an error won't be returned by the ->show()
      After this, the ->show() won't be called.
      I can reproduce it reliably only by putting delay like
      early in mddev_delayed_delete(). Then after creating an
      md device md0 run
        echo clear > /sys/block/md0/md/array_state; cat /sys/block/md0/md/array_state
      The bug can be triggered without the usleep.
      Fixes: 65da3484 ("sysfs: correctly handle short reads on PREALLOC attrs.")
      Fixes: 17d0774f ("sysfs: correctly handle read offset on PREALLOC attrs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. 27 Sep, 2016 1 commit
  14. 31 Aug, 2016 1 commit
  15. 10 Aug, 2016 1 commit
    • Tejun Heo's avatar
      kernfs: make kernfs_path*() behave in the style of strlcpy() · 3abb1d90
      Tejun Heo authored
      kernfs_path*() functions always return the length of the full path but
      the path content is undefined if the length is larger than the
      provided buffer.  This makes its behavior different from strlcpy() and
      requires error handling in all its users even when they don't care
      about truncation.  In addition, the implementation can actully be
      simplified by making it behave properly in strlcpy() style.
      * Update kernfs_path_from_node_locked() to always fill up the buffer
        with path.  If the buffer is not large enough, the output is
        truncated and terminated.
      * kernfs_path() no longer needs error handling.  Make it a simple
        inline wrapper around kernfs_path_from_node().
      * sysfs_warn_dup()'s use of kernfs_path() doesn't need error handling.
        Updated accordingly.
      * cgroup_path()'s use of kernfs_path() updated to retain the old
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  16. 23 Jun, 2016 2 commits
    • Eric W. Biederman's avatar
      kernfs: The cgroup filesystem also benefits from SB_I_NOEXEC · 29a517c2
      Eric W. Biederman authored
      The cgroup filesystem is in the same boat as sysfs.  No one ever
      permits executables of any kind on the cgroup filesystem, and there is
      no reasonable future case to support executables in the future.
      Therefore move the setting of SB_I_NOEXEC which makes the code proof
      against future mistakes of accidentally creating executables from
      sysfs to kernfs itself.  Making the code simpler and covering the
      sysfs, cgroup, and cgroup2 filesystems.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    • Eric W. Biederman's avatar
      mnt: Refactor fs_fully_visible into mount_too_revealing · 8654df4e
      Eric W. Biederman authored
      Replace the call of fs_fully_visible in do_new_mount from before the
      new superblock is allocated with a call of mount_too_revealing after
      the superblock is allocated.   This winds up being a much better location
      for maintainability of the code.
      The first change this enables is the replacement of FS_USERNS_VISIBLE
      with SB_I_USERNS_VISIBLE.  Moving the flag from struct filesystem_type
      to sb_iflags on the superblock.
      Unfortunately mount_too_revealing fundamentally needs to touch
      mnt_flags adding several MNT_LOCKED_XXX flags at the appropriate
      times.  If the mnt_flags did not need to be touched the code
      could be easily moved into the filesystem specific mount code.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  17. 18 Oct, 2015 1 commit
  18. 07 Oct, 2015 1 commit
  19. 04 Oct, 2015 1 commit
  20. 10 Jul, 2015 1 commit
    • Eric W. Biederman's avatar
      vfs: Commit to never having exectuables on proc and sysfs. · 90f8572b
      Eric W. Biederman authored
      Today proc and sysfs do not contain any executable files.  Several
      applications today mount proc or sysfs without noexec and nosuid and
      then depend on there being no exectuables files on proc or sysfs.
      Having any executable files show on proc or sysfs would cause
      a user space visible regression, and most likely security problems.
      Therefore commit to never allowing executables on proc and sysfs by
      adding a new flag to mark them as filesystems without executables and
      enforce that flag.
      Test the flag where MNT_NOEXEC is tested today, so that the only user
      visible effect will be that exectuables will be treated as if the
      execute bit is cleared.
      The filesystems proc and sysfs do not currently incoporate any
      executable files so this does not result in any user visible effects.
      This makes it unnecessary to vet changes to proc and sysfs tightly for
      adding exectuable files or changes to chattr that would modify
      existing files, as no matter what the individual file say they will
      not be treated as exectuable files by the vfs.
      Not having to vet changes to closely is important as without this we
      are only one proc_create call (or another goof up in the
      implementation of notify_change) from having problematic executables
      on proc.  Those mistakes are all too easy to make and would create
      a situation where there are security issues or the assumptions of
      some program having to be broken (and cause userspace regressions).
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  21. 01 Jul, 2015 1 commit
  22. 01 Jun, 2015 1 commit
  23. 24 May, 2015 1 commit
  24. 14 May, 2015 1 commit
    • Eric W. Biederman's avatar
      mnt: Refactor the logic for mounting sysfs and proc in a user namespace · 1b852bce
      Eric W. Biederman authored
      Fresh mounts of proc and sysfs are a very special case that works very
      much like a bind mount.  Unfortunately the current structure can not
      preserve the MNT_LOCK... mount flags.  Therefore refactor the logic
      into a form that can be modified to preserve those lock bits.
      Add a new filesystem flag FS_USERNS_VISIBLE that requires some mount
      of the filesystem be fully visible in the current mount namespace,
      before the filesystem may be mounted.
      Move the logic for calling fs_fully_visible from proc and sysfs into
      fs/namespace.c where it has greater access to mount namespace state.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  25. 25 Mar, 2015 2 commits
  26. 14 Feb, 2015 1 commit
    • Tejun Heo's avatar
      kernfs: remove KERNFS_STATIC_NAME · dfeb0750
      Tejun Heo authored
      When a new kernfs node is created, KERNFS_STATIC_NAME is used to avoid
      making a separate copy of its name.  It's currently only used for sysfs
      attributes whose filenames are required to stay accessible and unchanged.
      There are rare exceptions where these names are allocated and formatted
      dynamically but for the vast majority of cases they're consts in the
      rodata section.
      Now that kernfs is converted to use kstrdup_const() and kfree_const(),
      there's little point in keeping KERNFS_STATIC_NAME around.  Remove it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  27. 03 Feb, 2015 1 commit
  28. 07 Nov, 2014 3 commits
    • NeilBrown's avatar
      sysfs/kernfs: make read requests on pre-alloc files use the buffer. · 4ef67a8c
      NeilBrown authored
      To match the previous patch which used the pre-alloc buffer for
      writes, this patch causes reads to use the same buffer.
      This is not strictly necessary as the current seq_read() will allocate
      on first read, so user-space can trigger the required pre-alloc.  But
      consistency is valuable.
      The read function is somewhat simpler than seq_read() and, for example,
      does not support reading from an offset into the file: reads must be
      at the start of the file.
      As seq_read() does not use the prealloc buffer, ->seq_show is
      incompatible with ->prealloc and caused an EINVAL return from open().
      sysfs code which calls into kernfs always chooses the correct function.
      As the buffer is shared with writes and other reads, the mutex is
      extended to cover the copy_to_user.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reviewed-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      sysfs/kernfs: allow attributes to request write buffer be pre-allocated. · 2b75869b
      NeilBrown authored
      md/raid allows metadata management to be performed in user-space.
      A various times, particularly on device failure, the metadata needs
      to be updated before further writes can be permitted.
      This means that the user-space program which updates metadata much
      not block on writeout, and so must not allocate memory.
      mlockall(MCL_CURRENT|MCL_FUTURE) and pre-allocation can avoid all
      memory allocation issues for user-memory, but that does not help
      kernel memory.
      Several kernel objects can be pre-allocated.  e.g. files opened before
      any writes to the array are permitted.
      However some kernel allocation happens in places that cannot be
      In particular, writes to sysfs files (to tell md that it can now
      allow writes to the array) allocate a buffer using GFP_KERNEL.
      This patch allows attributes to be marked as "PREALLOC".  In that case
      the maximal buffer is allocated when the file is opened, and then used
      on each write instead of allocating a new buffer.
      As the same buffer is now shared for all writes on the same file
      description, the mutex is extended to cover full use of the buffer
      including the copy_from_user().
      The new __ATTR_PREALLOC() 'or's a new flag in to the 'mode', which is
      inspected by sysfs_add_file_mode_ns() to determine if the file should be
      marked as requiring prealloc.
      Despite the comment, we *do* use ->seq_show together with ->prealloc
      in this patch.  The next patch fixes that.
      Signed-off-by: default avatarNeilBrown  <neilb@suse.de>
      Reviewed-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vladimir Zapolskiy's avatar
      fs: sysfs: return EGBIG on write if offset is larger than file size · 09368960
      Vladimir Zapolskiy authored
      According to the user expectations common utilities like dd or sh
      redirection operator > should work correctly over binary files from
      sysfs. At the moment doing excessive write can not be completed:
        write(1, "\0\0\0\0\0\0\0\0", 8)         = 4
        write(1, "\0\0\0\0", 4)                 = 0
        write(1, "\0\0\0\0", 4)                 = 0
        write(1, "\0\0\0\0", 4)                 = 0
      Fix the problem by returning EFBIG described in man 2 write.
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  29. 03 Jun, 2014 1 commit
  30. 27 May, 2014 2 commits
  31. 20 May, 2014 1 commit
    • Tejun Heo's avatar
      sysfs: make sure read buffer is zeroed · f5c16f29
      Tejun Heo authored
      13c589d5 ("sysfs: use seq_file when reading regular files")
      switched sysfs from custom read implementation to seq_file to enable
      later transition to kernfs.  After the change, the buffer passed to
      ->show() is acquired through seq_get_buf(); unfortunately, this
      introduces a subtle behavior change.  Before the commit, the buffer
      passed to ->show() was always zero as it was allocated using
      get_zeroed_page().  Because seq_file doesn't clear buffers on
      allocation and neither does seq_get_buf(), after the commit, depending
      on the behavior of ->show(), we may end up exposing uninitialized data
      to userland thus possibly altering userland visible behavior and
      leaking information.
      Fix it by explicitly clearing the buffer.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarRon <ron@debian.org>
      Fixes: 13c589d5 ("sysfs: use seq_file when reading regular files")
      Cc: stable <stable@vger.kernel.org> # 3.13+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  32. 13 May, 2014 1 commit
    • Tejun Heo's avatar
      kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs · 555724a8
      Tejun Heo authored
      The kernfs open method - kernfs_fop_open() - inherited extra
      permission checks from sysfs.  While the vfs layer allows ignoring the
      read/write permissions checks if the issuer has CAP_DAC_OVERRIDE,
      sysfs explicitly denied open regardless of the cap if the file doesn't
      have any of the UGO perms of the requested access or doesn't implement
      the requested operation.  It can be debated whether this was a good
      idea or not but the behavior is too subtle and dangerous to change at
      this point.
      After cgroup got converted to kernfs, this extra perm check also got
      applied to cgroup breaking libcgroup which opens write-only files with
      O_RDWR as root.  This patch gates the extra open permission check with
      a new flag KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK and enables it for sysfs.
      For sysfs, nothing changes.  For cgroup, root now can perform any
      operation regardless of the permissions as it was before kernfs
      conversion.  Note that kernfs still fails unimplemented operations
      with -EINVAL.
      While at it, add comments explaining KERNFS_ROOT flags.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarAndrey Wagin <avagin@gmail.com>
      Tested-by: default avatarAndrey Wagin <avagin@gmail.com>
      Cc: Li Zefan <lizefan@huawei.com>
      References: http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0U8upJ44+A@mail.gmail.com
      Fixes: 2bd59d48 ("cgroup: convert to kernfs")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  33. 16 Apr, 2014 1 commit