On Sunday, June 28 2020, Craig Small wrote: > On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack <andr...@canonical.com> > wrote: > >> we are not happy yet with those commits because they change a struct >> without bumping the soname. We are investigating how impactful that is. >> > > Hi, > Did you see how bad these patches are with the API change? Generally if > the API is doing things like mystruct_new() and mystruct_free() its > probably ok but malloc(struct mystruct) will be a problem because the > binary will have one idea of the size and the library another. It also > depends if they are using accessor functions to get values or directly > pulling them out of the struct. > > I'm concerned that if the binary has one idea of the struct and the library > has another we are going to get some very bad corruption going on between > them.
Yeah, I did investigate that. You can see some of my findings here: https://github.com/net-snmp/net-snmp/commit/39381c4d2#commitcomment-40180748 In an perfect world, a user would not be accessing the struct fields directly. However, we can never guarantee that 100%, because the whole definition of struct used to be exported. Upstream has changed that recently (and introduced another API breakage, FWIW). I think the important piece of information here is that upstream bit the bullet and bumped the soname recently: https://github.com/net-snmp/net-snmp/commit/a0932b73ea0851308ca3e797caa600192cc3508a But we have to decide what to do with the version we're carrying on Debian. Arguably, it is really unlikely that a user will be using this struct in a program. And a quick search on sources.d.o tells us that net-snmp is the only package in the archive that uses this struct: https://codesearch.debian.net/search?q=usmStateReference So we could do like Fedora did and ignore that the ABI has been broken, since there are no apparent packages that will be affected. In this case, the set of patches I backported from upstream is enough to address the CVE. This is probably what Ubuntu will do as well, FWIW. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
signature.asc
Description: PGP signature
