On 03/07/2013 10:29 AM, Neil Horman wrote:
On Thu, Mar 07, 2013 at 03:52:35PM +0100, Cristian Constantin wrote:
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)
All paths that touch primary_path hold the associated socket lock for the socket
that owns the transport path, so there shouldn't be any changing of the primary
path while accessing it here, at least not in the upstream kernel.
Right. I don't this that condition is possible. Association can't live
without at least 1 transport and that 1 transport will always be primary.
-vlad
Regards
Neil
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
--
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
