linux-kernel - Re: CVE-2004-2135 and CVE-2004-2136

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-next>] [day] [month] [year] [list]

Message-Id: <20091203205311.9a9478e4.michael.s.gilbert@gmail.com>
Date:	Thu, 3 Dec 2009 20:53:11 -0500
From:	Michael Gilbert <michael.s.gilbert@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: CVE-2004-2135 and CVE-2004-2136

On Thu, 3 Dec 2009 17:53:21 +0100 markus reichelt wrote:
> * Michael Gilbert wrote:
> 
> > CVE-2004-2135 [0] and CVE-2004-2136 [1] were disclosed over five
> > years ago; however, i have been unable to verify whether they have
> > been fixed or not in the latest kernels.
> 
> They are not, and both CVE-entries are still marked as 'candidate'.
> Add the fact that (crypto)loop code has had a poor relation with the
> vanilla kernel in favour of dm-crypt, and is also unmaintained,
> nobody really cares.
> 
> Did you receive any other replies to your mail? Just curious.

None so far.  Would it make sense to remove cryptoloop at this point
since it obviously has some major design/implementation weaknesses?
Apropos, there are two other full-disk encryption options (dm-crypt and
loop-aes) that, importantly, are not affected by these issues. Is it
really a good idea to have three different implementations of
essentially the same functionality?

Best wishes,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/