Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755997Ab2B0WqI (ORCPT ); Mon, 27 Feb 2012 17:46:08 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:47298 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754860Ab2B0WqE (ORCPT ); Mon, 27 Feb 2012 17:46:04 -0500 Date: Mon, 27 Feb 2012 14:46:02 -0800 From: Andrew Morton To: Hugh Dickins Cc: Jarkko Sakkinen , James Morris , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH] tmpfs: security xattr setting on inode creation Message-Id: <20120227144602.07f5ec33.akpm@linux-foundation.org> In-Reply-To: References: <1329990365-23779-1-git-send-email-jarkko.sakkinen@intel.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1518 Lines: 50 On Fri, 24 Feb 2012 19:19:22 -0800 (PST) Hugh Dickins wrote: > +/* > + * Callback for security_inode_init_security() for acquiring xattrs. > + */ > +static int shmem_initxattrs(struct inode *inode, > + const struct xattr *xattr_array, > + void *fs_info) > +{ > + struct shmem_inode_info *info = SHMEM_I(inode); > + const struct xattr *xattr; > + struct shmem_xattr *new_xattr; > + size_t len; > + > + for (xattr = xattr_array; xattr->name != NULL; xattr++) { > + new_xattr = shmem_xattr_alloc(xattr->value, xattr->value_len); > + if (!new_xattr) > + return -ENOMEM; > + > + len = strlen(xattr->name) + 1; > + new_xattr->name = kmalloc(XATTR_SECURITY_PREFIX_LEN + len, > + GFP_KERNEL); > + if (!new_xattr->name) { > + kfree(new_xattr); > + return -ENOMEM; > + } > + > + memcpy(new_xattr->name, XATTR_SECURITY_PREFIX, > + XATTR_SECURITY_PREFIX_LEN); > + memcpy(new_xattr->name + XATTR_SECURITY_PREFIX_LEN, > + xattr->name, len); > + > + spin_lock(&info->lock); > + list_add(&new_xattr->list, &info->xattr_list); > + spin_unlock(&info->lock); > + } > + > + return 0; > +} So if there's a kmalloc failure partway through the array, we leave a partially xattrified inode in place. Are we sure this is OK? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/