On Wed, Mar 06, 2013 at 08:53:02PM -0500, 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.
cristian: hi!
but, vlad, at least in 2.6.30.2 (which I have on my hdd with
the "tags" already computed), sctp_getsockopt_primary_addr() is a little
bit more conservative and does:
...
asoc = sctp_id2assoc(sk, prim.ssp_assoc_id);
if (!asoc)
return -EINVAL;
if (!asoc->peer.primary_path)
return -ENOTCONN;
...
any idea if is there any big difference btw. the two getsockopt()s? behind
them, everything is assumed to be asynch., right? (in the sense that
the assoc. can come and go at any time)
thanks!
bye now!
cristian
--
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
