diff --git a/gnu/local.mk b/gnu/local.mk
index 1d9de9a57e..2f24f892b1 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1053,6 +1053,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/guile-3.0-relocatable.patch		\
   %D%/packages/patches/guile-linux-syscalls.patch		\
   %D%/packages/patches/guile-3.0-linux-syscalls.patch		\
+  %D%/packages/patches/guile-fibers-destroy-peer-schedulers.patch \
   %D%/packages/patches/guile-gdbm-ffi-support-gdbm-1.14.patch	\
   %D%/packages/patches/guile-present-coding.patch		\
   %D%/packages/patches/guile-rsvg-pkgconfig.patch		\
diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 674b1f922b..a1deee32d1 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -523,7 +523,10 @@ (define-public guile-fibers
                     (("#:use-module \\(fibers\\)")
                      (string-append "#:use-module (fibers)\n"
                                     "#:use-module (ice-9 threads)\n")))
-                  #t))))
+                  #t))
+              (patches
+               ;; fixes a resource leak that causes crashes in the tests
+               (search-patches "guile-fibers-destroy-peer-schedulers.patch"))))
     (build-system gnu-build-system)
     (arguments
      '(;; The code uses 'scm_t_uint64' et al., which are deprecated in 3.0.
diff --git a/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch b/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch
new file mode 100644
index 0000000000..8bb7153153
--- /dev/null
+++ b/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch
@@ -0,0 +1,24 @@
+Fibers 1.0.0 has a bug in run-fibers in which peer schedulers aren't destroyed -
+so if you had 4 cores, 1 would be destroyed when run-fibers returned, but the
+other 3 would stay around.  Each scheduler uses 3 file descriptors, so for
+machines with many cores, this resource leak adds up quickly - quickly enough
+that the test suite can even fail because of it.
+
+See https://github.com/wingo/fibers/issues/36.
+
+This fixes that.  It should be safe to destroy the peer schedulers at the given
+point because the threads that could be running them are all either dead or the
+current thread.
+
+As of May 21, 2020, this bug still existed in the 1.0.0 (latest) release and in
+git master.
+--- a/fibers.scm	2020-05-21 18:38:06.890690154 -0500
++++ b/fibers.scm	2020-05-21 18:38:56.395686693 -0500
+@@ -137,5 +137,6 @@
+              (%run-fibers scheduler hz finished? affinity))
+            (lambda ()
+              (stop-auxiliary-threads scheduler)))))
++      (for-each destroy-scheduler (scheduler-remote-peers scheduler))
+       (destroy-scheduler scheduler)
+       (apply values (atomic-box-ref ret))))))
+