Thoughts on Xen updates in LTS
I have recently begun working on updates to xen in jessie.
First a small bit of history. The most recent update to xen in jessie
was on 8th October 2019. The following morning, 9th October, it was
triaged back into dla-needed.txt because of still open vulnerabilities.
The package has lain unclaimed until earlier this week when I claimed
I began by doing some research, which led me to Credativ's xen-lts
GitHub project. The most recent release, 4.4.4lts5, corresponds to the
8th October 2019 update in jessie. There have been no further updates
since. My next step was to start working on the oldest open
vulnerability, CVE-2018-12207, according to the security tracker.
The advisories published by the Xen project only provide patches as far
back as version 4.8, making it necessary to backport the 4.8 patches to
the 4.4.4lts5 version which is the basis of the xen package in jessie.
After several hours of work on the patches for CVE-2018-12207, I have
been able to mostly adapt them to the 4.4.4lts5 code base. However, the
last few remaining bits will require a fair amount of effort to properly
integrate into the older code. The vulnerability seems quite severe; a
malicious guest OS kernel can exploit the vulnerability to trigger a
crash of the host (denial of service).
That said, XSA-304 (which is associated with CVE-2018-12207) lists three
possible mitigations for the vulnerability. Ordinarily we would attempt
to backport patches, which in this case is doable but still tedious, but
the presence of mitigations lets users close the vulnerability with a
I intend to look into at least one or two other open vulnerabilities to
gain a sense for how difficult the effort associated with those would
be. However, I would appreciate some thoughts/intput on the following
- How much effort should be devoted to backporting a particular set of
patches? (Raphael & Holger, your input would be most helpful here)
- Given the apparent difficulty of backporting so far, would it make
sense to "defualt" triaging to <no-dsa> or <ignored> when there are
one or more feasible workarounds or mitigations?
- Is there another approach to all of this that I seem to have missed?
- How should these changes be tested?
Roberto C. Sánchez