On Wed, Jun 15, 2022 at 6:04 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Wed, Jun 15, 2022 at 4:03 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Tue, Jun 14, 2022 at 9:25 AM Xiu Jianfeng <xiujianfeng@xxxxxxxxxx> wrote: > > > > > > In this function, it directly returns the result of __security_read_policy > > > without freeing the allocated memory in *data, cause memory leak issue, > > > so free the memory if __security_read_policy failed. > > > > > > Signed-off-by: Xiu Jianfeng <xiujianfeng@xxxxxxxxxx> > > > --- > > > security/selinux/ss/services.c | 9 ++++++++- > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > This is another case where there is not actually a memory leak as the > > only caller of security_read_policy() is sel_open_policy() which will > > free the buffer it passes to security_read_policy() on error. > > > > If you want you could add a comment to security_read_policy() > > indicating that the caller is responsible for freeing the memory. > > Can we please not have two almost identical functions with different > cleanup conventions? Please let's either make both functions guarantee > cleanup on error or neither of them (adapting the caller(s) and > comments accordingly). Priorities Ondrej, priorities. Every patch posted to the list has a time and effort cost associated with it, and between reviewing other more important patches and working on a proper SCTP/SELinux fix, I simply don't have the cycles to spend doing the back-and-forth on a patch like this to fix a memory leak that doesn't exist. It definitely isn't because I don't think the code could be improved, it is just that there are only so many hours in a day and I need to prioritize actual bugs and important new features that people want merged. ... oh, and I need to reply to the complaints too, that's always the highlight of my day. -- paul-moore.com
