[PATCH v4 1/5] reiserfs: Add missing calls to reiserfs_security_free()

Paul Moore paul at paul-moore.com
Tue Nov 22 22:47:31 UTC 2022


On Tue, Nov 22, 2022 at 3:12 AM Roberto Sassu
<roberto.sassu at huaweicloud.com> wrote:
> On Mon, 2022-11-21 at 18:41 -0500, Paul Moore wrote:
> > On Thu, Nov 10, 2022 at 4:47 AM Roberto Sassu
> > <roberto.sassu at huaweicloud.com> wrote:
> > > From: Roberto Sassu <roberto.sassu at huawei.com>
> > >
> > > Commit 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes
> > > during inode creation") defined reiserfs_security_free() to free the name
> > > and value of a security xattr allocated by the active LSM through
> > > security_old_inode_init_security(). However, this function is not called
> > > in the reiserfs code.
> > >
> > > Thus, add a call to reiserfs_security_free() whenever
> > > reiserfs_security_init() is called, and initialize value to NULL, to avoid
> > > to call kfree() on an uninitialized pointer.
> > >
> > > Finally, remove the kfree() for the xattr name, as it is not allocated
> > > anymore.
> > >
> > > Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation")
> > > Cc: stable at vger.kernel.org
> > > Cc: Jeff Mahoney <jeffm at suse.com>
> > > Cc: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
> > > Reported-by: Mimi Zohar <zohar at linux.ibm.com>
> > > Reported-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
> > > Signed-off-by: Roberto Sassu <roberto.sassu at huawei.com>
> > > ---
> > >  fs/reiserfs/namei.c          | 4 ++++
> > >  fs/reiserfs/xattr_security.c | 2 +-
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > If I'm understanding this patch correctly, this is a standalone
> > bugfix, right?  Any reason this shouldn't be merged now, independent
> > of the rest of patches in this patchset?
>
> Yes. It would be fine for me to pick this sooner.

Okay, as it's been almost two weeks with no comments from the reiserfs
folks and this looks okay to me I'm going to go ahead and pull this
into the lsm/next branch as it's at least "LSM adjacent" :)  As it is
lsm/next and not lsm/stable-6.1, this should give the reiserfs folks
another couple of weeks to object if they find this to be problematic.

Thanks all.

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list