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]
Message-ID: <0449d177-28f3-2da8-b893-940e9e0511ed@digidescorp.com>
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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ