diff --git a/xen.spec b/xen.spec
index f29da28..57f2fa7 100644
--- a/xen.spec
+++ b/xen.spec
@@ -50,7 +50,7 @@
 Summary: Xen is a virtual machine monitor
 Name:    xen
 Version: 4.8.2
-Release: 4%{?dist}
+Release: 5%{?dist}
 Group:   Development/Libraries
 License: GPLv2+ and LGPLv2+ and BSD
 URL:     http://xen.org/
@@ -158,6 +158,7 @@ Patch114: xsa241-4.8.patch
 Patch115: xsa242-4.9.patch
 Patch116: xsa243-4.8.patch
 Patch117: xsa244.patch
+Patch118: xsa236-4.9.patch
 
 
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
@@ -379,6 +380,7 @@ manage Xen virtual machines.
 %patch115 -p1
 %patch116 -p1
 %patch117 -p1
+%patch118 -p1
 
 # qemu-xen-traditional patches
 pushd tools/qemu-xen-traditional
@@ -930,6 +932,10 @@ rm -rf %{buildroot}
 %endif
 
 %changelog
+* Thu Oct 26 2017 Michael Young <m.a.young@durham.ac.uk> - 4.8.2-5
+- pin count / page reference race in grant table code [XSA-236, CVE-2017-15597]
+	(#1506693)
+
 * Thu Oct 12 2017 Michael Young <m.a.young@durham.ac.uk> - 4.8.2-4
 - xen: various flaws (#1501391)
   multiple MSI mapping issues on x86 [XSA-237, CVE-2017-15590]
diff --git a/xsa236-4.9.patch b/xsa236-4.9.patch
new file mode 100644
index 0000000..203025d
--- /dev/null
+++ b/xsa236-4.9.patch
@@ -0,0 +1,66 @@
+From: Jan Beulich <jbeulich@suse.com>
+Subject: gnttab: fix pin count / page reference race
+
+Dropping page references before decrementing pin counts is a bad idea
+if assumptions are being made that a non-zero pin count implies a valid
+page. Fix the order of operations in gnttab_copy_release_buf(), but at
+the same time also remove the assertion that was found to trigger:
+map_grant_ref() also has the potential of causing a race here, and
+changing the order of operations there would likely be quite a bit more
+involved.
+
+This is XSA-236.
+
+Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
+
+--- a/xen/common/grant_table.c
++++ b/xen/common/grant_table.c
+@@ -2330,9 +2330,20 @@ __acquire_grant_for_copy(
+         td = page_get_owner_and_reference(*page);
+         /*
+          * act->pin being non-zero should guarantee the page to have a
+-         * non-zero refcount and hence a valid owner.
++         * non-zero refcount and hence a valid owner (matching the one on
++         * record), with one exception: If the owning domain is dying we
++         * had better not make implications from pin count (map_grant_ref()
++         * updates pin counts before obtaining page references, for
++         * example).
+          */
+-        ASSERT(td);
++        if ( td != rd || rd->is_dying )
++        {
++            if ( td )
++                put_page(*page);
++            *page = NULL;
++            rc = GNTST_bad_domain;
++            goto unlock_out_clear;
++        }
+     }
+ 
+     act->pin += readonly ? GNTPIN_hstr_inc : GNTPIN_hstw_inc;
+@@ -2451,6 +2462,11 @@ static void gnttab_copy_release_buf(stru
+         unmap_domain_page(buf->virt);
+         buf->virt = NULL;
+     }
++    if ( buf->have_grant )
++    {
++        __release_grant_for_copy(buf->domain, buf->ptr.u.ref, buf->read_only);
++        buf->have_grant = 0;
++    }
+     if ( buf->have_type )
+     {
+         put_page_type(buf->page);
+@@ -2461,11 +2477,6 @@ static void gnttab_copy_release_buf(stru
+         put_page(buf->page);
+         buf->page = NULL;
+     }
+-    if ( buf->have_grant )
+-    {
+-        __release_grant_for_copy(buf->domain, buf->ptr.u.ref, buf->read_only);
+-        buf->have_grant = 0;
+-    }
+ }
+ 
+ static int gnttab_copy_claim_buf(const struct gnttab_copy *op,