Backport CVEs from Upstream OE to Pyro


Relevant CVE's should be backported to pyro for our 9.0 Release

Validation Steps



Christopher Clark
July 18, 2019, 10:27 PM

I can’t find anything that uses the new {{bdwgc}} recipe that you’ve introduced a backport for – am I missing something?

Christopher Clark
July 19, 2019, 12:34 AM

{{gnulib}} in master of {{meta-oe}} has a more recent version than {{xenclient-oe}} that contains a fix for CVE-2018-17942.

Chris Rogers
July 19, 2019, 1:44 AM

I limited the CVEs I took to Critical level only to follow precedent and limit the scope to something achievable in the time we have before release. Since CVE-2019-9936 and CVE-2019-9937 for sqlite3 are only High, they were not included.

CVE-2018-17942 for gnulib wasn’t included since it wasnt Critical.

I found bdwgc to be compiled in my build tree; therefore I assumed something used it as a build dependency, but perhaps several layers deep. Since it had critical CVEs, it made my list for inclusion.


Christopher Clark
July 19, 2019, 5:39 PM

Thanks for the process statement - it does explain why the uprev’d components were not taken to the most recent available versions.

Was that precedent for only addressing a subset of CVEs for a release established for a prior OpenXT release?

If nss depends on sqlite3, and so the SSL and TLS implementation potentially stops working when sqlite3 is affected, might this mean the forward seal functionality is vulnerable to being disabled?

Re: bdwgc : from the latest builder logs, it looks like it’s being built as a native package, so will be a dependency from the build toolchain, so the upgrade does make sense.


Chris Rogers
July 22, 2019, 3:24 PM

I suppose it’s possible, and considering how nss and sqlite are involved in the forward sealing process, I think we can make an exception and bring in updates for those packages. Will have a PR up today.



Chris Rogers


Chris Rogers



QA Assignee


QA Image URL


Epic Link


Fix versions