Bug#573071: Oops: 0003 [#1] SMP - BUG: unable to handle kernel paging request
Similar (buggy) behaviour in stable 686-kernel package: linux-image-2.6.26-2-686-bigmem (2.6.26-21lenny4) Tested on Debian 5.0.4, 32 bits, on AMD64. Any idea on how long could it take a new kernel .deb to be released? Cheers, -r -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#153915: Bug still present in Debian 5.0.4
Hello, Same problem here in a up-to-date Debian stable (5.0.4 with all security fixes, etc). I surfed the web googling for more info and I could hear about the same problem reported in different forums, etc (there are several bug-ids in Debian bug-tracking system, for instance). It's not clear whether the problem is caused by saslauthd, libpam or any of the pam modules (pam-mysql, mainly). But it's clear that something is leaking memory. Only workaround I've found was to restart saslauthd service periodically (via cron). There is another workaround (-n 0 switch) which I didn't test, since it would be not acceptable (IMHO) due to performance problems. This bug can be abused to cause a DoS (server crash due to be out of memory), so it has a security impact. Bug reports if this bug arise from 2006 or earlier; incredibly it's NOT fixed yet (we're in 2010!). Cheers, -Roman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517331: Imapproxy refused to start when imap server is not available
Package: imapproxy Version: 1.2.6-5 Severity: important Hola, I upgraded Etch to Lenny today and ended with imapproxy service not being up. I researched a bit and the problem seems to be that imapproxy refuses to start when no imap server is reachable / available. This is dangerous and could derive in service lost (depending on imap server stability, possible network outages, etc). In my case, I suppose that imapproxy was restarted when cyrus was down. This is what I can see in mail.log: Feb 27 01:13:03 hsnew in.imapproxyd[5250]: No syslog priority mask specified. Feb 27 01:13:03 hsnew in.imapproxyd[5250]: main(): SELECT caching is disabled Feb 27 01:13:03 hsnew in.imapproxyd[5250]: main(): Internal admin commands are disabled Feb 27 01:13:03 hsnew in.imapproxyd[5250]: main(): Allocating 3072 IMAP connection structures. Feb 27 01:13:03 hsnew in.imapproxyd[5250]: ServerInit(): Using '/var/log/imapproxy_protocol.log' for global protocol logging file. Feb 27 01:13:03 hsnew in.imapproxyd[5250]: ServerInit(): proxying to IMAP server 'localhost'. Feb 27 01:13:03 hsnew in.imapproxyd[5250]: ServerInit(): Proxying to IMAP port 143 Feb 27 01:13:03 hsnew in.imapproxyd[5250]: ServerInit(): Connection refused -- exiting Look at the last line: imapproxy exited because it couldn't connect to imap server! This is unforgivable for a proxy service... The correct behaviour should be logging the error and then continue serving requests (waiting imap service to get up). Tested on Debian Lenny, up to date. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517331: Acknowledgement (Imapproxy refused to start when imap server is not available)
I forgot to mention that there is another bug reported (#512369), which it's similar. At least the cause seems to be the same, but when I read ticket #512369 I got the sensation that it was only a configure problem or a postinstall problem. It's wider than that: every time that imapproxy is started (/restarted) there's a failure window opened. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#327870: kernel-patch-grsecurity2: New glibc packages break compatibility with grsec
Steve Langasek wrote: See bugs 321720, 321721, 321723, and 321724 in the BTS. The bug in openssl has been fixed in unstable, and that fix should soon propagate to testing; a related bug was fixed in libacl1 before the sarge release. Nice to see that these kind of bugs are being addressed. I'll apply the workaround. You can close this ticket. This is the response I've received from grsec's developper: The workaround is fine. The main problem is that glibc was forcing an exit of the application if its improperly set PT_GNU_STACK was being set on the application. Regardless though (both with and without the workaround), the packages with the improper PT_GNU_STACK settings should be fixed soon, since exec-shield users will have the stack improperly set as executable in those applications (which due to exec-shield's implementation, makes the entire address space of that application executable). Gentoo has applied the same workaround by the way, a long time ago. -Brad Thanks to both Steve Brad. Cheers, -Román
Bug#327870: kernel-patch-grsecurity2: New glibc packages break compatibility with grsec
Hello, Thanks for your response, Steve. It sounds very logical to me. Anyway, I've cc'ed spender (grsec developper). It would be interesting if he could add his comments here in this ticket since he's perhaps the more capable person to answer grsec issues. Perhaps he can refute some of your arguments :) If not, the workaround could be ok for me and you could close this ticket but first let's wait for Brad's answer, please. Apart from this, do you have a list of libraries/packages that should be fixed? Because somebody would have to file tickets for those packages, I guess. I'd do by myself but I'm not a grsec nor Debian expert :-( Regards, -Roman Steve Langasek wrote: On Mon, Sep 12, 2005 at 06:18:22PM +0200, Roman Medina wrote: Package: kernel-patch-grsecurity2 Severity: critical Justification: breaks unrelated software Grsec patch is incompatible with glibc post-v.2.3.2. I don't think that's actually true. From what I can tell, what happens is that glibc now enforces requests for an executable stack, and bails immediately at startup rather than risking a failure sometime later when one or more libraries has requested an executable stack. http://lists.debian.org/debian-user/2005/08/msg00747.html This post describes a correct workaround, pending resolution of the bugs in libgcrypt, libcrypt, etc. http://forums.grsecurity.net/viewtopic.php?t=1152 This thread doesn't seem to include posts from anyone who actually has a clue about the nature of the bug, or who has tried to file bug reports with Debian about it (other than the original poster). It does, however, include posts from at least one known troll. To the best of my knowledge, there are only a handful of significant libraries in Debian which have this bug; they should be fixed, but there is a known workaround for those applications which require an executable stack. This is not a glibc bug; there is no bug in *reporting* the kernel error when a library's request for an executable stack cannot be honored, and it is not glibc's job to decide which executable stack requests are legitimate and which are not. It is not a kernel-patch-grsecurity2 bug; grsec is working as advertised, and requires you to manually enable executable stack for any applications you wish to grant it to. Unless you can show that the workaround for some reason doesn't work for you, I think this bug should be closed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
