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

On Wed, Jul 1, 2026 at 9:10 PM Tristan Madani <[email protected]> wrote:
>
> 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.

I am not Paul but FWIW this approach would work for me.