Thread (8 messages) flat view 8 messages, 3 authors, 2017-12-15

[PATCH 2/4] sctp: Add ip option support

From: paul@paul-moore.com (Paul Moore)
Date: 2017-12-15 14:02:09
Also in: linux-sctp, netdev, selinux

On December 14, 2017 4:04:28 PM Marcelo Ricardo Leitner
[off-list ref] wrote:
On Tue, Dec 12, 2017 at 05:24:46PM -0500, Paul Moore wrote:
quoted
On Tue, Dec 12, 2017 at 4:56 PM, Marcelo Ricardo Leitner
[off-list ref] wrote:
quoted
On Tue, Dec 12, 2017 at 04:33:03PM -0500, Paul Moore wrote:
quoted
On Tue, Dec 12, 2017 at 11:08 AM, Marcelo Ricardo Leitner
[off-list ref] wrote:
quoted
Hi Richard,

On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
...
quoted
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock
*sk, char __user *optval, unsigned
quoted
quoted
quoted
quoted
      if (asoc) {
              if (val == 0) {
+                     struct sctp_af *af = sp->pf->af;
                      val = asoc->pathmtu;
-                     val -= sp->pf->af->net_header_len;
+                     val -= af->ip_options_len(asoc->base.sk);
+                     val -= af->net_header_len;
                      val -= sizeof(struct sctphdr) +
                                      sizeof(struct sctp_data_chunk);
              }
Right below here there is a call to sctp_frag_point(). That function
also needs this tweak.

Yes, we should simplify all these calculations. I have a patch to use
sctp_frag_point on where it is currently recalculating it on
sctp_datamsg_from_user(), but probably should include other places as
well.
FYI: Richard let me know he is occupied with another project at the
moment and likely won't be able to do another respin until next week
at the earliest.
Okay, thanks. I can do a follow-up patch if it helps.
I'll leave that up to you, I think your comments are pretty
straightforward and should be easy for Richard to incorporate, and
there is a lot to be said for including the fix in the original patch,
but if you would prefer to send a separate patch I think that's fine
too.
This patchset conflicts with the stream schedulers patchset (on
sctp.h) and will also conflict with the stream interleaving patchsets
from Xin (other files).

I rebased the patchset upon current crypto tree but the last patchset
on stream interleaving is still to be accepted via net-next.

I'm unsure on how to proceed here. Please advise.

Thanks,
Marcelo
I still believe the right course of action is to merge this via the SELinux
tree (based on Linus' tree). Due to the nature of SELinux we often have to
deal with conflicts like this; I haven't seen the conflicts your talking
about (I'm currently traveling with limited access) but Linus should be
able to handle the trivial fixes, if it is more complex we can provide
guidance about how to resolve it.

--
paul moore
www.paul-moore.com


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help