linux-kernel - Re: [PATCH] udf: prevent allocation beyond UDF partition

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

Date:   Wed, 31 Jul 2019 09:06:44 -0500
From:   Steve Magnani <steve.magnani@...idescorp.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Jan Kara <jack@...e.com>, Steve Magnani <steve@...idescorp.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Pali Rohár <pali.rohar@...il.com>
Subject: Re: [PATCH] udf: prevent allocation beyond UDF partition

On 7/31/19 4:59 AM, Jan Kara wrote:
> On Sun 28-07-19 14:19:12, Steve Magnani wrote:
>> The UDF bitmap allocation code assumes that a recorded
>> Unallocated Space Bitmap is compliant with ECMA-167 4/13,
>> which requires that pad bytes between the end of the bitmap
>> and the end of a logical block are all zero.
>>
>> When a recorded bitmap does not comply with this requirement,
>> for example one padded with FF to the block boundary instead
>> of 00, the allocator may "allocate" blocks that are outside
>> the UDF partition extent. This can result in UDF volume descriptors
>> being overwritten by file data or by partition-level descriptors,
>> and in extreme cases, even in scribbling on a subsequent disk partition.
>>
>> Add a check that the block selected by the allocator actually
>> resides within the UDF partition extent.
>>
>> Signed-off-by: Steven J. Magnani <steve@...idescorp.com>
> Thanks for the patch! Added to my tree. I've just slightly modified the
> patch to also output error message about filesystem corruption.
>
> 								Honza


Thanks Jan. Ror the record, it appears that Windows chkdsk has a bug in its
analysis of a space bitmaps. If the last block of a UDF partition falls
in the middle of a bitmap byte, chkdsk reports spurious errors if the bits
in that byte that _don't_ correspond to UDF partition blocks are zero.

To maximize interoperability it would appear that it's best to format such
that UDF partition sizes are always a multiple of 8 blocks.

Note to non-UDF wonks reading this, a UDF partition is a sub-extent of a
disk partition. So achieving the multiple-of-8-blocks involves a change to
mkudffs code.

------------------------------------------------------------------------
  Steven J. Magnani               "I claim this network for MARS!
  www.digidescorp.com              Earthling, return my space modulator!"

  #include <standard.disclaimer>