linux-ext4 - Re: 4.9 kernel ext4 extent magic found in file data block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180803150914.GC32066@thunk.org>
Date:   Fri, 3 Aug 2018 11:09:14 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Kassey <kassey1216@...il.com>
Cc:     keescook@...omium.org, Eric Biggers <ebiggers@...gle.com>,
        nborisov@...e.com, eguan@...hat.com, linux-ext4@...r.kernel.org,
        kassey@....com
Subject: Re: 4.9 kernel ext4 extent magic found in file data block

On Fri, Aug 03, 2018 at 06:15:48PM +0800, Kassey wrote:
> hi linux-ext4 team:
> 
>     we got a easy reproduced issue that during OTA, the storage is  Samsung UFS.
>     we will extract the updated file to DDR firstly(buffer_from_ddr)...
> 
>     but we found some of the files is corrupted sometimes.
>     we compared the success and failure found that below pattern f30a
> EXT4_EXT_MAGIC
>     were in the failure file data block.
> 
>     which should be expected to in inode table extent info.
> 

The way OTA (Over the air) update works is that it "patches" the file
system.  Specifically, userspace (a program in the recovery partition)
is directly updating the file system at the block level.

The OTA data file is calculated by looking at the starting file system
image, and the destination file system image, comparing the two, and
then creating a "delta" file which is what is actually sent over the
air.

What you are seeing could be caused by:

*) A bug in the program which generates the OTA file

*) A bug in the program which uses the OTA file to update file systems

*) The OTA file getting corrupted

*) The starting file system image is different from what is expected;
   that is, it is different from the starting file system image used
   when generating the OTA file.

>    do you have some debug suggest to check how a extent looks like
> info write to a ext4 file data block ?

A file data block can look like *anything*, including the header of
extent data block.  For example, if you create a file system image,
e.g:

	mke2fs -t ext4 test.img 8M

The file system that contains test.img will, by *definition* contain
blocks that look like extent data blocks; in fact, they *are* extent
data blocks, but not for the file system where test.img is stored, but
in the test.img file system itself.

Furthermore, the program which applies the OTA update has no idea
whether a particular block it is updating is file data block.  It
simply doesn't have that context.  The OTA update system is also not
something which is maintained by the upstream ext4 developers (which
is who you have contacted when you e-mailed linux-ext4@...r.kernel.org).

So I'm afraid we can't help you behind giving you a general
explanation of how OTA works (and this is only something I know
because I've worked with the Android team).  I would check to see
whether you are properly configuring and creating OTA updates, as well
as checking whether Samsung made many local changes to the OTA update
system.

Best regards,

					- Ted