lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 14 Aug 2020 13:36:34 +0000 From: David Laight <David.Laight@...LAB.COM> To: "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>, Neil Horman <nhorman@...driver.com> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: RE: sctp: num_ostreams and max_instreams negotiation > > At some point the negotiation of the number of SCTP streams > > seems to have got broken. > > I've definitely tested it in the past (probably 10 years ago!) > > but on a 5.8.0 kernel getsockopt(SCTP_INFO) seems to be > > returning the 'num_ostreams' set by setsockopt(SCTP_INIT) > > rather than the smaller of that value and that configured > > at the other end of the connection. > > > > I'll do a bit of digging. > > I can't find the code that processes the init_ack. > But when sctp_procss_int() saves the smaller value > in asoc->c.sinint_max_ostreams. > > But afe899962ee079 (if I've typed it right) changed > the values SCTP_INFO reported. > Apparantly adding 'sctp reconfig' had changed things. > > So I suspect this has all been broken for over 3 years. It looks like the changes that broke it went into 4.11. I've just checked a 3.8 kernel and that negotiates the values down in both directions. I don't have any kernels lurking between 3.8 and 4.15. (Yes, I could build one, but it doesn't really help.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Powered by blists - more mailing lists