Skip to content
Snippets Groups Projects
  1. Oct 20, 2010
    • Stefano Babic's avatar
      FAT: buffer overflow with FAT12/16 · 11c8dd36
      Stefano Babic authored
      
      Last commit 3831530d was intended
      "explicitly specify FAT12/16 root directory parsing buffer size, instead
      of relying on cluster size". Howver, the underlying function requires
      the size of the buffer in blocks, not in bytes, and instead of passing
      a double sector size a request for 1024 blocks is sent. This generates
      a buffer overflow with overwriting of other structure (in the case seen,
      USB structures were overwritten).
      
      Signed-off-by: default avatarStefano Babic <sbabic@denx.de>
      CC: Mikhail Zolotaryov <lebon@lebon.org.ua>
      11c8dd36
  2. Oct 12, 2010
    • Mikhail Zolotaryov's avatar
      VFAT: fix processing of scattered long file name entries · 3831530d
      Mikhail Zolotaryov authored
      
      The U-Boot code has the following bugs related to the processing of Long File
      Name (LFN) entries scattered across several clusters/sectors :
      
      1) get_vfatname() function is designed to gather scattered LFN entries by
      cluster chain processing - that doesn't work for FAT12/16 root directory.
      In other words, the function expects the following input data:
       1.1) FAT32 directory (which is cluster chain based);
              OR
       1.2) FAT12/16 non-root directory (which is also cluster chain based);
              OR
       1.3) FAT12/16 root directory (allocated as contiguous sectors area), but
       all necessary information MUST be within the input buffer of filesystem cluster
       size (thus cluster-chain jump is never initiated).
      
      In order to accomplish the last condition, root directory parsing code in
      do_fat_read() uses the following trick: read-out cluster-size block, process
      only first sector (512 bytes), then shift 512 forward, read-out cluster-size
      block and so on. This works great unless cluster size is equal to 512 bytes
      (in a case you have a small partition), or long file name entries are scattered
      across three sectors, see 4) for details.
      
      2) Despite of the fact that get_vfatname() supports FAT32 root directory
      browsing, do_fat_read() function doesn't send current cluster number correctly,
      so root directory look-up doesn't work correctly.
      
      3) get_vfatname() doesn't gather scattered entries correctly also is the case
      when all LFN entries are located at the end of the source cluster, but real
      directory entry (which must be returned) is at the only beginning of the
      next one. No error detected, the resulting directory entry returned contains
      a semi-random information (wrong size, wrong start cluster number and so on)
      i.e. the entry is not accessible.
      
      4) LFN (VFAT) allows up to 20 entries (slots) each containing 26 bytes (13
      UTF-16 code units) to represent a single long file name i.e. up to 520 bytes.
      U-Boot allocates 256 bytes buffer instead, i.e. 10 or more LFN slots record
      may cause buffer overflow / memory corruption.
      Also, it's worth to mention that 20+1 slots occupy 672 bytes space which may
      take more than one cluster of 512 bytes (medium-size FAT32 or small FAT16
      partition) - get_vfatname() function doesn't support such case as well.
      
      The patch attached fixes these problems in the following way:
      - keep using 256 bytes buffer for a long file name, but safely prevent a
      possible buffer overflow (skip LFN processing, if it contains 10 or more
      slots).
      
      - explicitly specify FAT12/16 root directory parsing buffer size, instead
      of relying on cluster size. The value used is a double sector size (to store
      current sector and the next one). This fixes the first problem and increases
      performance on big FAT12/16 partitions;
      
      - send current cluster number (FAT32) to get_vfatname() during root
      directory processing;
      
      - use LFN counter to seek the real directory entry in get_vfatname() - fixes the
      third problem;
      
      - skip deleted entries in the root directory (to prevent bogus buffer
      overflow detection and LFN counter steps).
      
      Note: it's not advised to split up the patch, because a separate part may
      operate incorrectly.
      
      Signed-off-by: default avatarMikhail Zolotaryov <lebon@lebon.org.ua>
      3831530d
  3. Aug 07, 2010
  4. Jul 24, 2010
    • Wolfgang Denk's avatar
      fs/fat: Big code cleanup. · 7385c28e
      Wolfgang Denk authored
      
      - reformat
      - throw out macros like FAT_DPRINT and FAT_DPRINT
      - remove dead code
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      7385c28e
    • Wolfgang Denk's avatar
      FAT32: fix broken root directory handling. · 2aa98c66
      Wolfgang Denk authored
      
      On FAT32, instead of fetching the cluster numbers from the FAT, the
      code assumed (incorrectly) that the clusters for the root directory
      were allocated contiguously. In the result, only the first cluster
      could be accessed. At the typical cluster size of 8 sectors this
      caused all accesses to files after the first 128 entries to fail -
      "fatls" would terminate after 128 files (usually displaying a bogus
      file name, occasionally even crashing the system), and "fatload"
      would fail to find any files that were not in the first directory
      cluster.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      2aa98c66
    • Wolfgang Denk's avatar
      FAT32: fix support for superfloppy-format (PBR) · 66c2d73c
      Wolfgang Denk authored
      
      "Superfloppy" format (in U-Boot called PBR) did not work for FAT32 as
      the file system type string is at a different location. Add support
      for FAT32.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      66c2d73c
  5. May 28, 2010
  6. Apr 28, 2010
  7. Mar 31, 2010
  8. Jan 15, 2010
    • Wolfgang Denk's avatar
      JFFS2: drop support for LZARI compression mode · f0983371
      Wolfgang Denk authored
      
      Support for LZARI compression mode was added based on a MTD CVS
      snapshot of March 13, 2005. However, fs/jffs2/compr_lzari.c contains
      contradictory licensing terms: the original copyright clause says "All
      rights reserved. Permission granted for non-commercial use.", but
      later reference to the file 'LICENCE' in the jffs2 directory was added
      which says GPL v2 or later.
      
      As no boards ever used LZARI compression, and this file is also not
      present in recent MTD code, we resolve this conflict by removing the
      conflicting file and references to it.
      
      Also copy the referenced but missing file 'LICENCE' from the current
      MTD source tree.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      f0983371
  9. Dec 21, 2009
  10. Dec 08, 2009
  11. Dec 04, 2009
  12. Oct 03, 2009
  13. Sep 28, 2009
  14. Sep 23, 2009
  15. Sep 15, 2009
  16. Aug 21, 2009
    • Ilya Yanok's avatar
      jffs2: some fixes to summary support · 8cf19b9f
      Ilya Yanok authored
      
      This patch fixes some issues with JFFS2 summary support in U-Boot.
      1/ Summary support made compilation configurable (as summary support
      considered expiremental even in Linux).
      2/ Summary code can do unaligned 16-bit and 32-bit memory accesses.
      We need to get data byte by byte to exclude data aborts.
      3/ Make summary scan in two passes so we can safely fall back to full
      scan if we found unsupported entry in the summary.
      
      Signed-off-by: default avatarIlya Yanok <yanok@emcraft.com>
      8cf19b9f
  17. Aug 18, 2009
  18. Jul 28, 2009
  19. Jul 17, 2009
    • Scott Wood's avatar
      Remove legacy NAND and disk on chip code. · be33b046
      Scott Wood authored
      
      Legacy NAND had been scheduled for removal.  Any boards that use this
      were already not building in the previous release due to an #error.
      
      The disk on chip code in common/cmd_doc.c relies on legacy NAND,
      and it has also been removed.  There is newer disk on chip code
      in drivers/mtd/nand; someone with access to hardware and sufficient
      time and motivation can try to get that working, but for now disk
      on chip is not supported.
      
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      be33b046
  20. Jun 12, 2009
    • Tom Rix's avatar
      FAT replace compare_sign with strncmp. · 651351fe
      Tom Rix authored
      
      The static function compare_sign is only used to compare the fs_type string
      and does not do anything more than what strncmp does.
      
      The addition of the trailing '\0' to fs_type, while legal, is not needed
      because the it is never printed out and strncmp does not depend on NULL
      terminated strings.
      
      Signed-off-by: default avatarTom Rix <Tom.Rix@windriver.com>
      651351fe
  21. Jun 09, 2009
  22. Apr 30, 2009
  23. Apr 27, 2009
  24. Apr 04, 2009
  25. Apr 03, 2009
    • unsik Kim's avatar
      mflash: Initial mflash support · 75eb82ec
      unsik Kim authored
      
      Mflash is fusion memory device mainly targeted consumer eletronic and
      mobile phone.
      Internally, it have nand flash and other hardware logics and supports
      some different operation (ATA, IO, XIP) modes.
      
      IO mode is custom mode for the host that doesn't have IDE interface.
      (Many mobile targeted SoC doesn't have IDE bus)
      
      This driver support mflash IO mode.
      
      Followings are brief descriptions about IO mode.
      
      1. IO mode based on ATA protocol and uses some custom command. (read
         confirm, write confirm)
      2. IO mode uses SRAM bus interface.
      
      Signed-off-by: default avatarunsik Kim <donari75@gmail.com>
      75eb82ec
  26. Mar 20, 2009
    • Michael Lawnick's avatar
      UBIFS: Missing offset relocation for compressor 'none' · faac4fd8
      Michael Lawnick authored
      
      On systems where U-Boot is linked to another address than it really lays
      (e.g. backup image), calls via function pointers must be fixed with a
      '+= gd->reloc_off'.
      This was not done for none_compr in ubifs_compressors_init() what leads
      to system crash on ubifsmount command.
      
      Signed-off-by: default avatarMichael Lawnick <ml.lawnick@gmx.de>
      Acked-by: default avatarStefan Roese <sr@denx.de>
      faac4fd8
    • Stefan Roese's avatar
      UBIFS: Implement read-only UBIFS support in U-Boot · 9eefe2a2
      Stefan Roese authored
      
      The U-Boot UBIFS implementation is largely a direct copy from the current
      Linux version (2.6.29-rc6). As already done in the UBI version we have an
      "abstraction layer" to redefine or remove some OS calls (e.g. mutex_lock()
      ...). This makes it possible to use the original Linux code with very
      little changes. And by this we can better update to later Linux versions.
      
      I removed some of the Linux features that are not used in the U-Boot
      version (e.g. garbage-collection, write support).
      
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      CC: Artem Bityutskiy <dedekind@infradead.org>
      CC: Adrian Hunter <ext-Adrian.Hunter@nokia.com>
      9eefe2a2
  27. Jan 27, 2009
  28. Jan 24, 2009
  29. Dec 16, 2008
  30. Dec 10, 2008
  31. Dec 09, 2008
    • Ilya Yanok's avatar
      jffs2: cache data_crc results · 142a80ff
      Ilya Yanok authored
      
      As we moved data_crc() invocation from jffs2_1pass_build_lists() to
      jffs2_1pass_read_inode() data_crc is going to be calculated on each
      inode access. This patch adds caching of data_crc() results. There
      is no significant improvement in speed (because of flash access
      caching added in previous patch I think, crc in RAM is really fast)
      but this patch impacts memory usage -- every b_node structure uses
      12 bytes instead of 8.
      
      Signed-off-by: default avatarAlexey Neyman <avn@emcraft.com>
      Signed-off-by: default avatarIlya Yanok <yanok@emcraft.com>
      142a80ff
Loading