Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
As the bug is now fixed upstream [1], can we get a patch for the current stable (bullseye)? Because it's impossible to have SSL on apache without the mod-gnutls I know maybe it's impossible to re-insert a removed package to stable, but, I beg the Debian people to let this package come back directly to stable, because it is pretty much needed. [1] https://lists.gnupg.org/pipermail/mod_gnutls-devel/2023-February/000221.html El dom, 5 jun 2022 a la(s) 15:04, Félix Arreola Rodríguez ( fgatuno@gmail.com) escribió: > Finally managed to write a patch. This patch applies ok on mod-gnutls > 0.9.0 and not sure if it will work for buster. > > -- > Atte. Félix Arreola > Firmado con GPG 0x1e249ee4 > -- Atte. Félix Arreola Rodríguez, «Sin firma GPG»
Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
Finally managed to write a patch. This patch applies ok on mod-gnutls
0.9.0 and not sure if it will work for buster.
--
Atte. Félix Arreola
Firmado con GPG 0x1e249ee4
Author: Félix Arreola RodrÃguez
Date: Thu, 5 Jun 2022 10:42:46 -0500
Subject: Fix a loop caused by timeout if mod_reqtimeout is enabled
Bug-Debian: https://bugs.debian.org/942737
When mod_reqtimeout is enabled, when mod_gnutls tries to read from
the previous apr_bucket, it returns a timeout. Mod_gnutls handles
incorrectly this timeout as a EAGAIN, causing to forever loop
and consumes 100% CPU on the current apache process.
---
diff --git a/src/gnutls_io.c b/src/gnutls_io.c
===
--- a/src/gnutls_io.c
+++ b/src/gnutls_io.c
@@ -269,6 +269,17 @@ static apr_status_t gnutls_io_input_read
ap_log_cerror(APLOG_MARK, APLOG_TRACE2, ctxt->input_rc, ctxt->c,
"%s: looping recv after '%s' (%d)",
__func__, gnutls_strerror(rc), rc);
+if (APR_STATUS_IS_TIMEUP (ctxt->input_rc)) {
+ /* Timeout by mod_reqtimeout, bye bye */
+ ap_log_cerror(APLOG_MARK,
+APLOG_INFO,
+ctxt->input_rc,
+ctxt->c,
+"GnuTLS: Timeout reading data. (%d) '%s'",
+rc,
+gnutls_strerror(rc));
+break;
+}
/* For a blocking read, loop and try again
* immediately. Otherwise just notify the caller. */
if (ctxt->input_block != APR_NONBLOCK_READ)
pgpktdURikVpl.pgp
Description: Firma digital OpenPGP
Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
Tags 942737 security thanks -- Atte. Félix Arreola Firmado con GPG 0x1e249ee4 pgpJSeaWennzx.pgp Description: Firma digital OpenPGP
Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
Now I think this bug, this could be used as DOS, should we call the security team to handle this? -- Atte. Félix Arreola Firmado con GPG 0x1e249ee4 pgpV3xZ_Wj95S.pgp Description: Firma digital OpenPGP
Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu
On Mon, 16 Dec 2019 02:37:50 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: > Dear Maintainer, > tried to reconstruct the given backtrace with debug symbols > in a gdb session and came to following, maybe it could be > of some help. > (Still a proper backtrace with dbgsym packages > installed would be better.) > > Kind regards, > Bernhard > > Dear Maintainer: I came across this bugs too. The problem is a infinite loop between mod-reqtimeout and mod-gnutls. The mod-gnutls (and underlaying gnutls) tries to read some bytes when the client hasn't sent any (like an empty tcp conn) and the mod-reqtimeout returns a timeout, causing mod-gnutls to loop endless trying to read more. Either mod-reqtimeout is broken, or either mod-gnutls doesn't handle correctly the timeouts. After debugging a lot with gdb, I can reconstruct the loop as follow: The code starts at function gnutls_io_input_read from gnutls_io.c from mod_gnutls, line 246, the "while(1)" loop. The code calls gnutls_record_recv, from gnutls, which in turns calls _gnutls_recv_int. gnutls_recv_int is called with type=GNUTLS_APPLICATION_DATA asking for 8192 bytes. Next it calls check_session_status, which checks if there is an EOF, and there is NO EOF. Also, check_session_status says that the session->internals.recv_state is RECV_STATE_0, whichs makes check_session_status return 1. Next, it calls get_data_from_buffers, which returns 0, which means there is no data in the buffer to consume. Next, it calls _gnutls_recv_in_buffers. _gnutls_recv_in_buffers calls recv_headers, which tries to read the header (which is 5). it calls _gnutls_io_read_buffered for 5 bytes. _gnutls_io_read_buffered ask for 5 bytes to _gnutls_read, which in turn uses _gnutls_stream_read to complete the request. _gnutls_stream_read returns back to mod-gnutls using the "pull_func" mgs_transport_read. msg_transport_read is located at gnutls_io.c:824 mgs_transport_read tries to use ap_get_brigade to get some bytes from the underlaying socket. ap_get_brigade tries to read from the "next" ap_filter_t, which (in my case) is "reqtimeout". reqtimeout_filter function calls check_time_left, which returns APR_TIMEUP. When it returns APR_TIMEUP, it logs "Request %s read timeout". So, back to mgs_transport_read, it reads APR_TIMEUP from the ap_get_brigade. BUT, it handles wrong this timeout and converts it to EAGAIN, which makes this whole stack run back. This is a big, 'nice' nasty bug, I have to say. As a workout around, I disabled module reqtimeout. Seems to solve the cpu usage issue. But, the bug is way more big than 'disabling' reqtimeout. Because, the problem is between mod-gnutls and mod-reqtimeout Steps to reproduce: Enable apache2 with the modules mod-gnutls, and mod-reqtimeout. Setup a reqtimeout like: RequestReadTimeout header=20-40,minrate=500 and open an openssl s_client: openssl s_client -connect IP:port Don't send any data over the openssl connect. Just wait for the timeout to happen. After the timeout, the CPU usage will increase. Also, you can quit the openssl s_client and the apache process will be stuck in the endless loop. -- Atte. Félix Arreola Firmado con GPG 0x1e249ee4 pgpRhuwCqo6hD.pgp Description: Firma digital OpenPGP
Bug#643595: ITP: snes9x -- Cross-platform SNES emulator
Hi! I can give access to anyone in the git repo. Also, I have some working backport'ed packages on a private repo server. You can add this repo with: deb http://alanturing.cucei.udg.mx/debian gatuno-squeeze main contrib non-free The packages seems to be working, you can try to rebuild them. I don't what else to say, but I want to help in anything that I can. -- Atte. Félix Arreola Rodríguez, «Sin firma GPG» -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650767: /usr/bin/gpg: gpg --edit-key clean - does not work
notfound 650767 1.4.12-4+b1 thanks I can confirm that the bug no longer exists in wheezy. I try to clean my public key with the edit command on gpg on wheezy and it works correctly. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#610336: [gnupg/1423] gnupg: key command has not a clear help message nor a clear output
tags 610336 +wontfix thanks Qoute the upstream author: I will consider that for 2.1. Doing it for 1.4 will break all translations and thus I don't belive it will be an improvement in the end. Sorry, we will have to wait for GPG 2. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#622940: [gnupg/1394] man page documents some unsupported parameters
The upstream author doesn't respond. Should we prepare a patch to remove the options in the manpage meanwhile? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#514623: [gnupg/1000] gnupg: cannot use revoked subkeys for decription using a smart card
tags 514623 + moreinfo + help thanks I don't have a card reader, and therefore I can not reproduce the problem, is this bug still active? Someone could check if this bug persists. The upstream also could not reproduce the problem, so he just close the bug. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#642512: gnupg --recv-keys says key xxx not found on keyserver when a proxy refused connexion with 503
tags 642512 + moreinfo thanks I want to replicate the bug, Do you know some proxy that filters the HKP port? Or a way to make squid filter it? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#682281: Tag wontfix doesn't display the sad face icon correctly
Package: bugs.debian.org Severity: wishlist Hi, I love the Debian BTS, I always like to walk around and read the bugs and tags. But recently, the sad face icon (associated with the wontfix tag) doesn't display correctly. I mean, with the tag fixed-version it displays a happy face, but not with wontfix. Instead, it shows a letter a with circumflex. I have to say, that, I still use iceweasel 3.5, but I checked with a Firefox 14 and the bug remains. I attach the pic of the a with circumflex on iceweasel 3.5. In Firefox 14 doesn't display the little box with the 0098 numbers. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 attachment: tag_wontfix.png signature.asc Description: This is a digitally signed message part
Bug#386980: gnupg: can't mount loop-aes partition during boot with separate /usr partition
Maybe /etc/init.d/checkfs-loop should ensure that /usr is mounted before trying to mount loop-aes partitions. If that the case, it should be a loop-aes-utils bug. IMHO is not needed that gpg to be in /bin, as it is a user binary. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#614963: gnupg: gpg freezes with a zombie child gpgkeys_hkp after a Ctrl-C
tags 614963 + moreinfo unreproducible thanks Maybe it is a broken implementation of a hkp server? How many public keys do you have in your keyring? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#630388: gnupg: `gpg --edit-key notexist' silently does nothing
forwarded 630388 https://bugs.g10code.com/gnupg/msg4314 tags 630388 + upstream confirmed thanks I can confirm this bug still exists in gpg 1.4.12-4+b1 (lastest in unstable). The bug is now forwarded to upstream. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#645426: gpg --homedir /nonexistent --gen-key goes through the entire key generation process, then errors out
forwarded 645426 https://bugs.g10code.com/gnupg/msg4315 tags 645426 + upstream forwarded thanks This bug is confirmed in gnupg 1.4.12-4. This bug is now forwarded to upstream (https://bugs.g10code.com/gnupg/msg4315) -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#614963: gnupg: gpg freezes with a zombie child gpgkeys_hkp after a Ctrl-C
tags 614963 + moreinfo thanks Maybe it is a broken implementation of a hkp server? How many public keys do you have in your keyring? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#645426: gpg --homedir /nonexistent --gen-key goes through the entire key generation process, then errors out
forwarded 645426 https://bugs.g10code.com/gnupg/msg4315 tags 645426 + upstream forwarded thanks This bug is confirmed in gnupg 1.4.12-4. This bug is now forwarded to upstream (https://bugs.g10code.com/gnupg/msg4315) -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#660685: RFH: gnupg -- GNU privacy guard - a free PGP replacement
El lun, 20-02-2012 a las 21:31 +0100, Daniel Leidert escribió: Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I request assistance with maintaining the gnupg package. The package is team-maintained via alioth (pkg-gnupg group). Regards, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9CrbEACgkQm0bx+wiPa4w28wCgpy6PdGgZhB1mohgM3Dn5epWY o5QAn2UsFOJKsFyyif7Eha7hTQUuWgGj =jxCl -END PGP SIGNATURE- I'm also interested in lending a hand. Right now I'm joining to the Debian Alioth group. Is the help still needed? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#542095: duplicates in the archive
El lun, 09-07-2012 a las 19:46 +0100, Ian Jackson escribió: Adam Borowski writes (Re: duplicates in the archive): Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. I definitely think this should be fixed for wheezy. Adam earlier wrote on -devel: I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) The dependency comes via gnome-core depending on network-manager-gnome. To the Gnome maintainers: given that Adam has done this test, to check that things are OK without n-m, would you be willing to make this change to the gnome-core metapackage ? Thanks, Ian. A system without network-manager is still usable even for desktop users. I mean, for example, when Pidgin opens, and n-m is not available, it just tries to connect directly to internet. When pidgin opens, and n-m is active pidgin waits to connect until n-m gets connected. Sometimes is annoying because other network interfaces may be active with full internet and pidgin waits until n-m reports ready. A similiar experience happens with Evolution. But, ignoring the a desktop works fine without n-m thing, n-m makes more, much more easy connecting to wifi networks, espeacially for laptops. I suggest make Laptop task depend on n-m, in this way, n-m don't get installed on desktop systems, just on laptop systems. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#663025: isc-dhcp-client: Fails to set an ipv6 addr
So, we should mark this bug as duplicate of #591589? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#663025: isc-dhcp-client: Fails to set an ipv6 addr
Package: isc-dhcp-client Version: 4.1.1-P1-15+squeeze3 Severity: important Tags: ipv6 I have succeful installed a Tunnel broker in my router, and get a whole /64 prefix. The router is giving dhcp leases of the 2002:456:e:3e4::/64 subnet (The real IP is similar to this one). Using my laptop, I configured network-manager to automatic in ipv6, and sucessfull get a ipv6 over wired interface and wireless interface. So, I wanted to have ipv6 connectivity in my desktop machine. But, as the machine act as server, it doesn't use network-manager. The /etc/network/interfaces just have this: [code] # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp [/code] When I try to get a dhcpv6 lease (using dhclient -6), I get the following errors: dhclient -6 eth0 -v Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:546 Listening on Socket/eth0 Sending on Socket/eth0 PRC: Confirming active lease (INIT-REBOOT). XMT: Forming Confirm, 0 ms elapsed. XMT: X-- IA_NA 7d:28:d3:a5 XMT: | X-- Confirm Address 2002:456:e:3e4::10 XMT: V IA_NA appended. XMT: Confirm on eth0, interval 1010ms. send_packet6: Network is unreachable dhc6: sendpacket6() sent -1 of 72 bytes XMT: Forming Confirm, 1010 ms elapsed. XMT: X-- IA_NA 7d:28:d3:a5 XMT: | X-- Confirm Address 2002:456:e:3e4::10 XMT: V IA_NA appended. XMT: Confirm on eth0, interval 2040ms. send_packet6: Network is unreachable dhc6: sendpacket6() sent -1 of 72 bytes XMT: Forming Confirm, 3050 ms elapsed. XMT: X-- IA_NA 7d:28:d3:a5 XMT: | X-- Confirm Address 2002:456:e:3e4::10 XMT: V IA_NA appended. XMT: Confirm on eth0, interval 4000ms. send_packet6: Network is unreachable dhc6: sendpacket6() sent -1 of 72 bytes XMT: Forming Confirm, 7050 ms elapsed. XMT: X-- IA_NA 7d:28:d3:a5 XMT: | X-- Confirm Address 2002:456:e:3e4::10 XMT: V IA_NA appended. XMT: Confirm on eth0, interval 6950ms. send_packet6: Network is unreachable dhc6: sendpacket6() sent -1 of 72 bytes Max retransmission duration exceeded. PRC: Bound to lease 00:01:00:01:16:e9:b7:5a:1c:bd:b9:b7:44:be. Next, I run ifconfig to check the IP: #ifconfig eth0 Link encap:Ethernet HWaddr 00:1d:7d:28:d3:a5 inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::21d:7dff:fe28:d3a5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18727 errors:1 dropped:0 overruns:0 frame:1 TX packets:17145 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18368922 (17.5 MiB) TX bytes:2549306 (2.4 MiB) Interrupt:25 Base address:0xe000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:157204 (153.5 KiB) TX bytes:157204 (153.5 KiB) and the eth0 doesn't have the IP assigned (2002:456:e:3e4::10), just the local link. I think that dhclient fails to set the IP information properly. Regards, Felix -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isc-dhcp-client depends on: ii debianutils 3.4 Miscellaneous utilities specific t ii iproute 20100519-3 networking and traffic control too ii isc-dhcp-common 4.1.1-P1-15+squeeze3 common files used by all the isc-d ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: pn avahi-autoipd none (no description available) pn resolvconfnone (no description available) -- Configuration Files: /etc/dhcp/dhclient.conf changed: option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; send host-name gatuno-debianizado.gatuno.com; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes; -- no debconf information -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#651538: mame: New upstream release 0.144
El vie, 09-12-2011 a las 18:01 +0100, Christian Marillat escribió: Package: mame Version: 0.143-3 Severity: normal Dear Maintainer, 0.144 has been released to weeks ago. Would be nice to have a package. Christian -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mame depends on: ii libatk1.0-0 2.2.0-2 ii libc6 2.13-21 ii libexpat1 2.0.1-7.2 ii libfontconfig1 2.8.0-3 ii libgcc1 1:4.6.2-5 ii libgconf2-4 3.2.3-1 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libglib2.0-02.30.2-4 ii libgtk2.0-0 2.24.8-2 ii libpango1.0-0 1.29.4-2 ii libsdl-ttf2.0-0 2.0.9-1.1 ii libsdl1.2debian 1.2.14-6.4 ii libstdc++6 4.6.2-5 ii libx11-62:1.4.4-4 ii libxinerama12:1.1.1-3 ii zlib1g 1:1.2.3.4.dfsg-3 mame recommends no packages. Versions of packages mame suggests: pn gnome-video-arcade none pn mame-tools none -- no debconf information We are currently packing the new version in the git repo. But there are some new 'changes' around the mame and mess source code. These changes involves the way we build the deb packages. We will have the new package soon. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#632943: pixman: Please allow easier backports
Same problem here, on my squeeze machine. In first place tried to compile libcairo2, and then need to compile pixman. Pixman FTBFS on squeeze. Is something I need to add to the bug report? -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Bug#513322: Fwd: Bug#513322: ITP: mupen64plus -- plugin-based N64 emulator
Well, maybe I should give the ITP to another people, someone who has experience in the deb packing. I was thinking that I can do the work, but, maybe it's not for me... It's ok, I now know why Debian is so cool, because it has people who take care of all. I just want to say thank you for this oportunity. Maybe in the future. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 223D869A
