Kernel Bug Tracker – Bug 192
loop.c IV calculation is broken since 2.4.x
Last modified: 2003-07-19 02:08:04 UTC
loop's initial vector (=IV) calculation is based on the logical blocknumber
(necessary for crypto). Copy your image to another medium with a different
blocksize and the image will be broken. This flaw is known for a long time since
2.4.x, but the 2.4.x maintainers hesitated to correct it, since it will break
any old images. I'd like to emphasize that this is the best point in time to fix
that issue once and for all.
Fix: Always use the same IV calculation, which can only be the smallest
granulity available for blocksizes -> 512.
I'm told Adam J. Richter <firstname.lastname@example.org> has submitted patches for loop.c,
but obviously his requests have been ignored.
Created attachment 55 [details]
Adam J. Richter's Patch for 2.5.50
Ping Adam about the problem, as far as I'm concerned he's free to submit his
loop patches to Linus.
Does anyone know the status of this patch? Does it fix the problem reported
here so that the bug can be moved to the resolved state, or has patch made it to
the mainline kernel tree so that the bug can be closed?
nothing has changed. this issue is still present. adam has a backward compatible
patch, but it depends on other patches .. I'm not up-to-date if these patches
have been submitted && accepted.
Created attachment 393 [details]
trivial loop.c patch. based on hvr's 2.4.x version.
This is the most trivial patch for this issue. Not backward compatible. See
I've attached a trivial patch for loop.c
It is NOT backward compatible with any loop transformation which uses the IV
information. However I think it is a feasible solution, since
- Adam's changes to loop.c are too big to get accepted in the near future. There
is no loop.c maintainer, and no one is working on splitting up Adam's patches.
- To my knowledge there is no project which uses loop.c's IV information except
for loop-AES and CryptoAPI. These two crypto projects have fixed this issue two
years ago. Therefor their userbase will not be affected since they're using the
new scheme already.
So, my suggestion is to apply this dirty fix and go for a clean-up of loop.c
No. This will break existing crypto loop installations, making
the existing encrypted image unreable.
The only way to implement this is with a new flag that is set by losetup
and keep the old behaviour by default.
I believe that this is fixed by patched from Andries Brouwer.
It is getting somewhat late :-)
this is correct. thanks for keeping track.