summaryrefslogtreecommitdiff
path: root/fs/befs/io.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2018-02-06 15:42:08 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2018-02-06 18:32:48 -0800
commitf7340761812fc10313e6fcc115e0bc4f7a799112 (patch)
tree2374b679e8378f22800e233b0c69883546616138 /fs/befs/io.c
parentc4fed5a91fadc8a277b1eda474317b501651dd3e (diff)
pipe: read buffer limits atomically
The pipe buffer limits are accessed without any locking, and may be changed at any time by the sysctl handlers. In theory this could cause problems for expressions like the following: pipe_user_pages_hard && user_bufs > pipe_user_pages_hard ... since the assembly code might reference the 'pipe_user_pages_hard' memory location multiple times, and if the admin removes the limit by setting it to 0, there is a very brief window where processes could incorrectly observe the limit to be exceeded. Fix this by loading the limits with READ_ONCE() prior to use. Link: http://lkml.kernel.org/r/20180111052902.14409-8-ebiggers3@gmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: "Luis R . Rodriguez" <mcgrof@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/befs/io.c')
0 files changed, 0 insertions, 0 deletions