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 12:41:13 +0000 From: David Laight <David.Laight@...LAB.COM> To: David Laight <David.Laight@...LAB.COM>, "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: RE: 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. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Powered by blists - more mailing lists