1. 09 Feb, 2023 1 commit
    • Jan Kara's avatar
      udf: Avoid directory type conversion failure due to ENOMEM · df97f64d
      Jan Kara authored
      When converting directory from in-ICB to normal format, the last
      iteration through the directory fixing up directory enteries can fail
      due to ENOMEM. We do not expect this iteration to fail since the
      directory is already verified to be correct and it is difficult to undo
      the conversion at this point. So just use GFP_NOFAIL to make sure the
      small allocation cannot fail.
      
      Reported-by: syzbot+111eaa994ff74f8d440f@syzkaller.appspotmail.com
      Fixes: 0aba4860 ("udf: Allocate name buffer in directory iterator on heap")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      df97f64d
  2. 07 Feb, 2023 3 commits
    • Kees Cook's avatar
      udf: Use unsigned variables for size calculations · 51e38c92
      Kees Cook authored
      To avoid confusing the compiler about possible negative sizes, switch
      various size variables that can never be negative from int to u32. Seen
      with GCC 13:
      
      ../fs/udf/directory.c: In function 'udf_copy_fi':
      ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 80 and size [-2147483648, -1] [-Warray-bounds=]
         57 | #define __underlying_memcpy     __builtin_memcpy
            |                                 ^
      ...
      ../fs/udf/directory.c:102:9: note: in expansion of macro 'memcpy'
        102 |         memcpy(&iter->fi, iter->bh[0]->b_data + off, len);
            |         ^~~~~~
      
      Cc: Jan Kara <jack@suse.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Message-Id: <20230204183427.never.856-kees@kernel.org>
      51e38c92
    • Tom Rix's avatar
      udf: remove reporting loc in debug output · f8d0dd0b
      Tom Rix authored
      clang build fails with
      fs/udf/partition.c:86:28: error: variable 'loc' is uninitialized when used here [-Werror,-Wuninitialized]
                                sb, block, partition, loc, index);
                                                      ^~~
      
      loc is now only known when bh is valid. So remove reporting loc in debug
      output.
      
      Fixes: 4215db46 ("udf: Use udf_bread() in udf_get_pblock_virt15()")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatar"kernelci.org bot" <bot@kernelci.org>
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Reviewed-by: default avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      f8d0dd0b
    • Vladislav Efanov's avatar
      udf: Check consistency of Space Bitmap Descriptor · 1e0d4adf
      Vladislav Efanov authored
      Bits, which are related to Bitmap Descriptor logical blocks,
      are not reset when buffer headers are allocated for them. As the
      result, these logical blocks can be treated as free and
      be used for other blocks.This can cause usage of one buffer header
      for several types of data. UDF issues WARNING in this situation:
      
      WARNING: CPU: 0 PID: 2703 at fs/udf/inode.c:2014
        __udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014
      
      RIP: 0010:__udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014
      Call Trace:
       udf_setup_indirect_aext+0x573/0x880 fs/udf/inode.c:1980
       udf_add_aext+0x208/0x2e0 fs/udf/inode.c:2067
       udf_insert_aext fs/udf/inode.c:2233 [inline]
       udf_update_extents fs/udf/inode.c:1181 [inline]
       inode_getblk+0x1981/0x3b70 fs/udf/inode.c:885
      
      Found by Linux Verification Center (linuxtesting.org) with syzkaller.
      
      [JK: Somewhat cleaned up the boundary checks]
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarVladislav Efanov <VEfanov@ispras.ru>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      1e0d4adf
  3. 26 Jan, 2023 36 commits