linux-kernel - Re: [PATCH v3] pipe: Fix memory leaks in create_pipe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <68ab61d0ba3a6ddd7838bc293c9e24f5d8002e27.camel@redhat.com>
Date:   Thu, 01 Oct 2020 09:37:02 -0400
From:   Qian Cai <cai@...hat.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] pipe: Fix memory leaks in create_pipe_files()

On Thu, 2020-10-01 at 14:16 +0100, Al Viro wrote:
> On Thu, Oct 01, 2020 at 08:50:55AM -0400, Qian Cai wrote:
> > Calling pipe2() with O_NOTIFICATION_PIPE could results in memory leaks
> > in an error path or CONFIG_WATCH_QUEUE=n. Plug them.
> 
> [snip the copy of bug report]
> 
> No objections on the patch itself, but commit message is just about
> unreadable.  How about something along the lines of the following?
> 
> =======================
> 	Calling pipe2() with O_NOTIFICATION_PIPE could results in memory
> leaks unless watch_queue_init() is successful.
> 
> 	In case of watch_queue_init() failure in pipe2() we are left
> with inode and pipe_inode_info instances that need to be freed.  That
> failure exit has been introduced in commit c73be61cede5 ("pipe: Add
> general notification queue support") and its handling should've been
> identical to nearby treatment of alloc_file_pseudo() failures - it
> is dealing with the same situation.  As it is, the mainline kernel
> leaks in that case.
> 
> 	Another problem is that CONFIG_WATCH_QUEUE and !CONFIG_WATCH_QUEUE 
> cases are treated differently (and the former leaks just pipe_inode_info,
> the latter - both pipe_inode_info and inode).
> 
> 	Fixed by providing a dummy wath_queue_init() in !CONFIG_WATCH_QUEUE
> case and by having failures of wath_queue_init() handled the same way
> we handle alloc_file_pseudo() ones.
> 
> Fixes: c73be61cede5 ("pipe: Add general notification queue support")
> Signed-off-by: Qian Cai <cai@...hat.com>
> =======================

Thanks Al. This looks very good to me.