1. 28 1月, 2015 1 次提交
  2. 25 10月, 2013 1 次提交
  3. 29 6月, 2013 3 次提交
    • A
      [readdir] convert ubifs · 01122e06
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      01122e06
    • A
      UBIFS: fix a horrid bug · 605c912b
      Artem Bityutskiy 提交于
      Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
      mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
      in the middle of 'ubifs_readdir()'.
      
      This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
      it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
      but this may corrupt memory and lead to all kinds of problems like crashes an
      security holes.
      
      This patch fixes the problem by using the 'file->f_version' field, which
      '->llseek()' always unconditionally sets to zero. We set it to 1 in
      'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
      seek and it is time to clear the state saved in 'file->private_data'.
      
      I tested this patch by writing a user-space program which runds readdir and
      seek in parallell. I could easily crash the kernel without these patches, but
      could not crash it with these patches.
      
      Cc: stable@vger.kernel.org
      Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      605c912b
    • A
      UBIFS: prepare to fix a horrid bug · 33f1a63a
      Artem Bityutskiy 提交于
      Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
      mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
      in the middle of 'ubifs_readdir()'.
      
      First of all, this means that 'file->private_data' can be freed while
      'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
      This patch is only a preparation, and the fix will follow next.
      
      In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
      because 'file->f_pos' can be changed by '->llseek()' at any point. This may
      lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
      may correspond to incorrect file positions.
      
      So here we introduce a local variable 'pos', read 'file->f_pose' once at very
      the beginning, and then stick to 'pos'. The result of this is that when
      'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
      'ubifs_readdir()', the latter "wins".
      
      Cc: stable@vger.kernel.org
      Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      33f1a63a
  4. 23 2月, 2013 1 次提交
  5. 18 12月, 2012 1 次提交
  6. 31 8月, 2012 1 次提交
  7. 20 7月, 2012 1 次提交
  8. 14 7月, 2012 2 次提交
  9. 30 5月, 2012 1 次提交
  10. 17 5月, 2012 1 次提交
  11. 03 5月, 2012 1 次提交
  12. 29 2月, 2012 1 次提交
    • A
      UBIFS: do not use inc_link when i_nlink is zero · c43be108
      Artem Bityutskiy 提交于
      This patch changes the 'i_nlink' counter handling in 'ubifs_unlink()',
      'ubifs_rmdir()' and 'ubifs_rename()'. In these function  'i_nlink' may become 0,
      and if 'ubifs_jnl_update()' failed, we would use 'inc_nlink()' to restore
      the previous 'i_nlink' value, which is incorrect from the VFS point of view and
      would cause a 'WARN_ON()' (see 'inc_nlink() implementation).
      
      This patches saves the previous 'i_nlink' value in a local variable and uses it
      at the error path instead of calling 'inc_nlink()'. We do this only for the
      inodes where 'i_nlink' may potentially become zero.
      
      This change has been requested by Al Viro <viro@ZenIV.linux.org.uk>.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      c43be108
  13. 04 1月, 2012 4 次提交
  14. 04 7月, 2011 4 次提交
  15. 28 5月, 2011 1 次提交
  16. 26 5月, 2011 2 次提交
  17. 14 5月, 2011 1 次提交
  18. 15 3月, 2011 1 次提交
  19. 26 10月, 2010 1 次提交
  20. 22 5月, 2010 1 次提交
  21. 06 3月, 2010 1 次提交
  22. 19 5月, 2009 1 次提交
    • H
      UBIFS: return error if link and unlink race · 8b3884a8
      Hunter Adrian 提交于
      Consider a scenario when 'vfs_link(dirA/fileA)' and
      'vfs_unlink(dirA/fileA, dirB/fileB)' race. 'vfs_link()' does not
      lock 'dirA->i_mutex', so this is possible. Both of the functions
      lock 'fileA->i_mutex' though. Suppose 'vfs_unlink()' wins, and takes
      'fileA->i_mutex' mutex first. Suppose 'fileA->i_nlink' is 1. In this
      case 'ubifs_unlink()' will drop the last reference, and put 'inodeA'
      to the list of orphans. After this, 'vfs_link()' will link
      'dirB/fileB' to 'inodeA'. Thir is a problem because, for example,
      the subsequent 'vfs_unlink(dirB/fileB)' will add the same inode
      to the list of orphans.
      
      This problem was reported by J. R. Okajima <hooanon05@yahoo.co.jp>
      
      [Artem: add more comments, amended commit message]
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      8b3884a8
  23. 26 1月, 2009 1 次提交
  24. 18 1月, 2009 1 次提交
  25. 14 11月, 2008 1 次提交
  26. 06 11月, 2008 2 次提交
    • A
      UBIFS: fix compilation warnings · e84461ad
      Artem Bityutskiy 提交于
      We print 'ino_t' type using '%lu' printk() placeholder, but this
      results in many warnings when compiling for Alpha platform. Fix
      this by adding (unsingned long) casts.
      
      Fixes these warnings:
      
      fs/ubifs/journal.c:693: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/journal.c:1131: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/dir.c:163: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/tnc.c:2680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/tnc.c:2700: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/replay.c:1066: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'ino_t'
      fs/ubifs/orphan.c:108: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:135: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:142: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:154: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:159: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:451: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:539: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:612: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:843: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:856: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1438: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1443: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1475: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1495: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:1591: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1671: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1674: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1699: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1788: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1821: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1833: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1924: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1932: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1938: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1945: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1953: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1960: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1967: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1973: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1988: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1991: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:2009: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ino_t'
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e84461ad
    • H
      UBIFS: endian handling fixes and annotations · 0ecb9529
      Harvey Harrison 提交于
      Noticed by sparse:
      fs/ubifs/file.c:75:2: warning: restricted __le64 degrades to integer
      fs/ubifs/file.c:629:4: warning: restricted __le64 degrades to integer
      fs/ubifs/dir.c:431:3: warning: restricted __le64 degrades to integer
      
      This should be checked to ensure the ubifs_assert is working as
      intended, I've done the suggested annotation in this patch.
      
      fs/ubifs/sb.c:298:6: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:298:6:    expected int [signed] [assigned] tmp
      fs/ubifs/sb.c:298:6:    got restricted __le64 [usertype] <noident>
      fs/ubifs/sb.c:299:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:299:19:    expected restricted __le64 [usertype] atime_sec
      fs/ubifs/sb.c:299:19:    got int [signed] [assigned] tmp
      fs/ubifs/sb.c:300:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:300:19:    expected restricted __le64 [usertype] ctime_sec
      fs/ubifs/sb.c:300:19:    got int [signed] [assigned] tmp
      fs/ubifs/sb.c:301:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:301:19:    expected restricted __le64 [usertype] mtime_sec
      fs/ubifs/sb.c:301:19:    got int [signed] [assigned] tmp
      
      This looks like a bugfix as your tmp was a u32 so there was truncation in
      the atime, mtime, ctime value, probably not intentional, add a tmp_le64
      and use it here.
      
      fs/ubifs/key.h:348:9: warning: cast to restricted __le32
      fs/ubifs/key.h:348:9: warning: cast to restricted __le32
      fs/ubifs/key.h:419:9: warning: cast to restricted __le32
      
      Read from the annotated union member instead.
      
      fs/ubifs/recovery.c:175:13: warning: incorrect type in assignment (different base types)
      fs/ubifs/recovery.c:175:13:    expected unsigned int [unsigned] [usertype] save_flags
      fs/ubifs/recovery.c:175:13:    got restricted __le32 [usertype] flags
      fs/ubifs/recovery.c:186:13: warning: incorrect type in assignment (different base types)
      fs/ubifs/recovery.c:186:13:    expected restricted __le32 [usertype] flags
      fs/ubifs/recovery.c:186:13:    got unsigned int [unsigned] [usertype] save_flags
      
      Do byteshifting at compile time of the flag value.  Annotate the saved_flags
      as le32.
      
      fs/ubifs/debug.c:368:10: warning: cast to restricted __le32
      fs/ubifs/debug.c:368:10: warning: cast from restricted __le64
      
      Should be checked if the truncation was intentional, I've changed the
      printk to print the full width.
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      0ecb9529
  27. 18 9月, 2008 1 次提交
  28. 21 8月, 2008 1 次提交
  29. 13 8月, 2008 1 次提交