#1115497 Memory leak in mdadm --monitor --scan

Package:
mdadm
Source:
mdadm
Description:
Tool to administer Linux MD arrays (software RAID)
Submitter:
Peter Mann
Date:
2026-06-22 15:57:01 UTC
Severity:
normal
#1115497#5
Date:
2025-09-17 15:03:39 UTC
From:
To:
We noticed a memory leak in mdmonitor.service on all of our newly installed trixie machines.
The worst case machine accumulated about 20GB of leaks in 13 days of uptime.

After some debugging we found the issue.
At mdadm-4.4/udev.c:153 (fetched using apt source):
...
if (udev_monitor_receive_device(udev_monitor))
	return UDEV_STATUS_SUCCESS; /* event detected */
...

According to libudev docs:
On success, udev_monitor_receive_device() returns a pointer to a newly referenced device that was received via the monitor. The caller is responsible to drop this reference when done.

As you can see, the reference to the device never gets dropped.
We put together a quick patch, which seems to have fixed the issue or at least substantially reduced the amount of leaks.

Since we have no experience with the codebase, we have no idea about the implications of these changes.
We would appreciate if someone took a closer look.

Additionaly as a workaround, passing MDADM_NO_UDEV=1 env to mdadm stops the leaks as well, since it bypasses the leaking codepath.
--- udev.old.c	2025-01-14 13:13:50.000000000 +0100
+++ udev.c	2025-09-17 15:42:15.932836197 +0200
@@ -149,9 +149,13 @@
 	tv.tv_sec = seconds;
 	tv.tv_usec = 0;

-	if (select(fd + 1, &readfds, NULL, NULL, &tv) > 0 && FD_ISSET(fd, &readfds))
-		if (udev_monitor_receive_device(udev_monitor))
+	if (select(fd + 1, &readfds, NULL, NULL, &tv) > 0 && FD_ISSET(fd, &readfds)) {
+		struct udev_device *dev = udev_monitor_receive_device(udev_monitor);
+		if (dev) {
+			udev_device_unref(dev);
 			return UDEV_STATUS_SUCCESS; /* event detected */
+		}
+	}
 	return UDEV_STATUS_TIMEOUT;
 }
 #endif

#1115497#10
Date:
2025-09-18 13:12:08 UTC
From:
To:
Hi Peter,

nice for spotting this, thanks!

applied and looks good for now, but would you mind reporting it upstream
at https://github.com/md-raid-utilities/mdadm/issues

Regards,
Daniel

#1115497#15
Date:
2025-09-18 13:36:28 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
mdadm, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1115497@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Baumann <daniel@debian.org> (supplier of updated mdadm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 18 Sep 2025 15:20:58 +0200
Source: mdadm
Architecture: source
Version: 4.4-13
Distribution: sid
Urgency: medium
Maintainer: Daniel Baumann <daniel@debian.org>
Changed-By: Daniel Baumann <daniel@debian.org>
Closes: 1112392 1114744 1114858 1115497
Changes:
 mdadm (4.4-13) sid; urgency=medium
 .
   * Adding patch from QRPp <awesome.walrus+github@gmail.com> to fix fails
     with with relative ARRAY devnames (Closes: #1114744).
   * Adding patch from Peter Mann <peter.mann@sh.cz> to fix memory leak in
     mdadm --monitor --scan (Closes: #1115497).
   * Adding updated Italian debconf translations from Luca Monducci
     <luca.mo@tiscali.it> (Closes: #1114858).
   * Removing in initramfs hook a reference to old documentation file
     removed by upstream, thanks to Lionel Elie Mamane <lionel@mamane.lu>
     (Closes: #1112392).
Checksums-Sha1:
 1e9bcfec3d0240b85cd0c8e076aca3511999219f 1356 mdadm_4.4-13.dsc
 450628e1b63dbf26d84042ca532c264d961c3197 89828 mdadm_4.4-13.debian.tar.xz
 ff61ee3a301d00381d031cca2a801b72034ebc4c 5586 mdadm_4.4-13_amd64.buildinfo
Checksums-Sha256:
 229ddf4567add9a3b87efb96a064f1884186c8c51b1e230fe0aff1180ff60006 1356 mdadm_4.4-13.dsc
 5de6dee55b6489cfabc9d2be9547d44bd5a644e42f4e8ede4ec6cff83706b4ed 89828 mdadm_4.4-13.debian.tar.xz
 98bc78548bbb8c3070bad1756dcfd021ba7f54c0cd8b2f1e2abd85e62185d0b4 5586 mdadm_4.4-13_amd64.buildinfo
Files:
 89b93a3d9d9bdd45ed34956c348eb223 1356 admin optional mdadm_4.4-13.dsc
 b5281f7c4de68768d8226720d663e445 89828 admin optional mdadm_4.4-13.debian.tar.xz
 a7bcb51c019a3afd367804981b15584d 5586 admin optional mdadm_4.4-13_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQmmGg4gLaoSj0ERgL7tPDoCoAiLwUCaMwH3gAKCRD7tPDoCoAi
L2JuAQDQtH9xJlZdqEzIZ91Wl/9Rbv/6fti3ahN+Ej3I6JIZtQEA+behtMSf3OBK
LPwsqVBYJ3BgMW7ZIlZOfk45M6WrRwU=
=wnVg
-----END PGP SIGNATURE-----

#1115497#20
Date:
2025-09-18 13:50:17 UTC
From:
To:
Hello Daniel,

Thank you for the quick response.

Reported upstream:
https://github.com/md-raid-utilities/mdadm/issues/195

Regards,
Peter Mann

#1115497#25
Date:
2025-09-18 14:25:41 UTC
From:
To:
great, thanks.

once it's merged upstream I'll propose this (and a few other fixes) to
be accepted for the next trixie point-release.

Regards,
Daniel

#1115497#34
Date:
2026-06-22 15:55:48 UTC
From:
To:
Hello,

We are seeing mdmonitor eat a lot of memory, we have to restart it now
and then, which fits this bug description.

Daniel Baumann, le jeu. 18 sept. 2025 16:25:41 +0200, a ecrit:

Could this trixie-proposed-update be done?

Thanks,
Samuel