splice: handle zero nr_pages in splice_to_pipe()
BugLink: http://bugs.launchpad.net/bugs/1572722
commit
d6785d9152147596f60234157da2b02540c3e60f upstream.
Running the following command:
busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null
with any tracing enabled pretty very quickly leads to various NULL
pointer dereferences and VM BUG_ON()s, such as these:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000020
IP: [<
ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
Call Trace:
[<
ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
[<
ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
[<
ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
[<
ffffffff81196869>] do_sendfile+0x199/0x380
[<
ffffffff81197600>] SyS_sendfile64+0x90/0xa0
[<
ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d
page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
kernel BUG at include/linux/mm.h:367!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
RIP: [<
ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
Call Trace:
[<
ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
[<
ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
[<
ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
[<
ffffffff81196869>] do_sendfile+0x199/0x380
[<
ffffffff81197600>] SyS_sendfile64+0x90/0xa0
[<
ffffffff8192cd1e>] tracesys_phase2+0x84/0x89
(busybox's cat uses sendfile(2), unlike the coreutils version)
This is because tracing_splice_read_pipe() can call splice_to_pipe()
with spd->nr_pages == 0. spd_pages underflows in splice_to_pipe() and
we fill the page pointers and the other fields of the pipe_buffers with
garbage.
All other callers of splice_to_pipe() avoid calling it when nr_pages ==
0, and we could make tracing_splice_read_pipe() do that too, but it
seems reasonable to have splice_to_page() handle this condition
gracefully.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>