Re: [PATCH v3] selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()

[Tristan Madani]

On Wed, 01 Jul 2026, Paul Moore wrote:
> However, there is another issue relating to the SCTP softirq code paths:
> the fact that we call into sock_has_perm() in both
> __selinux_socket_bind() and selinux_socket_connect_helper().  The
> sock_has_perm() function uses current_sid() as the subject in the
> avc_has_perm() call, and in the softirq case that is not what we want.

Had a look at this. The ASCONF softirq path is:

  sctp_rcv()  [NET_RX softirq]
    -> sctp_process_asconf()
      -> sctp_process_asconf_param()
        -> security_sctp_bind_connect(sk, SCTP_PARAM_ADD_IP/SET_PRIMARY)
          -> selinux_sctp_bind_connect()
            -> sock_has_perm()
              -> avc_has_perm(current_sid(), sksec->sid, ...)

In softirq, current is whatever process was interrupted, so the subject
SID is effectively random. Meanwhile the port/node bind checks further
down in __selinux_socket_bind() and the port connect check in
selinux_socket_connect_helper() already use sksec->sid as the subject,
which is the established pattern for softirq context
(selinux_socket_sock_rcv_skb, selinux_sctp_assoc_request, etc.).

The approach I would suggest: thread an explicit subject SID into the inner
helpers. selinux_sctp_bind_connect() would pass sksec->sid, and the
process-context wrappers (selinux_socket_bind, selinux_socket_connect)
would pass current_sid(). That keeps sock_has_perm() semantics
unchanged for the normal path and makes the SID choice visible at each
call site.

I can send a patch for this if this approach works for you.

--
Tristan