Your message dated Sat, 11 Jul 2026 10:32:47 +0000
with message-id <[email protected]>
and subject line Released in 13.6
has caused the Debian Bug report #1140797,
regarding trixie-pu: package libslirp/4.8.0-1+deb13u1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1140797: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140797
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: [email protected]
Control: affects -1 + src:libslirp
User: [email protected]
Usertags: pu
[ 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 <[email protected]> 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 <[email protected]>
+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 <[email protected]>
+---
+ 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
--- End Message ---
--- Begin Message ---
Version: 13.6
This update was released as part of 13.6.
--- End Message ---
