linux-kernel - Re: [ 026/180] eCryptfs: Improve statfs reporting

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

Message-ID: <506ADCEB.1040109@canonical.com>
Date:	Tue, 02 Oct 2012 06:24:11 -0600
From:	Tim Gardner <tim.gardner@...onical.com>
To:	Tyler Hicks <tyhicks@...onical.com>
CC:	Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Colin Ian King <colin.king@...onical.com>,
	Stefan Bader <stefan.bader@...onical.com>
Subject: Re: [ 026/180] eCryptfs: Improve statfs reporting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2012 11:46 PM, Tyler Hicks wrote:
> On 2012-10-02 00:52:23, Willy Tarreau wrote:
>> 2.6.32-longterm review patch.  If anyone has any objections,
>> please let me know.
> 
> Hi - Please drop this patch. It incorrectly calculates f_namelen
> and I haven't had a chance to fix it yet. When I get a fix ready,
> I'll forward the corrected patch to stable@....o. Thanks!
> 
> Tyler
> 
>> 
>> ------------------
>> 
>> From: Tyler Hicks <tyhicks@...onical.com>
>> 
>> commit 4a26620df451ad46151ad21d711ed43e963c004e upstream.
>> 
>> BugLink: http://bugs.launchpad.net/bugs/885744
>> 
>> statfs() calls on eCryptfs files returned the wrong filesystem
>> type and, when using filename encryption, the wrong maximum
>> filename length.
>> 
>> If mount-wide filename encryption is enabled, the cipher block
>> size and the lower filesystem's max filename length will
>> determine the max eCryptfs filename length. Pre-tested, known
>> good lengths are used when the lower filesystem's namelen is 255
>> and a cipher with 8 or 16 byte block sizes is used. In other,
>> less common cases, we fall back to a safe rounded-down estimate
>> when determining the eCryptfs namelen.
>> 
>> https://launchpad.net/bugs/885744
>> 
>> Signed-off-by: Tyler Hicks <tyhicks@...onical.com> Reported-by:
>> Kees Cook <keescook@...omium.org> Reviewed-by: Kees Cook
>> <keescook@...omium.org> Reviewed-by: John Johansen
>> <john.johansen@...onical.com> Signed-off-by: Colin Ian King
>> <colin.king@...onical.com> Acked-by: Stefan Bader
>> <stefan.bader@...onical.com> Signed-off-by: Tim Gardner
>> <tim.gardner@...onical.com> Signed-off-by: Willy Tarreau
>> <w@....eu> --- fs/ecryptfs/crypto.c          |   68
>> ++++++++++++++++++++++++++++++++++++---- 
>> fs/ecryptfs/ecryptfs_kernel.h |   11 ++++++ 
>> fs/ecryptfs/keystore.c        |    9 ++--- fs/ecryptfs/super.c
>> |   18 ++++++++++- 4 files changed, 92 insertions(+), 14
>> deletions(-)

Tyler - this is the same patch that we're carrying in every kernel
from Lucid to Quantal, right ? Colin has verified test cases for this,
so I'm curious what you think is wrong. Something unique to 2.6.32 ?

https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/5
https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/9

rtg
- -- 
Tim Gardner tim.gardner@...onical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQatzmAAoJED12yEX6FEfKwpsP/jgSVRAb3X/Xu1Hob46T2TD3
XFClsr4xWlRzrHKsKxDHZxYUKy6TexEB9ZagjfFIlteqbyEqOB+Eq/p7cFrouIlm
nX4/ERslly1H1tvm9x7hc3fUN3M8C5dwWsARjiRHY3luEZapIyMETnrikhahpZM5
xferd8RIowgTkDUfnLwBVhwagJSvpaBgavJq1Kn5+6ArEPWtT1AeiybHoJ0fOTb8
uNuCTjSHOhZh5ssConAyxhPiCgl0NYBdzHNPmuc+jO0ZDfb9NFfnNUUB6lRdrVhe
QJBXX1N4N90R70nnQBHFNWJCdMJpjbE80PdE/T8IAsUqa8IFpHzfZZJYRgMVUbc9
2nkQ+ZLTSOIy2IZSCGZzWA/kf9bRGuUF/KcPizpKEB7s2QDlPp3Rrt/zs1DRbnt5
FBWmfgtb37Hpz94EGaMQzTIAj0iZXqZ68njww3c1ELllCMmj+z/0UKktLCOhz3dO
ntlp8EUAD1F+Z5cMYxEP20Gn3EVvENSDfJnpdzWgTYzqNqFixCTC+cOWLl3OmCoL
2XxYDG6b6N6Y0dYMxjQV/DrptEXzr4kl70mLTa6yED6a3uxSSDGwRpM16feBR785
a83u27nVe9DLwJIo4D/gxmTiCsYZ7N5Y62hFMSwYgBFYrKDEq2wK6XizCerr11RB
NZ3Rh1IDrSVxBPwqpS/w
=z24H
-----END PGP SIGNATURE-----
--
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/