1. 29 Feb, 2012 1 commit
  2. 04 Jan, 2012 1 commit
  3. 07 Dec, 2011 1 commit
    • Al Viro's avatar
      fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API · 02125a82
      Al Viro authored
      __d_path() API is asking for trouble and in case of apparmor d_namespace_path()
      getting just that.  The root cause is that when __d_path() misses the root
      it had been told to look for, it stores the location of the most remote ancestor
      in *root.  Without grabbing references.  Sure, at the moment of call it had
      been pinned down by what we have in *path.  And if we raced with umount -l, we
      could have very well stopped at vfsmount/dentry that got freed as soon as
      prepend_path() dropped vfsmount_lock.
      
      It is safe to compare these pointers with pre-existing (and known to be still
      alive) vfsmount and dentry, as long as all we are asking is "is it the same
      address?".  Dereferencing is not safe and apparmor ended up stepping into
      that.  d_namespace_path() really wants to examine the place where we stopped,
      even if it's not connected to our namespace.  As the result, it looked
      at ->d_sb->s_magic of a dentry that might've been already freed by that point.
      All other callers had been careful enough to avoid that, but it's really
      a bad interface - it invites that kind of trouble.
      
      The fix is fairly straightforward, even though it's bigger than I'd like:
      	* prepend_path() root argument becomes const.
      	* __d_path() is never called with NULL/NULL root.  It was a kludge
      to start with.  Instead, we have an explicit function - d_absolute_root().
      Same as __d_path(), except that it doesn't get root passed and stops where
      it stops.  apparmor and tomoyo are using it.
      	* __d_path() returns NULL on path outside of root.  The main
      caller is show_mountinfo() and that's precisely what we pass root for - to
      skip those outside chroot jail.  Those who don't want that can (and do)
      use d_path().
      	* __d_path() root argument becomes const.  Everyone agrees, I hope.
      	* apparmor does *NOT* try to use __d_path() or any of its variants
      when it sees that path->mnt is an internal vfsmount.  In that case it's
      definitely not mounted anywhere and dentry_path() is exactly what we want
      there.  Handling of sysctl()-triggered weirdness is moved to that place.
      	* if apparmor is asked to do pathname relative to chroot jail
      and __d_path() tells it we it's not in that jail, the sucker just calls
      d_absolute_path() instead.  That's the other remaining caller of __d_path(),
      BTW.
              * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
      the normal seq_file logics will take care of growing the buffer and redoing
      the call of ->show() just fine).  However, if it gets path not reachable
      from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
      ignoring the return value as it used to do).
      Reviewed-by: default avatarJohn Johansen <john.johansen@canonical.com>
      ACKed-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org
      02125a82
  4. 26 Oct, 2010 1 commit
  5. 23 Sep, 2010 1 commit
  6. 07 Mar, 2010 1 commit
  7. 22 Feb, 2010 1 commit
  8. 10 Feb, 2010 1 commit
  9. 24 Sep, 2009 2 commits
  10. 18 Jun, 2009 1 commit
  11. 30 Mar, 2009 1 commit
  12. 18 Feb, 2009 1 commit
    • Eric Biederman's avatar
      seq_file: properly cope with pread · 8f19d472
      Eric Biederman authored
      Currently seq_read assumes that the offset passed to it is always the
      offset it passed to user space.  In the case pread this assumption is
      broken and we do the wrong thing when presented with pread.
      
      To solve this I introduce an offset cache inside of struct seq_file so we
      know where our logical file position is.  Then in seq_read if we try to
      read from another offset we reset our data structures and attempt to go to
      the offset user space wanted.
      
      [akpm@linux-foundation.org: restore FMODE_PWRITE]
      [pjt@google.com: seq_open needs its fmode opened up to take advantage of this]
      Signed-off-by: default avatarEric Biederman <ebiederm@xmission.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Turner <pjt@google.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f19d472
  13. 05 Feb, 2009 2 commits
  14. 31 Dec, 2008 1 commit
  15. 29 Dec, 2008 1 commit
  16. 28 Nov, 2008 1 commit
  17. 23 Nov, 2008 2 commits
  18. 20 Oct, 2008 2 commits
  19. 25 Aug, 2008 1 commit
  20. 12 Aug, 2008 1 commit
  21. 23 Apr, 2008 2 commits
  22. 22 Apr, 2008 2 commits
  23. 15 Feb, 2008 2 commits
  24. 10 Oct, 2007 1 commit
  25. 16 Jul, 2007 2 commits
    • Alexey Dobriyan's avatar
      seq_file: more atomicity in traverse() · cb510b81
      Alexey Dobriyan authored
      Original problem: in some circumstances seq_file interface can present
      infinite proc file to the following script when normally said proc file is
      finite:
      
      	while read line; do
      		[do something with $line]
      	done </proc/$FILE
      
      bash, to implement such loop does essentially
      
      	read(0, buf, 128);
      	[find \n]
      	lseek(0, -difference, SEEK_CUR);
      
      Consider, proc file prints list of objects each of them consists of many
      lines, each line is shorter than 128 bytes.
      
      Two objects in list, with ->index'es being 0 and 1.  Current one is 1, as
      bash prints second object line by line.
      
      Imagine first object being removed right before lseek().
      traverse() will be called, because there is negative offset.
      traverse() will reset ->index to 0 (!).
      traverse() will call ->next() and get NULL in any usual iterate-over-list
      code using list_for_each_entry_continue() and such. There is one object in
      list now after all...
      traverse() will return 0, lseek() will update file position and pretend
      everything is OK.
      
      So, what we have now: ->f_pos points to place where second object will be
      printed, but ->index is 0.  seq_read() instead of returning EOF, will start
      printing first line of first object every time it's called, until enough
      objects are added to ->f_pos return in bounds.
      
      Fix is to update ->index only after we're sure we saw enough objects down
      the road.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@sw.ru>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cb510b81
    • Alexey Dobriyan's avatar
      mutex_unlock() later in seq_lseek() · 00c5746d
      Alexey Dobriyan authored
      All manipulations with struct seq_file::version are done under
      struct seq_file::lock except one introduced in commit
      d6b7a781c51c91dd054e5c437885205592faac21
      aka "[PATCH] Speed up /proc/pid/maps"
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@sw.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00c5746d
  26. 11 Jul, 2007 1 commit
    • Pavel Emelianov's avatar
      Make common helpers for seq_files that work with list_heads · bcf67e16
      Pavel Emelianov authored
      Many places in kernel use seq_file API to iterate over a regular list_head.
      The code for such iteration is identical in all the places, so it's worth
      introducing a common helpers.
      
      This makes code about 300 lines smaller:
      
      The first version of this patch made the helper functions static inline
      in the seq_file.h header. This patch moves them to the fs/seq_file.c as
      Andrew proposed. The vmlinux .text section sizes are as follows:
      
      2.6.22-rc1-mm1:              0x001794d5
      with the previous version:   0x00179505
      with this patch:             0x00179135
      
      The config file used was make allnoconfig with the "y" inclusion of all
      the possible options to make the files modified by the patch compile plus
      drivers I have on the test node.
      
      This patch:
      
      Many places in kernel use seq_file API to iterate over a regular list_head.
      The code for such iteration is identical in all the places, so it's worth
      introducing a common helpers.
      Signed-off-by: default avatarPavel Emelianov <xemul@openvz.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bcf67e16
  27. 08 Dec, 2006 1 commit
  28. 07 Dec, 2006 1 commit
  29. 23 Mar, 2006 1 commit
  30. 08 Nov, 2005 1 commit
  31. 01 May, 2005 1 commit
  32. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4