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 > <20190206201430.18830-1-julien@xxxxxxxxxx> > "[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 <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) >
