diff --git a/SOURCES/xfsprogs-4.9.0-junk-attr-leaf-count-zero.patch b/SOURCES/xfsprogs-4.9.0-junk-attr-leaf-count-zero.patch
new file mode 100644
index 0000000..74f0590
--- /dev/null
+++ b/SOURCES/xfsprogs-4.9.0-junk-attr-leaf-count-zero.patch
@@ -0,0 +1,50 @@
+xfs_repair: junk leaf attribute if count == 0
+
+We have recently seen a case where, during log replay, the
+attr3 leaf verifier reported corruption when encountering a
+leaf attribute with a count of 0 in the header.
+
+We chalked this up to a transient state when a shortform leaf
+was created, the attribute didn't fit, and we promoted the
+(empty) attribute to the larger leaf form.
+
+I've recently been given a metadump of unknown provenance which actually
+contains a leaf attribute with count 0 on disk.  This causes the
+verifier to fire every time xfs_repair is run:
+
+ Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
+
+If this 0-count state is detected, we should just junk the leaf, same
+as we would do if the count was too high.  With this change, we now
+remedy the problem:
+
+ Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
+ bad attribute count 0 in attr block 0, inode 12587828
+ problem with attribute contents in inode 12587828
+ clearing inode 12587828 attributes
+ correcting nblocks for inode 12587828, was 2 - counted 1
+
+Signed-off-by: Eric Sandeen <sandeen@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+---
+
+diff --git a/repair/attr_repair.c b/repair/attr_repair.c
+index 40cb5f7..b855a10 100644
+--- a/repair/attr_repair.c
++++ b/repair/attr_repair.c
+@@ -593,7 +593,8 @@ process_leaf_attr_block(
+ 	stop = xfs_attr3_leaf_hdr_size(leaf);
+ 
+ 	/* does the count look sorta valid? */
+-	if (leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop >
++	if (!leafhdr.count ||
++	    leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop >
+ 						mp->m_sb.sb_blocksize) {
+ 		do_warn(
+ 	_("bad attribute count %d in attr block %u, inode %" PRIu64 "\n"),
+--
+To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
+
+
diff --git a/SPECS/xfsprogs.spec b/SPECS/xfsprogs.spec
index 0d8686c..8001d99 100644
--- a/SPECS/xfsprogs.spec
+++ b/SPECS/xfsprogs.spec
@@ -1,7 +1,7 @@
 Summary:	Utilities for managing the XFS filesystem
 Name:		xfsprogs
 Version:	4.5.0
-Release:	8%{?dist}
+Release:	9%{?dist}
 # Licensing based on generic "GNU GENERAL PUBLIC LICENSE"
 # in source, with no mention of version.
 # doc/COPYING file specifies what is GPL and what is LGPL
@@ -32,6 +32,7 @@ Patch8:		xfsprogs-4.7.0-fix-agf-limit-errors.patch
 Patch9:		xfsprogs-4.7.0-quota-fixes.patch
 Patch10:	xfsprogs-4.8.0-replace-ustat.patch
 Patch11:	xfsprogs-revert-off64_t.patch
+Patch12:	xfsprogs-4.9.0-junk-attr-leaf-count-zero.patch
 
 %description
 A set of commands to use the XFS filesystem, including mkfs.xfs.
@@ -74,6 +75,7 @@ also want to install xfsprogs.
 %patch9 -p1
 %patch10 -p1
 %patch11 -p1
+%patch12 -p1
 
 %build
 export tagname=CC
@@ -139,6 +141,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_libdir}/*.so
 
 %changelog
+* Fri Dec 16 2016 Eric Sandeen <sandeen@redhat.com> 4.5.0-9
+- xfs_repair: junk leaf attribute if count == 0 (#1402944)
+
 * Thu Sep 08 2016 Eric Sandeen <sandeen@redhat.com> 4.5.0-8
 - revert loff_t to off64_t change to preserve xfs.h behavior (#1366291)
 - accomodate lack of ustat() on some arches (#1373605)