Hardy SRU, xen unified block-device I/O interface back end can orphan devices, CVE-2010-3699
Re-pushed with a proper BugLink in the commit message.
--
Tim Gardner tim.gardner@canonical.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
01-27-2011, 03:43 PM
Tim Gardner
Hardy SRU, xen unified block-device I/O interface back end can orphan devices, CVE-2010-3699
This is a multi-part message in MIME format.Here is the patch which I believe addresses the resource
allocation/deallocation issue of concern in CVE-2010-3699. I've attached
the pull request and native patch. Given the nature of Hardy custom
binary patches, I've also attached the flattened patch which is a bit
easier to read. If you're still having problems groking the changes,
then you can prepare a flattened xen tree thusly:
The flattened tree will be in debian/build/custom-source-xen
I was never able to definitively reproduce the vulnerability. I suspect
it requires environments with more block and network devices than I am
able to reproduce. However, I've instrumented a debug version of this
patch and have verified that all affected code paths have been
exercized. Therefore I believe that I have at least not introduced any
regressions.
rtg
--
Tim Gardner tim.gardner@canonical.com
The following changes since commit 54233a263fa24dbf2677e8d8d6a42733428b7af7:
Dan Rosenberg (1):
V4L/DVB: ivtvfb: prevent reading uninitialized stack memory, CVE-2010-4079
Hardy SRU, xen unified block-device I/O interface back end can orphan devices, CVE-2010-3699
On 01/27/2011 05:43 PM, Tim Gardner wrote:
> Here is the patch which I believe addresses the resource allocation/deallocation
> issue of concern in CVE-2010-3699. I've attached the pull request and native
> patch. Given the nature of Hardy custom binary patches, I've also attached the
> flattened patch which is a bit easier to read. If you're still having problems
> groking the changes, then you can prepare a flattened xen tree thusly:
>
> git clone git://kernel.ubuntu.com/rtg/ubuntu-hardy.git
> cd ubuntu-hardy
> git checkout -b CVE-2010-3699 remotes/origin/CVE-2010-3699
> fakeroot debian/rules clean custom-prepare-xen
>
> The flattened tree will be in debian/build/custom-source-xen
>
> I was never able to definitively reproduce the vulnerability. I suspect it
> requires environments with more block and network devices than I am able to
> reproduce. However, I've instrumented a debug version of this patch and have
> verified that all affected code paths have been exercized. Therefore I believe
> that I have at least not introduced any regressions.
>
> rtg
>
Seems to be functionally exactly the same as the version I played around with
and after getting rid of xen-3.3 I feel comfortable with it not regressing too.
Acked-by: Stefan Bader <stefan.bader@canonical.com>
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
01-27-2011, 05:24 PM
John Johansen
Hardy SRU, xen unified block-device I/O interface back end can orphan devices, CVE-2010-3699
On 01/27/2011 08:43 AM, Tim Gardner wrote:
> Here is the patch which I believe addresses the resource allocation/deallocation issue of concern in CVE-2010-3699. I've attached the pull request and native patch. Given the nature of Hardy custom binary patches, I've also attached the flattened patch which is a bit easier to read. If you're still having problems groking the changes, then you can prepare a flattened xen tree thusly:
>
> git clone git://kernel.ubuntu.com/rtg/ubuntu-hardy.git
> cd ubuntu-hardy
> git checkout -b CVE-2010-3699 remotes/origin/CVE-2010-3699
> fakeroot debian/rules clean custom-prepare-xen
>
> The flattened tree will be in debian/build/custom-source-xen
>
> I was never able to definitively reproduce the vulnerability. I suspect it requires environments with more block and network devices than I am able to reproduce. However, I've instrumented a debug version of this patch and have verified that all affected code paths have been exercized. Therefore I believe that I have at least not introduced any regressions.
>
well I need to do a reinstall of my xen box so I haven't tested this yet, but I
suspect it will turn out the same as Stephan's testing.
I've run through checking against the original patch, and it looks good to me.
I don't see this regressing, so
Acked-by: John Johansen <john.johansen@canonical.com>
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team