[ Reason ]
There's a (low-impact?) security issue found in libslirp,
which is CVE-2026-9539 (OOB heap read). This debian release
includes patch from upstream which fixes this issue.
[ Tests ]
I verified basic qemu functionality with libslirp, - there's
no visible difference. I didn't especially try to use the code
paths being fixed, though.
This code is used for quite some time in sid and testing and by
other users of libslirp, - it's been fixed 2 versions ago - with
no problems.
[ Risks ]
This is a low-risk update. The code in question is about rarely used
feature, and libslirp (qemu user-mode networking) is a rarely used
networking too. And the change looks fine.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
There are 2 changes: a change for d/gbp.conf (switching to debian/trixie
branch) and the upstream patch fixing the issue in question, quite small.
[ Additional Info ]
I'm uploading the new release to the archive, to save a round-trip -
hopefully it's okay.
Thanks,
/mjt
diff -Nru libslirp-4.8.0/debian/changelog libslirp-4.8.0/debian/changelog
--- libslirp-4.8.0/debian/changelog 2024-06-16 18:17:55.000000000 +0300
+++ libslirp-4.8.0/debian/changelog 2026-06-26 19:13:32.000000000 +0300
@@ -1,3 +1,12 @@
+libslirp (4.8.0-1+deb13u1) trixie; urgency=medium
+
+ * d/gbp.conf: switch to debian/trixie branch
+ * oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch
+ patch from upstream to fix CVE-2026-9539 (oob heap read and integer
+ underflow allowing reading sensitive host-process memory)
+
+ -- Michael Tokarev <mjt@tls.msk.ru> Fri, 26 Jun 2026 19:13:32 +0300
+
libslirp (4.8.0-1) unstable; urgency=medium
[ Michael Tokarev ]
diff -Nru libslirp-4.8.0/debian/gbp.conf libslirp-4.8.0/debian/gbp.conf
--- libslirp-4.8.0/debian/gbp.conf 2023-04-23 09:28:04.000000000 +0300
+++ libslirp-4.8.0/debian/gbp.conf 2026-06-26 19:11:38.000000000 +0300
@@ -1,2 +1,3 @@
[DEFAULT]
upstream-vcs-tag = v%(version)s
+debian-branch = debian/trixie
diff -Nru libslirp-4.8.0/debian/patches/oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch libslirp-4.8.0/debian/patches/oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch
--- libslirp-4.8.0/debian/patches/oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch 1970-01-01 03:00:00.000000000 +0300
+++ libslirp-4.8.0/debian/patches/oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch 2026-06-26 19:11:38.000000000 +0300
@@ -0,0 +1,123 @@
+From: Samuel Thibault <samuel.thibault@ens-lyon.org>
+Date: Sat, 23 May 2026 22:06:59 +0200
+Subject: oob: cap urgent data count to what is actually available
+Origin: upstream, https://gitlab.freedesktop.org/slirp/libslirp/-/commit/927bca7344e31fd58e2f7afaca784aad4400eb84
+Forwarded: not-needed
+Bug: https://gitlab.freedesktop.org/slirp/libslirp/-/work_items/93
+
+so_urgc is provided by the guest sender, so can arbitrary and beyond
+what we actually have. Worse, this can lead to an sb_cc integer
+underflow leading to leaking gigabytes of data.
+
+Fixes #93
+
+Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
+---
+ src/socket.c | 40 +++++++++++++++++++++++-----------------
+ 1 file changed, 23 insertions(+), 17 deletions(-)
+
+diff --git a/src/socket.c b/src/socket.c
+index 77c5cf6..c491d0f 100644
+--- a/src/socket.c
++++ b/src/socket.c
+@@ -339,7 +339,8 @@ int sorecvoob(struct socket *so)
+ int sosendoob(struct socket *so)
+ {
+ struct sbuf *sb = &so->so_rcv;
+- char buff[2048]; /* XXX Shouldn't be sending more oob data than this */
++ uint32_t urgc = so->so_urgc;
++ char buff[2048];
+
+ int n;
+
+@@ -347,12 +348,15 @@ int sosendoob(struct socket *so)
+ DEBUG_ARG("so = %p", so);
+ DEBUG_ARG("sb->sb_cc = %d", sb->sb_cc);
+
+- if (so->so_urgc > sizeof(buff))
+- so->so_urgc = sizeof(buff); /* XXXX */
++ if (urgc > sizeof(buff))
++ urgc = sizeof(buff);
++
++ if (urgc > sb->sb_cc)
++ urgc = sb->sb_cc;
+
+ if (sb->sb_rptr < sb->sb_wptr) {
+ /* We can send it directly */
+- n = slirp_send(so, sb->sb_rptr, so->so_urgc,
++ n = slirp_send(so, sb->sb_rptr, urgc,
+ (MSG_OOB)); /* |MSG_DONTWAIT)); */
+ } else {
+ /*
+@@ -360,7 +364,6 @@ int sosendoob(struct socket *so)
+ * we must copy all data to a linear buffer then
+ * send it all
+ */
+- uint32_t urgc = so->so_urgc; /* Amount of room left in buff */
+ int len = (sb->sb_data + sb->sb_datalen) - sb->sb_rptr;
+ if (len > urgc) {
+ len = urgc;
+@@ -405,7 +408,7 @@ int sosendoob(struct socket *so)
+ */
+ int sowrite(struct socket *so)
+ {
+- int n, nn;
++ int n, nn, noob = 0;
+ struct sbuf *sb = &so->so_rcv;
+ int len = sb->sb_cc;
+ struct iovec iov[2];
+@@ -415,16 +418,20 @@ int sowrite(struct socket *so)
+
+ if (so->so_urgc) {
+ uint32_t expected = so->so_urgc;
+- if (sosendoob(so) < expected) {
+- /* Treat a short write as a fatal error too,
+- * rather than continuing on and sending the urgent
+- * data as if it were non-urgent and leaving the
+- * so_urgc count wrong.
+- */
++ int noob = sosendoob(so);
++
++ if (noob <= 0)
+ goto err_disconnected;
+- }
++
++ if (noob < expected)
++ /* Short write: either we have not yet received all
++ * urgent data, or the socket buffers are full. Leave
++ * it for later when we have data or have room. */
++ return noob;
++
+ if (sb->sb_cc == 0)
+- return 0;
++ /* Nothing left to write actually */
++ return noob;
+ }
+
+ /*
+@@ -455,12 +462,11 @@ int sowrite(struct socket *so)
+ } else
+ n = 1;
+ }
+- /* Check if there's urgent data to send, and if so, send it */
+
+ nn = slirp_send(so, iov[0].iov_base, iov[0].iov_len, 0);
+ /* This should never happen, but people tell me it does *shrug* */
+ if (nn < 0 && (errno == EAGAIN || errno == EINTR))
+- return 0;
++ return noob;
+
+ if (nn <= 0) {
+ goto err_disconnected;
+@@ -487,7 +493,7 @@ int sowrite(struct socket *so)
+ if ((so->so_state & SS_FWDRAIN) && sb->sb_cc == 0)
+ sofcantsendmore(so);
+
+- return nn;
++ return noob + nn;
+
+ err_disconnected:
+ DEBUG_MISC(" --- sowrite disconnected, so->so_state = %x, errno = %d",
+--
+2.47.3
+
diff -Nru libslirp-4.8.0/debian/patches/series libslirp-4.8.0/debian/patches/series
--- libslirp-4.8.0/debian/patches/series 2023-04-23 09:28:04.000000000 +0300
+++ libslirp-4.8.0/debian/patches/series 2026-06-26 19:11:38.000000000 +0300
@@ -0,0 +1 @@
+oob-cap-urgent-data-to-what-is-available-CVE-2026-9539.patch