Patchwork Hardy SRU, xen unified block-device I/O interface back end can orphan devices, CVE-2010-3699

login
register
mail settings
Submitter Tim Gardner
Date Jan. 27, 2011, 4:43 p.m.
Message ID <4D41A09D.8090307@canonical.com>
Download mbox
Permalink /patch/80714/
State Accepted
Delegated to: Stefan Bader
Headers show

Pull-request

git://kernel.ubuntu.com/rtg/ubuntu-hardy.git CVE-2010-3699

Comments

Tim Gardner - Jan. 27, 2011, 4:43 p.m.
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
Stefan Bader - Jan. 27, 2011, 5:26 p.m.
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>
John Johansen - Jan. 27, 2011, 6:24 p.m.
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>