summaryrefslogtreecommitdiffstats
path: root/crypto/seqiv.c
diff options
context:
space:
mode:
authorDave Hansen <dave.hansen@linux.intel.com>2014-12-12 16:58:19 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2014-12-13 12:42:52 -0800
commitd3c97900b427b8d5a476fdfe484267f09df418d6 (patch)
tree0169510392ae190dcec4376a7341efe955fa27fd /crypto/seqiv.c
parent0050ee059f7fc86b1df2527aaa14ed5dc72f9973 (diff)
downloadop-kernel-dev-d3c97900b427b8d5a476fdfe484267f09df418d6.zip
op-kernel-dev-d3c97900b427b8d5a476fdfe484267f09df418d6.tar.gz
ipc/shm.c: fix overly aggressive shmdt() when calls span multiple segments
This is a highly-contrived scenario. But, a single shmdt() call can be induced in to unmapping memory from mulitple shm segments. Example code is here: http://www.sr71.net/~dave/intel/shmfun.c The fix is pretty simple: Record the 'struct file' for the first VMA we encounter and then stick to it. Decline to unmap anything not from the same file and thus the same segment. I found this by inspection and the odds of anyone hitting this in practice are pretty darn small. Lightly tested, but it's a pretty small patch. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Manfred Spraul <manfred@colorfullife.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'crypto/seqiv.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud