summaryrefslogtreecommitdiff
path: root/Documentation/m68k
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 /Documentation/m68k
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 'Documentation/m68k')
0 files changed, 0 insertions, 0 deletions