The issue appears to manifest itself when the connection is closed from the remote end and getsockopt(SCTP_STATUS) is called within a small window in which the association is still valid but asoc->peer.primary_path is NULL. On Thu, Mar 7, 2013 at 10:48 AM, Vlad Yasevich <vyasevich@xxxxxxxxx> wrote: > On 03/06/2013 08:53 PM, Vlad Yasevich wrote: >> >> On 03/06/2013 05:57 PM, Karl Heiss wrote: >>> >>> I am getting kernel panics due to a NULL dereference in >>> sctp_getsockopt_sctp_status() when calling getsockopt() with >>> SCTP_STATUS immediately after establishing a connection. This occurs >>> when transport = asoc->peer.primary_path; is NULL and transport is >>> later dereferenced. Is there any way that an association would be >>> present but have no primary_path? >> >> >> No, that shouldn't happen. The very first transport that is added >> to the association is assigned to the primary_path. Primary_path can >> never be null since the association must have at least 1 transport and >> that 1 transport will always be primary. >> >> Is this happening on the server or the client side? >> >> Which kernel version? >> >> Is Add-IP on and are there any Add-IP options in the packets? > > > Also, are you using SOCK_STREAM or SOCK_SEQPACKET sockets? > > Thanks > -vlad > > >> >> Thanks >> -vlad >> >>> Should >>> sctp_getsockopt_sctp_status() be checking asoc->peer.primary_path and >>> returning -EINVAL? >>> >>> Karl >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
