29 May, 2019

5 commits

  • Contrary to fat12/16, fat32 can have root directory at any location
    and its size can be expanded.
    Without this patch, root directory won't grow properly and so we will
    eventually fail to add files under root directory. Please note that this
    can happen even if you delete many files as deleted directory entries
    are not reclaimed but just marked as "deleted" under the current
    implementation.

    Signed-off-by: AKASHI Takahiro
    Tested-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • When a long name directory entry is created, multiple directory entries
    may be occupied across a directory cluster boundary. Since only one
    directory cluster is cached in a directory iterator, a first cluster must
    be written back to device before switching over a second cluster.

    Without this patch, some added files may be lost even if you don't see
    any failures on write operation.

    Signed-off-by: AKASHI Takahiro
    Tested-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • With the commit below, fat now correctly handles a file read under
    a non-cluster-aligned root directory of fat12/16.
    Write operation should be fixed in the same manner.

    Fixes: commit 9b18358dc05d ("fs: fat: fix reading non-cluster-aligned
    root directory")
    Signed-off-by: AKASHI Takahiro
    Cc: Anssi Hannula
    Tested-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • fat_itr_root() allocates fatbuf so we free it on the exit path, if
    the function fails we should not free it, check the return value
    and skip freeing if the function fails.

    Signed-off-by: Andrew F. Davis

    Andrew F. Davis
     
  • File names may not contain control characters (< 0x20).
    Simplify the coding.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

05 May, 2019

1 commit


03 May, 2019

2 commits


27 Apr, 2019

4 commits

  • Per Pierre this change shouldn't have been applied as it was superseded
    by "fs: btrfs: fix btrfs_search_tree invalid results" which is also
    applied now as 1627e5e5985d.

    This reverts commit 633967f9818cb6a0e87ffa8cba33148a5bcc6edb.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • btrfs_search_tree should return the first item in the tree that is
    greater or equal to the searched item.

    The search algorithm did not properly handle the edge case where the
    searched item is higher than the last item of the node but lower than
    the first item of the next node. Instead of properly returning the first
    item of the next node, it was returning an invalid path pointer
    (pointing to a non-existent item after the last item of the node + 1).

    This fixes two issues in the btrfs driver:
    - Looking for a ROOT_ITEM could fail if it was the first item of its
    leaf node.
    - Iterating through DIR_INDEX entries (for readdir) could fail if the
    first DIR_INDEX entry was the first item of a leaf node.

    Signed-off-by: Pierre Bourdon
    Cc: Marek Behun

    Pierre Bourdon
     
  • Signed-off-by: Ismael Luceno

    Ismael Luceno Cortes
     
  • ROOT_ITEMs in btrfs are referenced without knowing their actual "offset"
    value. To perform these searches using only two items from the key, the
    btrfs driver uses a special "btrfs_search_tree_key_type" function.

    The algorithm used by that function to transform a 3-tuple search into a
    2-tuple search was subtly broken, leading to items not being found if
    they were the first in their tree node.

    This commit fixes btrfs_search_tree_key_type to properly behave in these
    situations.

    Signed-off-by: Pierre Bourdon
    Cc: Marek Behun

    Pierre Bourdon
     

10 Apr, 2019

7 commits

  • Ext4 allows for arbitrarily sized block group descriptors when 64-bit
    addressing is enabled, which was previously not properly supported. This
    patch dynamically allocates a chunk of memory of the correct size.

    Signed-off-by: Benjamin Lim

    Benjamin Lim
     
  • A FAT12/FAT16 root directory location is specified by a sector offset and
    it might not start at a cluster boundary. It also resides before the
    data area (before cluster 2).

    However, the current code assumes that the root directory is located at
    a beginning of a cluster, causing no files to be found if that is not
    the case.

    Since the FAT12/FAT16 root directory is located before the data area
    and is not aligned to clusters, using unsigned cluster numbers to refer
    to the root directory does not work well (the "cluster number" may be
    negative, and even allowing it be signed would not make it properly
    aligned).

    Modify the code to not use the normal cluster numbering when referring to
    the root directory of FAT12/FAT16 and instead use a cluster-sized
    offsets counted from the root directory start sector.

    This is a relatively common case as at least the filesystem formatter on
    Win7 seems to create such filesystems by default on 2GB USB sticks when
    "FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors,
    rootdir starts at half a cluster before cluster 2).

    dosfstools mkfs.vfat does not seem to create affected filesystems.

    Signed-off-by: Anssi Hannula
    Reviewed-by: Bernhard Messerklinger
    Tested-by: Bernhard Messerklinger

    Anssi Hannula
     
  • Hi,

    when I try to load a sparse file via ext4load, I am getting the error message
    'invalid extent'

    After a deeper look in the code, it seems to be an issue in the function ext4fs_get_extent_block in fs/ext4/ext4_common.c:

    The file starts with 1k of zeros. The blocksize is 1024. So the first extend block contains the following information:

    eh_entries: 1
    eh_depth: 1
    ei_block 1

    When the upper layer (ext4fs_read_file) asks for fileblock 0, we are running in the 'invalid extent' error message.
    For me it seems, that the code is not prepared for handling a sparse block at the beginning of the file. The following change, solved my problem:

    I am really not an expert in ext4 filesystems. Can somebody please have a look at this issue and give me a feedback, if I am totally wrong or not?

    Gero Schumacher
     
  • The command line is:
    ln target linkname

    Currently symbolic links are supported only in ext4 and only if the option
    CMD_EXT4_WRITE is enabled.

    Signed-off-by: Jean-Jacques Hiblot
    Reviewed-by: Tom Rini

    Jean-Jacques Hiblot
     
  • Re-use the functions used to write/create a file, to support creation of a
    symbolic link.
    The difference with a regular file are small:
    - The inode mode is flagged with S_IFLNK instead of S_IFREG
    - The ext2_dirent's filetype is FILETYPE_SYMLINK instead of FILETYPE_REG
    - Instead of storing the content of a file in allocated blocks, the path
    to the target is stored. And if the target's path is short enough, no block
    is allocated and the target's path is stored in ext2_inode.b.symlink

    As with regulars files, if a file/symlink with the same name exits, it is
    unlinked first and then re-created.

    Signed-off-by: Jean-Jacques Hiblot
    Reviewed-by: Tom Rini
    [trini: Fix ext4 env code]
    Signed-off-by: Tom Rini

    Jean-Jacques Hiblot
     
  • There is no need to modify the buffer passed to ext4fs_write_file().
    The memset() call is not required here and was likely copied from the
    equivalent part of the ext4fs_read_file() function where we do need it.

    Signed-off-by: Jean-Jacques Hiblot
    Reviewed-by: Tom Rini

    Jean-Jacques Hiblot
     
  • When a file contains extents, U-Boot currently reads extent-related data
    for each block in the file, even if that data is located in the same
    block each time. This significantly slows down loading of files that use
    extents. Implement a very dumb cache to prevent repeatedly reading the
    same block. Files with extents now load as fast as files without.

    Note: There are many cases where read_allocated_block() is called. This
    patch only addresses one of those places; all others still read redundant
    data in any case they did before. This is a minimal patch to fix the
    load command; other cases aren't fixed.

    Signed-off-by: Stephen Warren

    Stephen Warren
     

09 Apr, 2019

1 commit


23 Mar, 2019

1 commit

  • U-Boot doesn't support metadata_csum feature. Writing to filesystem with
    metadata_csum feature makes the filesystem corrupted and unbootable by
    Linux:

    [ 2.527495] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 0 failed (52188!=0)
    [ 2.537421] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 1 failed (5262!=0)
    ...
    [ 2.653308] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 14 failed (42611!=0)
    [ 2.662179] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 15 failed (21527!=0)
    [ 2.687920] JBD2: journal checksum error
    [ 2.691982] EXT4-fs (mmcblk0p2): error loading journal
    [ 2.698292] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -74

    Don't write to filesystem with meatadata_csum feature to not corrupt the
    filesystem.

    Signed-off-by: Sébastien Szymanski

    Sébastien Szymanski
     

01 Mar, 2019

1 commit

  • When compiling with DEBUG=1 an error
    fs/fat/fat_write.c:831: undefined reference to `__aeabi_ldivmod'
    occurred.

    We should use do_div() instead of the modulus operator.

    filesize and cur_pos cannot be negative. So let's use u64 to avoid
    warnings.

    Fixes: cb8af8af5ba0 ("fs: fat: support write with non-zero offset")
    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

19 Feb, 2019

2 commits


09 Feb, 2019

1 commit

  • Unlike other generic FS accessors, fs_get_info() does not call fs_close()
    at the end of it's operation. Thus, using fs_get_info() in do_fs_type()
    without calling fs_close() causes potential memory leak by creating new
    filesystem structures on each call of do_fs_type().

    The test case to trigger this problem is as follows. It is required to
    have ext4 filesystem on the first partition of the SDMMC device, since
    ext4 requires stateful mount and causes memory allocation.
    => while true ; do mmc rescan ; fstype mmc 1 ; done
    Eventually, the mounting of ext4 will fail due to malloc failures
    and the filesystem will not be correctly detected.

    This patch fixes the problem by adding the missing fs_close().

    Signed-off-by: Marek Vasut
    Cc: Simon Glass
    Cc: Tom Rini

    Marek Vasut
     

02 Feb, 2019

1 commit

  • This fixes the automatic lmb initialization and reservation for boards
    with more than one DRAM bank.

    This fixes the CVE-2018-18439 and -18440 fixes that only allowed to load
    files into the firs DRAM bank from fs and via tftp.

    Found-by: Heinrich Schuchardt
    Signed-off-by: Simon Goldschmidt
    Tested-by: Heinrich Schuchardt
    Reviewed-by: Simon Glass

    Simon Goldschmidt
     

01 Feb, 2019

4 commits


17 Jan, 2019

1 commit


11 Jan, 2019

1 commit

  • This particular commit is causing a regression on stih410-b2260 and
    other platforms when reading from FAT16. Noting that I had rebased the
    original fix from Thomas onto then-current master, there is also
    question from Akashi-san if the change is still needed after other FAT
    fixes that have gone in.

    This reverts commit a68b0e11ea774492713a65d9fd5bb525fcaefff3.

    Reported-by: Patrice Chotard
    Cc: AKASHI Takahiro
    Cc: Thomas RIENOESSL
    Signed-off-by: Tom Rini

    Tom Rini
     

31 Dec, 2018

2 commits

  • The call to file_cbfs_fill_cache() is given with the parameter
    'start' pointing to the offset by the CBFS base address, but
    with the parameter 'size' that equals to the whole CBFS size.
    During CBFS walking through, it checks files one by one and
    after it pass over the end of the CBFS which is 4GiB boundary
    it tries to check files from address 0 and so on, until the
    overall size the codes checked hits to the given 'size'.

    Fix this by passing 'start' pointing to the CBFS base address.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • cbfs_fileheader.len indicates the content size of the file in the
    cbfs, and it has nothing to do with cbfs_fileheader.offset which
    is the starting address of the file in the cbfs.

    Remove such check in file_cbfs_next_file(). Before this change
    'cbfsinit' failed with 'Bad CBFS file'. After this change all cbfs
    commands are working as expected.

    Signed-off-by: Christian Gmeiner
    [bmeng: keep the necessary header sanity check]
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Christian Gmeiner
     

07 Dec, 2018

2 commits

  • The long name apparently can be accumulated using multiple
    13-byte slots. Unfortunately we never checked how many we
    can actually fit in the buffer we are reading to.

    Signed-off-by: Patrick Wildt

    Patrick Wildt
     
  • The cluster size specifies how many sectors make up a cluster. A
    cluster size of zero makes no sense, as it would mean that the
    cluster is made up of no sectors. This will later lead into a
    division by zero in sect_to_clust(), so better take care of that
    early.

    The MAX_CLUSTSIZE define can reduced using a define to make some
    room in low-memory system. Unfortunately if the code reads a
    filesystem with a bigger cluster size it will overflow the buffer.

    Signed-off-by: Patrick Wildt

    Patrick Wildt
     

03 Dec, 2018

1 commit

  • As in the case of fs_set_blk_dev(), fs_set_blk_dev_with_part() should
    maintain and update fs_dev_part whenever called.

    Without this patch, a problem will come up when an efi binary associated
    with efi's BOOTxxxx variable is invoked via "bootefi bootmgr".

    Signed-off-by: AKASHI Takahiro
    Signed-off-by: Alexander Graf

    AKASHI Takahiro
     

21 Nov, 2018

1 commit


17 Nov, 2018

1 commit


07 Nov, 2018

1 commit

  • Add local size_t variable to crypto_comp_decompress as intermediate
    storage for destination length to avoid memory corruption and incorrect
    results on 64 bit targets.

    This is what linux does for the various lz compression implementations.

    Signed-off-by: Paul Davey
    Cc: Heiko Schocher
    Tested-by: Heiko Schocher

    Paul Davey