linux-kernel - [GIT PULL][PATCH] tracing: Fix buggered tee(2) on tracing

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>] [day] [month] [year] [list]

Date:	Fri, 17 Jan 2014 23:28:01 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: [GIT PULL][PATCH] tracing: Fix buggered tee(2) on tracing_pipe


Linus,

Al Viro has concerns with the trace_pipe release method calling
__free_page() instead of using the generic_pipe_buf_release() which
does a page_cache_release(). Looking at the differences between
__free_page() and page_cache_release() I do not think there's a real
issue here. But to be on the safe side, and at least to be symmetric
with generic_pipe_buf_get(), this patch is fine to add.

Please pull the latest trace-fixes-v3.13-rc8 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.13-rc8

Tag SHA1: 5a8329936de8662773042fa76bc3c3d0c48fe5c3
Head SHA1: c50b3d58415b1f46bdb044fbd4e807cda49f0aa2


Al Viro (1):
      tracing: Fix buggered tee(2) on tracing_pipe

----
 kernel/trace/trace.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)
---------------------------
commit c50b3d58415b1f46bdb044fbd4e807cda49f0aa2
Author: Al Viro <viro@...IV.linux.org.uk>
Date:   Fri Jan 17 07:53:39 2014 -0500

    tracing: Fix buggered tee(2) on tracing_pipe
    
    In kernel/trace/trace.c we have this:
    static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
                                         struct pipe_buffer *buf)
    {
            __free_page(buf->page);
    }
    static const struct pipe_buf_operations tracing_pipe_buf_ops = {
            .can_merge              = 0,
            .map                    = generic_pipe_buf_map,
            .unmap                  = generic_pipe_buf_unmap,
            .confirm                = generic_pipe_buf_confirm,
            .release                = tracing_pipe_buf_release,
            .steal                  = generic_pipe_buf_steal,
            .get                    = generic_pipe_buf_get,
    };
    with
    void generic_pipe_buf_get(struct pipe_inode_info *pipe, struct pipe_buffer *buf)
    {
            page_cache_get(buf->page);
    }
    
    and I don't see anything that would've prevented tee(2) called on the pipe
    that got stuff spliced into it from that sucker.  ->ops->get() will be
    called, then buf gets copied into target pipe's ->bufs[] and eventually
    readers get to both copies of the buffer.  With
    	get_page(page)
    	look at that page
    	__free_page(page)
    	look at that page
    	__free_page(page)
    which is not a good thing, to put it mildly.  AFAICS, that ought to use
    the normal generic_pipe_buf_release() (aka page_cache_release(buf->page)),
    shouldn't it?
    
    [
     SDR - As trace_pipe just allocates the page with alloc_page(GFP_KERNEL),
      and doesn't do anything special with it (no LRU logic). The __free_page()
      should be fine, as it wont actually free a page with reference count.
      Maybe there's a chance to leak memory? Anyway, This change is at a minimum
      good for being symmetric with generic_pipe_buf_get, it is fine to add.
    ]
    
    Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
    [ SDR - Removed no longer used tracing_pipe_buf_release ]
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9d20cd9..8f86143 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4212,12 +4212,6 @@ out:
 	return sret;
 }
 
-static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
-				     struct pipe_buffer *buf)
-{
-	__free_page(buf->page);
-}
-
 static void tracing_spd_release_pipe(struct splice_pipe_desc *spd,
 				     unsigned int idx)
 {
@@ -4229,7 +4223,7 @@ static const struct pipe_buf_operations tracing_pipe_buf_ops = {
 	.map			= generic_pipe_buf_map,
 	.unmap			= generic_pipe_buf_unmap,
 	.confirm		= generic_pipe_buf_confirm,
-	.release		= tracing_pipe_buf_release,
+	.release		= generic_pipe_buf_release,
 	.steal			= generic_pipe_buf_steal,
 	.get			= generic_pipe_buf_get,
 };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/