From: Seth Forshee <sforshee@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Gaosheng Cui <cuigaosheng1@huawei.com>,
serge@hallyn.com, paul@paul-moore.com, jmorris@namei.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] security: commoncap: fix potential memleak on error path from vfs_getxattr_alloc
Date: Tue, 25 Oct 2022 08:45:41 -0500 [thread overview]
Message-ID: <Y1fohadXVWj3Q89E@do-x1extreme> (raw)
In-Reply-To: <20221025130459.kk42edsz56vsd3ur@wittgenstein>
On Tue, Oct 25, 2022 at 03:04:59PM +0200, Christian Brauner wrote:
> On Tue, Oct 25, 2022 at 06:45:44PM +0800, Gaosheng Cui wrote:
> > In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
> > complete the memory allocation of tmpbuf, if we have completed
> > the memory allocation of tmpbuf, but failed to call handler->get(...),
> > there will be a memleak in below logic:
> >
> > |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) <-- alloc for tmpbuf
> > |-- value = krealloc(*xattr_value, error + 1, flags) <-- alloc memory
> > |-- error = handler->get(handler, ...) <-- if error
> > |-- *xattr_value = value <-- xattr_value is &tmpbuf <-- memory leak
> >
> > So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.
>
> Hey Gaosheng,
>
> >
> > Fixes: 71bc356f93a1 ("commoncap: handle idmapped mounts")
>
> The Fixes: tag is wrong afaict. The control flow isn't changed in any
> way by the referenced commit.
>
> The logic changed the last time with
> 82e5d8cc768b ("security: commoncap: fix -Wstringop-overread warning")
> but even that commit wouldn't have introduced the bug. It would've been
> introduced by 8db6c34f1dbc ("Introduce v3 namespaced file
> capabilities"). So update the Fixes: tag with that reference, please.
>
> Otherwise I think you in principle have a point. Not sure if we have any
> filesystem that in practice would fail after permission checks have
> already passed with the first call to ->get() but then fail with the
> correct size passed in the second ->get() invocation. Sounds super
> unlikely but not impossible.
Looks like several other callers have the same problem --
evm_is_immutable(), evm_xattr_change(), ima_eventevmsig_init(). And
ima_read_xattr() expects the caller to handle it which seems potentially
problematic, though currently only current caller does handle it
properly.
The documention comment for vfs_getxattr_alloc() needs a warning that
the caller needs to free memory even if an error is returned, because
that is very counterintuitive. It probably should have been named
vfs_getxattr_realloc() ...
Seth
next prev parent reply other threads:[~2022-10-25 13:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 10:45 [PATCH] security: commoncap: fix potential memleak on error path from vfs_getxattr_alloc Gaosheng Cui
2022-10-25 13:04 ` Christian Brauner
2022-10-25 13:45 ` Seth Forshee [this message]
2022-10-25 13:51 ` cuigaosheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1fohadXVWj3Q89E@do-x1extreme \
--to=sforshee@kernel.org \
--cc=brauner@kernel.org \
--cc=cuigaosheng1@huawei.com \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox