[pkg-cryptsetup-devel] Bug#935702: Bug#935702: Wrong DM device size due to integer truncation

[Guilhem Moulin]

Control: retitle -1 DM device size ≥2³² 512-bits sectors is truncated on 32-bits platforms
Control: tag -1 + upstream

Hi,

On Sun, 25 Aug 2019 at 12:43:26 +0000, nbf at waifu.club wrote:
> Not only the access to protected data is lost, the integritysetup's "open"
> operation actually succeeds. All reads on the incorrectly created DM device
> will of course fail with I/O errors due to bad integrity tags, but all
> writes will happily write wrong tags at wrong places! This makes it very
> easy for the administrator to destroy the data while trying to recover with
> --integrity-recovery-mode.

Would you mind sharing your test vector, either here or the upstream bug
tracker at https://gitlab.com/cryptsetup/cryptsetup/issues ?  While it's
clear there is a bug, I was unable to reproduce your observations in the
arguably most common cases, namely block devices formatted as LUKS1 or
LUKS2 with the default parameters (and a payload size exceeding ≥2³²
512-bits sectors).  The only function of the dm_*_target_set() family
called is dm_crypt_target_set(), and always with 0 as segment offset and
size.

`cryptsetup plainOpen -b $LARGE_NUMBER` does yield a call to dm_crypt_target_set()
with a truncated dmd.size, but the proper size is used before opening
the device thanks to device_block_adjust().

Or does the bug only applies to integrity targets?  I'm indeed able to
reproduce for these targets:

    $ uname -r
    4.19.0-5-686
    $ truncate -s3T /tmp/disk.img
    $ losetup /dev/loop0 /tmp/disk.img

    $ integritysetup format -s 512 --no-wipe -q /dev/loop0
    $ integritysetup dump /dev/loop0 | grep provided_data_sectors
    provided_data_sectors 6392379512
    $ integritysetup open /dev/loop0 integrity_test
    $ echo $?
    0
    $ dmsetup table integrity_test
    0 2097412216 integrity …

    syslog contains (checksum errors are due to no-wipe):
    […] device-mapper: integrity: Checksum failed at sector 0x7d03f780
    […] device-mapper: integrity: Checksum failed at sector 0x7d03f780
    […] Buffer I/O error on dev dm-2, logical block 262176496, async page read


    ## experimental --integrity extension
    $ cryptsetup luksFormat -q --integrity hmac-sha256 --integrity-no-wipe \
        --pbkdf-force-iterations 4 --pbkdf-memory 32 /dev/loop0 <<<test
    $ cryptsetup luksOpen /dev/loop0 crypt_test <<<test
    $ echo $?
    0
    $ dmsetup table crypt_test crypt_test_dif
    crypt_test: 0 1768359968 crypt …
    crypt_test_dif: 0 1768359968 integrity …

    syslog contains (checksum errors are due to no-wipe):
    […] device-mapper: crypt: INTEGRITY AEAD ERROR, sector 1768359808
    […] device-mapper: crypt: INTEGRITY AEAD ERROR, sector 1768359808
    […] Buffer I/O error on dev dm-3, logical block 221044976, async page read

2097412216 and 1768359968 are both 6063327264 on a 64-bits system.  I
didn't check verity targets, but wasn't able to reproduce this with
crypt targets.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20190826/733d660d/attachment.sig>