[ 064/167] [PATCH 04/26] sctp: Allow struct sctp_event_subscribe to growwithout breaking binaries
From: Ben Hutchings
Date: Wed May 09 2012 - 02:11:23 EST
3.2-stable review patch. If anyone has any objections, please let me know.
From: Thomas Graf <tgraf@xxxxxxxxxxxxx>
[ Upstream commit acdd5985364f8dc511a0762fab2e683f29d9d692 ]
getsockopt(..., SCTP_EVENTS, ...) performs a length check and returns
an error if the user provides less bytes than the size of struct
Struct sctp_event_subscribe needs to be extended by an u8 for every
new event or notification type that is added.
This obviously makes getsockopt fail for binaries that are compiled
against an older versions of <net/sctp/user.h> which do not contain
all event types.
This patch changes getsockopt behaviour to no longer return an error
if not enough bytes are being provided by the user. Instead, it
returns as much of sctp_event_subscribe as fits into the provided buffer.
This leads to the new behavior that users see what they have been aware
of at compile time.
The setsockopt(..., SCTP_EVENTS, ...) API is already behaving like this.
Signed-off-by: Thomas Graf <tgraf@xxxxxxx>
Acked-by: Vlad Yasevich <vladislav.yasevich@xxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
net/sctp/socket.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 54a7cd2..0075554 100644
@@ -4133,9 +4133,10 @@ static int sctp_getsockopt_disable_fragments(struct sock *sk, int len,
static int sctp_getsockopt_events(struct sock *sk, int len, char __user *optval,
int __user *optlen)
- if (len < sizeof(struct sctp_event_subscribe))
+ if (len <= 0)
- len = sizeof(struct sctp_event_subscribe);
+ if (len > sizeof(struct sctp_event_subscribe))
+ len = sizeof(struct sctp_event_subscribe);
if (put_user(len, optlen))
if (copy_to_user(optval, &sctp_sk(sk)->subscribe, len))
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/