On 26/08/2019 03:28, Guilhem Moulin wrote: > On Sun, 25 Aug 2019 at 12:43:26 +0000, n...@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.
No need to report it upstream, I'll fix it. This is really stupid bug, all sizes in code must be uint_64t. I just wonder why no static analysis screamed here, I run it on 32bit... Thanks for the report! m.