Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Neil Horman <nhorman@tuxdriver.com>
Date: 2019-02-06 20:50:31
Also in:
linux-sctp, lkml
On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
quoted hunk ↗ jump to hunk
Make sctp_setsockopt_events() able to accept sctp_event_subscribe structures longer than the current definitions. This should prevent unjustified setsockopt() failures due to struct sctp_event_subscribe extensions (as in 4.11 and 4.12) when using binaries that should be compatible, but were built with later kernel uapi headers. Signed-off-by: Julien Gomes <redacted> --- net/sctp/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 9644bdc8e85c..f9717e2789da 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c@@ -2311,7 +2311,7 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval, int i; if (optlen > sizeof(struct sctp_event_subscribe)) - return -EINVAL; + optlen = sizeof(struct sctp_event_subscribe);
I'm not sure I like this. If you have a userspace application built against more recent uapi headers than the kernel you are actually running on, then by defintion you won't have this check in place, and you'll get EINVAL returns anyway. If you just backport this patch to an older kernel, you'll not get the EINVAL return, but you will get silent failures on event subscriptions that your application thinks exists, but the kernel doesn't recognize. This would make sense if you had a way to communicate back to user space the unrecognized options, but since we don't (currently) have that, I would rather see the EINVAL returned than just have things not work. Neil
if (copy_from_user(&subscribe, optval, optlen)) return -EFAULT; -- 2.20.1