Debian Patches

Status for slirp/1:1.0.17-11

Patch Description Author Forwarded Bugs Origin Last update
006-changelog-1.0.17.patch Add 1.0.17 upstream changelog Roberto Lumbreras <rover@debian.org> no
007-debian-changes.patch Debian building changes Roberto Lumbreras <rover@debian.org> no
005-use-snprintf.patch Use snprintf instead of sprintf Roberto Lumbreras <rover@debian.org> no
001-update-man-fix-hyphens-as-minus.patch fix hyphens used instead of minus signs and update manpage Roberto Lumbreras <rover@debian.org> no
002-fix-arguements.patch fix arguements spelling error Roberto Lumbreras <rover@debian.org> no
003-socklen_t.patch Use addrlen as socklen_t instead of int Roberto Lumbreras <rover@debian.org> no
004-compilation-warnings.patch Fix compilation warnings Roberto Lumbreras <rover@debian.org> no
008-slirp-amd64-log-crash.patch Fix crash on amd64 when enabling file logging On amd64 architectures, slirp crashes immediately when file logging is
enabled with "log start". It happens at the first call to lprint after the
log file is opened and ready for logging. The reason is that the va_list
object "args" is used twice in that case, once at
lprint_ptr += (*lprint_print)(*lprint_arg, format, args);
and once at
vfprintf(lfd, bptr2, args);
.
After the first call, args gets invalid because all arguments have been
read from the va_args structure. For some reason, this does not happen on
i386 versions. Maybe a real copy of args is created when the function is
called in i386.		 Alexander Block <ablock84@gmail.com> no debian
009-i-hate-perl.patch Do not run MAKEPRO anymore mkpro is a nice perl script that used to regenerate all slirp prototypes
correctly in the past. It stopped working, maybe because a change in perl
and/or because it has a bug. I'm not a perl guru, and after wasting hours
of my time trying to decypher mkrpo and fixing that silly thing, I quit.
Slirp hasn't changed for years, so I think mkpro isn't very useful anyway.
.

===================================================================		 Roberto Lumbreras <rover@debian.org> no debian
010-fullbolt-fix.patch please apply "real full bolt" patch Even when compiled with "-DFULL_BOLT", slirp applies a small delay to
TCP ACKs, which results in the upload speed being capped to circa 46Kb/s.
Manfread Haertel published a tiny patch for this on the UML mailing list:
http://article.gmane.org/gmane.linux.uml.user/13973
.

===================================================================		 Manfred Haertel <Manfred.Haertel <at> rz-online.de> no debian
011-sizeof_ipv4.patch IPCP negotiation fails for 64-bit hosts Due to incorrect use of "sizeof(long)" in src/ppp/ipcp.c, a 64-bit host
may send back incorrect IPCP NAKs in response to a client sending an IPCP
configure request that includes DNS/WINS options.
The NAK response offers an incorrect IP address and no DNS IPs, which
eventually causes negotiation to fail.
Proposed solution is to change "sizeof (long)" to "sizeof (u_int32_t)" to
correctly match the length of IPV4 addresses.
.

===================================================================		 Tueidj Traden <tueidj <at> hotmail.com> no debian
012_ipq64.patch fix crashes at startup in 64bit systems Due to the use of 32bit pointers slirp crashes at startup
.
Thanks to Fernando Toledo for the fix: http://bugs.debian.org/922323

===================================================================		 Roberto Lumbreras <rover@debian.org> no debian
013_hurd.patch make it compile on GNU Hurd Quick and dirty fix to make it compile on GNU Hurd.
.

===================================================================		 Roberto Lumbreras <rover@debian.org> no
014_CVE-2020-7039.patch CVE-2020-7039 fix .
tcp_emu: Fix oob access
https://gitlab.freedesktop.org/slirp/libslirp/commit/2655fffed7a9e765bcb4701dd876e9dab975f289
The main loop only checks for one available byte, while we sometimes need two bytes.
.
slirp: use correct size while emulating IRC commands
https://gitlab.freedesktop.org/slirp/libslirp/commit/ce131029d6d4a405cb7d3ac6716d03e58fb4a5d9
While emulating IRC DCC commands, tcp_emu() uses 'mbuf' size
'm->m_size' to write DCC commands via snprintf(3). This may
lead to OOB write access, because 'bptr' points somewhere in
the middle of 'mbuf' buffer, not at the start. Use M_FREEROOM(m)
size to avoid OOB access.
Reported-by: default avatarVishnu Dev TJ <vishnudevtj@gmail.com>
Signed-off-by: default avatarPrasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
Message-Id: <20200109094228.79764-2-ppandit@redhat.com>
.
slirp: use correct size while emulating commands
https://gitlab.freedesktop.org/slirp/libslirp/commit/82ebe9c370a0e2970fb5695aa19aa5214a6a1c80
While emulating services in tcp_emu(), it uses 'mbuf' size
'm->m_size' to write commands via snprintf(3). Use M_FREEROOM(m)
size to avoid possible OOB access.
Signed-off-by: default avatarPrasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
Message-Id: <20200109094228.79764-3-ppandit@redhat.com>
.

===================================================================		 Roberto Lumbreras <rover@debian.org> no
015_949003_explicit_extern_declaration.patch 949003

===================================================================		 Bernhard Übelacker <bernhardu@mailbox.org> no debian 2020-09-02
016_c11b4078042_fix_64_bit_issue_in_slirp.patch Fix 64 bit issue in slirp

===================================================================		 no debian https://gitlab.freedesktop.org/slirp/libslirp/-/commit/c11b407804272b71e5bdd7a2a9181c64c7a594ed 2020-09-02
017_CVE-2020-8608.patch patch for CVE-2020-8608=================================================================== no

All known versions for source package 'slirp'

Links