linux-ext4 - 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-next>] [day] [month] [year] [list]

Message-ID: <CAKwPUoz1Rtx-YZU0jm858ecQkXkf63KJ=JMmz6rekE=ko0sYFw@mail.gmail.com>
Date:   Fri, 3 Aug 2018 18:15:48 +0800
From:   Kassey <kassey1216@...il.com>
To:     tytso@....edu, keescook@...omium.org,
        Eric Biggers <ebiggers@...gle.com>, nborisov@...e.com,
        eguan@...hat.com, linux-ext4@...r.kernel.org
Cc:     kassey@....com
Subject: 4.9 kernel ext4 extent magic found in file data block

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),
and open the old file something like below
     /system/bin/hello_app

    fd = open(" /system/bin/hello_app", O_CREAT|O_WRONLY|O_TRUNC,0755);
    write(fd, buffer_from_ddr, len)
    close(fd)
    after all required files were updated, do a sync command.

    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.

    0004000 is the address in hex editor, this is not always same.

    0004000 f30a 0004 0154 0000 0000 0000 0000 0000


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



-- 
Best regards
Kassey