On 6/1/2018 9:29 AM, CHANDAN VN wrote:

quoted

quoted

?I?agree?that?the?fix?can?be?done?simply?by?using?"false"?for?
?smack_inode_getsecurity(),?but?what?happens?with?kernfs_node_setsecdata()
?and?smack_inode_notifysecctx().?kernfs_node_setsecdata()?is?probably?ignorable
?but?smack_inode_notifysecctx()?is?sending?the?"ctx"?to?smack_inode_setsecurity()
?and?since?"ctx"?would?be?NULL?because?we?used?"false",?smack_inode_setsecurity()
?becomes?dummy.

?

quoted

Thank?you?for?pointing?this?out.?You're?right,?there's?more
at?issue?here?than?changing?the?alloc?flag?will?fix.?I?think
that?calling?smack_inode_getsecurity()?from?smack_inode_getsecctx()
is?making?the?code?more?complicated?than?it?needs?to?be.?I?will
have?a?patch?shortly.

If you think the patch would take time or is complicated, I suggest that the kfree() fix should go
to fix the leaks for now.

Heavens no! The patch is very simple. I'm building a kernel with
it now, and should have it tested and posted within a few hours.
The implementation of smack_inode_getsecctx() that's there is
understandable, but wrong. There's a much better way to do the
job.

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