diff options
author | J. Bruce Fields <bfields@redhat.com> | 2018-10-18 15:27:02 -0400 |
---|---|---|
committer | Trond Myklebust <trond.myklebust@hammerspace.com> | 2018-10-18 17:20:57 -0400 |
commit | 826799e66e8683e5698e140bb9ef69afc8c0014e (patch) | |
tree | 8c1998d6ef140e64bd45152d035c087aa356e292 /net/sunrpc/xprt.c | |
parent | fc187514d8af3a676c7bd7922439f9f5e5c6223f (diff) | |
download | linux-826799e66e8683e5698e140bb9ef69afc8c0014e.tar.gz linux-826799e66e8683e5698e140bb9ef69afc8c0014e.tar.bz2 linux-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 'net/sunrpc/xprt.c')
0 files changed, 0 insertions, 0 deletions