On Sun, Apr 19, 2020 at 12:25:36PM +0200, Harald Welte wrote:

Dear Linux SCTP developers,

this patchset (merged back in Q4/2019) has broken ABI compatibility, more
or less exactly as it was discussed/predicted in Message-Id
[ref]
"[PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length"
on this very list in February 2019.

The process to reproduce this is quite simple:
* upgrade your kernel / uapi headers to a later version (happens
  automatically on most distributions as linux-libc-dev is upgraded)
* rebuild any application using SCTP_EVENTS which was working perfectly
  fine before
* fail to execute on any older kernels

This can be a severe issue in production systems where you may not
upgrade the kernel until/unless a severe security issue actually makes
you do so.

Those steps above can very well happen on different machines, i.e. your
build server having a more recent linux-libc-dev package (and hence
linux/sctp.h) than some of the users in the field are running kernels.

I think this is a severe problem that affects portability of binaries
between differnt Linux versions and hence the kind of ABI breakage that
the kernel exactly doesn't want to have.

The point here is that there is no check if any of those newly-added
events at the end are actually used.  I can accept that programs using
those new options will not run on older kernels - obviously.  But old
programs that have no interest in new events being added should run just
fine, even if rebuilt against modern headers.

In the kernel setsockopt handling coee: Why not simply check if any of
the newly-added events are actually set to non-zero?  If those are all
zero, we can assume that the code doesn't use them.

Yes, for all the existing kernels out there it's too late as they simply
only have the size based check.  But I'm worried history will repeat
itself...

Thanks for your consideration.

As Marcello noted, I don't think theres anything we can do here.  We screwed
this up, but reverting the change is just going to create a second breakage
point through which users are going to have to deal with this.  The best way
forward is to document the need to run a newer userspace uapi header set on a
correspondingly new kernel, and be sure in the future that any extension to the
uapi structures are codified as separate structures with separate socket options
(or some simmilar approach to allow for fixed size api structures)

Neil

-- 
- Harald Welte [off-list ref]           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)