Re: [PATCH] udf: prevent allocation beyond UDF partition

[Steve Magnani <steve.magnani@digidescorp.com>]

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@digidescorp.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>