Bug#945770: Segfaults running XSLT operations
Package: libxslt1.1 Version: 1.1.32-2.2~deb10u1 Running XSLT operations might result in segmentation faults with version 1.1.32. We experienced it running some of our apps in a Debian 10, Apache mod_php environment which uses Debian's stock packages. Code path is rather difficult to analyze & to share, so it might not be possible to reproduce. However, the exact same app with exact same input was tested on the exact same environment except the libxslt version: - With 1.1.32-2.2~deb10u1 (Debian's) : Segfault of Apache process: Program terminated with signal SIGSEGV, Segmentation fault. #0 xmlStrEqual__internal_alias ( str2=0x6e2f6d6f632e6d75 0x6e2f6d6f632e6d75>, str1=0x558f57552cf1 "ttp://www.w3.org/2001/XMLSchema-instance") at ../../xmlstring.c:162 - With 1.1.33 (built as Debian package from upstream libxslt sources & minor modifications to 1.1.32 Debian packaging sources) : runs fine. BTW, we don't know if it is related, but we had already identified the need to upgrade to 1.1.33 for our apps as we experienced bug #939785 as well. I suggest replacing v1.1.32 with v1.1.33 in Buster. Thanks,
Bug#793941: That's a Linux bug
I tracked the issue down and here is more information : IPMI session is cut off when a ip link set eth0 down command is issued. The Debian installer does that is a script as well as something similar (iface downing) in netcfg (at least). It seems that's a Linux bug. Before 25bfb1dd4ba3b2d9a49ce9d9b0cd7be1840e15ed downing the iface only causes 2/3s of packet loss on the IPMI side. The Maintainers have been contacted. So if the issue is confirmed and fixed by the maintainers, it would be great to backport the fix to Jessie's kernel. -- Sébastien Bocahu IT infrastructure manager 4, Rue Montrochet - 69002 - Lyon, France +33 (0)437651704 - Phone ReportLinker.com
Bug#793941: ethdetect kills IPMI session on a DELL R510 server
Package: installation-reports Severity: important Dear Maintainers, I can't install Jessie remotely on a Dell R510 server over IPMI, because the IPMI session gets killed at ethdetect. The server is very mainstream, a Dell R510 model w/ a IPMI BMC shared over a BCM5716 NIC. I tried an old Jessie netboot image as well as yesterday's current one from : http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/netboot.tar.gz + BNX2 firmware from : http://ftp.nl.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-bnx2_0.44_all.deb packed into the initrd. The installer boots fine and asks for the language, then tries to detect ethernet hardware and the IPMI session gets killed : timeout. It is then impossible to reach the BMC, the IPMI dedicated IP does not respond (ICMP confirms - it comes back after a power cycling from a PDU) I could however check that the network interface works fine by escaping the questions asked by the installer and starting a shell : ip link set eno1 up # works udhcpc -i eno1 # works, gets an ip ping whatever # works ethdetect # boum, big badaboum With Wheezy, the IPMI session gets freezed for 10s (ICMP reports ~10s of packet loss) then everything's ok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704089: tzdata config script prevents non-interactive (re)configuration
Package: tzdata Version: 2012j-1 The configuration script of the tzdata package, wich uses debconf, prevents non-interactive (re)configuration of the package. To reproduce: - feed debconf with new values for tzdata keys (ex. debconf-set-selections) - run 'dpkg-reconfigure -fnoninteractive tzdata' - configuration is unchanged I propose the following change which makes non-interactive reconfiguration possible: --- /var/lib/dpkg/info/tzdata.config.orig 2013-03-27 18:58:53.0 +0100 +++ /var/lib/dpkg/info/tzdata.config2013-03-27 18:35:53.0 +0100 @@ -370,8 +370,10 @@ # Initializes debconf default values from the ones found in # configuration files -db_set tzdata/Areas $AREA -db_set tzdata/Zones/$AREA $ZONE +if [ -z $DEBCONF_RECONFIGURE ]; then + db_set tzdata/Areas $AREA + db_set tzdata/Zones/$AREA $ZONE +fi STATE=1 while [ $STATE -ge 0 ]; do Note: the comment could make us believe that keys are initialized with the current values of the debconf database, but it is not the case. These values are computed from /etc/timezone. Thanks, -- Sebastien Bocahu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683984: libapache2-mod-rpaf: potential Denial of Service
Hi, I am the bug reporter. The minimal patch is to drop 030_ipv6.patch. I can't confirm that this bug is *not* reproducible for 0.6 version *with* the above patch. Can you ask bugreporter to report details on: --8-- rpaf 0.6 is available in Debian wheezy. The IPv6 patched is not applied though. I patched myself and tested it on the same squeeze environment: there is no more segfaults. --8-- ? Unmodified 030_ipv6.patch still produce segfaults on 0.6+, for me. You are right. The ipv6 patch still produce segfaults on 0.6 on my setups as well. I had messed up while testing custom patches, sorry. This means that I should report the bug to upstream, as there is still a bug in the memory management or header parsing in 0.6... Thanks for working on this -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683984: libapache2-mod-rpaf: potential Denial of Service
As a workaround, you should avoid using x-forwarded-for header from untrusted sources. Usually, it is the case - you can trust your frontend servers ;) That means - real impact of this issue is very minor and mostly due to misconfiguration. Excuse me ? This is definitely _not_ a misconfiguration issue. mod_rpaf is supposed to use the *last* X-Forwarded-For header. There's a bug which adds some garbage to the remote_ip field, when a specific request is sent, and a *correct* X-Forwarded-For header added by the reverse proxy. (so the request has two X-Forwarded-For headers when it arrives on the web front end, one is malicious, one is correct from a trusted source). A workaround could be stripping the previous X-Forwarded-For headers on the reverse proxy, but it shouldn't be necessary. Real impact of this issue can be remote DOS of a LAMP cluster. What makes you feel that this issue is very minor ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651425: LVM2 pvs -o pv_attr bug
Hi, I confirm this bug: Fresh Wheezy installation on two machines, only one had this bug. I played a bit with the pvs command line and it appears that everything's fine excepted the pv_attr field (pvs -o pv_attr). I could fix this by upgrading LVM2 to version 2.02.95-4 from Sid. Please let me know if more experimentation are needed or how I can help. Cheers, -- Sébastien Bocahu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
