sctp on RHEL9

sctp on RHEL9

[David Laight]

A bit of a gamble...

Anyone any idea why RHEL9 should reject sctp setsockopt() calls like SCTP_INITMSG?

My guess is some security check that doesn't allow for sctp.

I don't have access to the failing system - it is a customer of the company
I used to work for.

	David

Re: sctp on RHEL9

[Marcelo Ricardo Leitner]

On Tue, Nov 18, 2025 at 11:07:43PM +0000, David Laight wrote:
> A bit of a gamble...
> 
> Anyone any idea why RHEL9 should reject sctp setsockopt() calls like SCTP_INITMSG?

More likely an invalid buffer as argument. It has to have the exact
size of struct sctp_initmsg, and not more than that.

  Marcelo

Re: sctp on RHEL9

[David Laight]

On Fri, 28 Nov 2025 08:45:52 -0300
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:

> On Tue, Nov 18, 2025 at 11:07:43PM +0000, David Laight wrote:
> > A bit of a gamble...
> > 
> > Anyone any idea why RHEL9 should reject sctp setsockopt() calls like SCTP_INITMSG?  
> 
> More likely an invalid buffer as argument. It has to have the exact
> size of struct sctp_initmsg, and not more than that.

It was resolved.
Basically the code is an out of tree driver and they were using an old version
that calls kernel_setsockopt().
That was removed from the kernel well before the one RHEL9 is based on, so we'd
expected they get a build error (the driver usually runs if it builds).
But it seems RHEL9 has a wrapper for kernel_setsockopt() that doesn't actually work.
The later driver has its own correct wrapper and worked fine.

	David

Re: sctp on RHEL9

[Marcelo Ricardo Leitner]

On Fri, Nov 28, 2025 at 11:59:26AM +0000, David Laight wrote:
> On Fri, 28 Nov 2025 08:45:52 -0300
> Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> 
> > On Tue, Nov 18, 2025 at 11:07:43PM +0000, David Laight wrote:
> > > A bit of a gamble...
> > > 
> > > Anyone any idea why RHEL9 should reject sctp setsockopt() calls like SCTP_INITMSG?  
> > 
> > More likely an invalid buffer as argument. It has to have the exact
> > size of struct sctp_initmsg, and not more than that.
> 
> It was resolved.
> Basically the code is an out of tree driver and they were using an old version
> that calls kernel_setsockopt().
> That was removed from the kernel well before the one RHEL9 is based on, so we'd
> expected they get a build error (the driver usually runs if it builds).
> But it seems RHEL9 has a wrapper for kernel_setsockopt() that doesn't actually work.
> The later driver has its own correct wrapper and worked fine.

Ah ok. kABI can play some tricks, but yeah, this one seems off.

  Marcelo