From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Br=FCns=2C_Stefan?= Date: Fri, 9 Sep 2016 16:47:09 +0000 Subject: [U-Boot] [PATCH] ext4: fix possible crash on directory traversal, ignore deleted entries In-Reply-To: <20160902145308.GE4990@bill-the-cat> References: <614f4ec39414464eb4c053438c6f5e9c@rwthex-w2-b.rwth-ad.de> <5096748.Z86yB2JU2R@pebbles.site> <20160902145308.GE4990@bill-the-cat> Message-ID: <1773564.W4YydK1XsB@sbruens-linux> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Freitag, 2. September 2016 10:53:08 CEST you wrote: > > > > Adding this to the current test script is somewhat problematic. The test > > runs all tests for fat and ext4, so each testcase should be file system > > agnostic. Unfortunately fat and ext4 (at least as implemented in U-Boot) > > have different semantics, as ext4 in U-Boot requires all path to absolute > > paths, whereas fat seems to require something else (relative path? > > absolute path, but without leading '/'?). > > > > Calling 'fatwrite host 0 0 /. 0x10' happily creates a directory! called > > '/.', 'fatwrite host 0 0 /./foo 0x10' creates a file and copletely messes > > up the filesystem (according to fsck.vfat and mounting the fs in linux). > > > > Any advise? > > Can we fix this up in the argument parsing? This sounds like it's > showing some bugs in the fatwrite parsing code itself. The fatwrite code is hardly doing any parsing at all. It does not strip any "/" or "\" characters, does not interpret these as dir delimiters, and just pushes whatever it gets into the directory. For the lookup, it uses a function which is quite similar to the fatload/fatls function, but still different. It only traverses the root directory. The whole fatwrite seems to be a 50% almost verbatim copy of the read implementation and shares hardly any code. The problem is the "almost" copy, most functions have minor differences. I think lots of code could be removed from fatwrite if the read implementation where better structured, but e.g. the main entry point is a huge function which, depending on some flags either prints the directory listing while walking/traversing the tree, returns the file size, loads a specified file into a buffer, or errors out in case some path element was not reachable. So, currently there are two options for the bad fatwrite behaviour: a) add even more duplicate code to fatwrite b) restructure fatread to be reusable Opinions, please! Kind regards, Stefan