From: Greg Kroah-Hartman Date: Fri, 18 May 2018 07:24:10 +0000 (+0200) Subject: 3.18-stable patches X-Git-Tag: v4.16.10~10 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c65b523036054fbf4f553abab7ab8e197e126c5c;p=thirdparty%2Fkernel%2Fstable-queue.git 3.18-stable patches added patches: pipe-cap-initial-pipe-capacity-according-to-pipe-max-size-limit.patch --- diff --git a/queue-3.18/pipe-cap-initial-pipe-capacity-according-to-pipe-max-size-limit.patch b/queue-3.18/pipe-cap-initial-pipe-capacity-according-to-pipe-max-size-limit.patch new file mode 100644 index 00000000000..a206611869b --- /dev/null +++ b/queue-3.18/pipe-cap-initial-pipe-capacity-according-to-pipe-max-size-limit.patch @@ -0,0 +1,67 @@ +From 086e774a57fba4695f14383c0818994c0b31da7c Mon Sep 17 00:00:00 2001 +From: "Michael Kerrisk (man-pages)" +Date: Tue, 11 Oct 2016 13:53:43 -0700 +Subject: pipe: cap initial pipe capacity according to pipe-max-size limit + +From: Michael Kerrisk (man-pages) + +commit 086e774a57fba4695f14383c0818994c0b31da7c upstream. + +This is a patch that provides behavior that is more consistent, and +probably less surprising to users. I consider the change optional, and +welcome opinions about whether it should be applied. + +By default, pipes are created with a capacity of 64 kiB. However, +/proc/sys/fs/pipe-max-size may be set smaller than this value. In this +scenario, an unprivileged user could thus create a pipe whose initial +capacity exceeds the limit. Therefore, it seems logical to cap the +initial pipe capacity according to the value of pipe-max-size. + +The test program shown earlier in this patch series can be used to +demonstrate the effect of the change brought about with this patch: + + # cat /proc/sys/fs/pipe-max-size + 1048576 + # sudo -u mtk ./test_F_SETPIPE_SZ 1 + Initial pipe capacity: 65536 + # echo 10000 > /proc/sys/fs/pipe-max-size + # cat /proc/sys/fs/pipe-max-size + 16384 + # sudo -u mtk ./test_F_SETPIPE_SZ 1 + Initial pipe capacity: 16384 + # ./test_F_SETPIPE_SZ 1 + Initial pipe capacity: 65536 + +The last two executions of 'test_F_SETPIPE_SZ' show that pipe-max-size +caps the initial allocation for a new pipe for unprivileged users, but +not for privileged users. + +Link: http://lkml.kernel.org/r/31dc7064-2a17-9c5b-1df1-4e3012ee992c@gmail.com +Signed-off-by: Michael Kerrisk +Reviewed-by: Vegard Nossum +Cc: Willy Tarreau +Cc: +Cc: Tetsuo Handa +Cc: Jens Axboe +Cc: Al Viro +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Daniel Sangorrin +Signed-off-by: Greg Kroah-Hartman + +--- + fs/pipe.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/pipe.c ++++ b/fs/pipe.c +@@ -618,6 +618,9 @@ struct pipe_inode_info *alloc_pipe_info( + unsigned long pipe_bufs = PIPE_DEF_BUFFERS; + struct user_struct *user = get_current_user(); + ++ if (pipe_bufs * PAGE_SIZE > pipe_max_size && !capable(CAP_SYS_RESOURCE)) ++ pipe_bufs = pipe_max_size >> PAGE_SHIFT; ++ + if (!too_many_pipe_buffers_hard(user)) { + if (too_many_pipe_buffers_soft(user)) + pipe_bufs = 1; diff --git a/queue-3.18/series b/queue-3.18/series index f73f8d053d7..d71e2bca686 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -18,3 +18,4 @@ qmi_wwan-do-not-steal-interfaces-from-class-drivers.patch lockd-lost-rollback-of-set_grace_period-in-lockd_down_net.patch revert-arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch l2tp-revert-l2tp-fix-missing-print-session-offset-info.patch +pipe-cap-initial-pipe-capacity-according-to-pipe-max-size-limit.patch