Patchwork [Hardy-xen] SRU: Fix potential resource leak

login
register
mail settings
Submitter Stefan Bader
Date June 22, 2011, 2:52 p.m.
Message ID <4E020194.6000804@canonical.com>
Download mbox | patch
Permalink /patch/101497/
State New
Headers show

Comments

Stefan Bader - June 22, 2011, 2:52 p.m.
On 21.06.2011 17:41, Stefan Bader wrote:
> I think it is not released yet, but I gave it its own bug anyway. Though it is
> sort of a follow up for CVE-2010-4247.
> Attaching the actual patch not the patch as it would get added to the xen
> patches as it is much simpler to look at.
> 
> SRU Justification:
> 
> Impact: This only affects the xen custom kernel. When applying patches to fix
> CVE-2010-4247, a follow-up patch was missed that would fix a potention leak.
> This will only happen in the error case when the loop is prematurely ended.
> 
> Fix: Patch taken from Xen repository.
> 
> Testcase: none, found by code review and not sure how to trigger the error case
> the first place.
> 

In case it was missed or assumed to be the other issue... And this time
attaching the patch against the tree.

-Stefan

Patch

From 62cc36822cdfbbe79e5244d2f6f832c0a582be82 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Wed, 22 Jun 2011 16:37:23 +0200
Subject: [PATCH] xen: blkback, blktap: Fix potential resource leak

When picking up the changes for CVE-2010-4247 I missed that there
actually is a follow-up patch (that was not mentioned in the CVE)
which prevents resource leak in that special case.

Signed-off-by: Keir Fraser <keir.fraser@citrix.com>

BugLink: http://bugs.launchpad.net/bugs/800254

(picked from http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/5012c470f875)
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 ...lkback-blktap-Fix-potential-resource-leak.patch |   69 ++++++++++++++++++++
 1 files changed, 69 insertions(+), 0 deletions(-)
 create mode 100644 debian/binary-custom.d/xen/patchset/025-xen-blkback-blktap-Fix-potential-resource-leak.patch

diff --git a/debian/binary-custom.d/xen/patchset/025-xen-blkback-blktap-Fix-potential-resource-leak.patch b/debian/binary-custom.d/xen/patchset/025-xen-blkback-blktap-Fix-potential-resource-leak.patch
new file mode 100644
index 0000000..14d97cc
--- /dev/null
+++ b/debian/binary-custom.d/xen/patchset/025-xen-blkback-blktap-Fix-potential-resource-leak.patch
@@ -0,0 +1,69 @@ 
+From dc547726170fff96567d5899a1222400137b753f Mon Sep 17 00:00:00 2001
+From: Stefan Bader <stefan.bader@canonical.com>
+Date: Tue, 21 Jun 2011 17:20:27 +0200
+Subject: [PATCH] xen: blkback, blktap: Fix potential resource leak
+
+When picking up the changes for CVE-2010-4247 I missed that there
+actually is a follow-up patch (that was not mentioned in the CVE)
+which prevents resource leak in that special case.
+
+Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
+
+BugLink: http://bugs.launchpad.net/bugs/800254
+
+(picked from http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/5012c470f875)
+Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
+---
+ drivers/xen/blkback/blkback.c |    8 ++++----
+ drivers/xen/blktap/blktap.c   |    8 ++++----
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/xen/blkback/blkback.c b/drivers/xen/blkback/blkback.c
+index afd68ed..6787d0d 100644
+--- a/drivers/xen/blkback/blkback.c
++++ b/drivers/xen/blkback/blkback.c
+@@ -314,14 +314,14 @@ static int do_block_io_op(blkif_t *blkif)
+ 		if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
+ 			break;
+ 
+-		pending_req = alloc_req();
+-		if (NULL == pending_req) {
+-			blkif->st_oo_req++;
++		if (kthread_should_stop()) {
+ 			more_to_do = 1;
+ 			break;
+ 		}
+ 
+-		if (kthread_should_stop()) {
++		pending_req = alloc_req();
++		if (NULL == pending_req) {
++			blkif->st_oo_req++;
+ 			more_to_do = 1;
+ 			break;
+ 		}
+diff --git a/drivers/xen/blktap/blktap.c b/drivers/xen/blktap/blktap.c
+index bde14f5..0da7fe4 100644
+--- a/drivers/xen/blktap/blktap.c
++++ b/drivers/xen/blktap/blktap.c
+@@ -1237,14 +1237,14 @@ static int do_block_io_op(blkif_t *blkif)
+ 			break;		
+ 		}
+ 
+-		pending_req = alloc_req();
+-		if (NULL == pending_req) {
+-			blkif->st_oo_req++;
++		if (kthread_should_stop()) {
+ 			more_to_do = 1;
+ 			break;
+ 		}
+ 
+-		if (kthread_should_stop()) {
++		pending_req = alloc_req();
++		if (NULL == pending_req) {
++			blkif->st_oo_req++;
+ 			more_to_do = 1;
+ 			break;
+ 		}
+-- 
+1.7.4.1
+
-- 
1.7.4.1