summaryrefslogtreecommitdiffstats
path: root/include/trace
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@redhat.com>2018-10-18 15:27:02 -0400
committerTrond Myklebust <trond.myklebust@hammerspace.com>2018-10-18 17:20:57 -0400
commit826799e66e8683e5698e140bb9ef69afc8c0014e (patch)
tree8c1998d6ef140e64bd45152d035c087aa356e292 /include/trace
parentfc187514d8af3a676c7bd7922439f9f5e5c6223f (diff)
downloadlinux-stable-826799e66e8683e5698e140bb9ef69afc8c0014e.tar.gz
linux-stable-826799e66e8683e5698e140bb9ef69afc8c0014e.tar.bz2
linux-stable-826799e66e8683e5698e140bb9ef69afc8c0014e.zip
sunrpc: safely reallow resvport min/max inversion
Commits ffb6ca33b04b and e08ea3a96fc7 prevent setting xprt_min_resvport greater than xprt_max_resvport, but may also break simple code that sets one parameter then the other, if the new range does not overlap the old. Also it looks racy to me, unless there's some serialization I'm not seeing. Granted it would probably require malicious privileged processes (unless there's a chance these might eventually be settable in unprivileged containers), but still it seems better not to let userspace panic the kernel. Simpler seems to be to allow setting the parameters to whatever you want but interpret xprt_min_resvport > xprt_max_resvport as the empty range. Fixes: ffb6ca33b04b "sunrpc: Prevent resvport min/max inversion..." Fixes: e08ea3a96fc7 "sunrpc: Prevent rexvport min/max inversion..." Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Diffstat (limited to 'include/trace')
0 files changed, 0 insertions, 0 deletions