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]
Date:	Tue, 25 Dec 2012 13:48:25 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Chen Gang <gang.chen@...anux.com>
Cc:	jack@...e.cz, akpm@...ux-foundation.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] fs/ext3: use kzalloc instead of kmalloc

On Mon, Dec 24, 2012 at 01:28:53PM +0800, Chen Gang wrote:
> 
>   better to use kzalloc instead of kmalloc.
>     if acl_e->e_tag is neither ACL_USER, nor ACL_GROUP.
>     entry->e_id will not be initialized
> 
>   we can not say it is a bug, but suggest to initialize it, too.
> 
> Signed-off-by: Chen Gang <gang.chen@...anux.com>

This shouldn't be a problem, since if e_tag is not ACL_USER nor
ACL_GROUP, the on-disk encoding does not include e_id at all.

That being said, it looks to me there's another bug hiding here.  The
size of the extended attribute is calculated by ext3_acl_size(), and
it looks totally wrong.  For one thing, it caluclates the size of the
xattr assuming all of the stored encoding ext3_acl_entry_short ---
which would not be the case if we had a acl entry of type ACL_USER or
ACL_GROUP.

But if that were the case, it would mean that we would not be storing
the full acl entry on disk, which would be a pretty horrible and
obvious breakage.

I haven't had time to check this yet, but I wanted to flag this so
hopefully someone else should double check this.....  It would seem to
me that the better thing to do would be to calculate the size as part
of the for loop in ext3_acl_to_disk(), and drop ext3_acl_size() from
acl.h.  (This code exists in ext4 as well, so if we have a bug in
ext3, we would have a similar bug in ext4.)


						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ