On Sat, 2013-02-16 at 22:37 +0100, Josip Rodin wrote: > On Sat, Feb 16, 2013 at 03:13:06AM +0000, Ben Hutchings wrote: > > On Fri, 2013-02-15 at 08:56 +0100, Josip Rodin wrote: > > > > I appear to be experiencing a serious problem with a 768 MB RAM Xen domU > > > > machine running an NFS client - every now and then (for months now), often > > > > in the middle of the night, it enters some kind of a broken state where a > > > > few semi-random processes (mainly apache2's and vsftpd's which are told to > > > > serve files from the NFS mount) > > [...] > > > I caught it earlier just now, at: > > > > > > [950084.590733] active_anon:2805 inactive_anon:11835 isolated_anon:0 > > > [950084.590735] active_file:76 inactive_file:516 isolated_file:32 > > > [950084.590737] unevictable:783 dirty:1 writeback:0 unstable:0 > > > [950084.590739] free:26251 slab_reclaimable:15733 slab_unreclaimable:128868 > > > [950084.590741] mapped:938 shmem:75 pagetables:651 bounce:0 > > > > > > And snuck in a few slabtops (even some -o invocations were getting killed, > > > along with my shell and pretty much everything else): > > [...] > > > 65390 65390 100% 2.06K 13338 15 426816K net_namespace > > [...] > > > > Looks like CVE-2011-2189, for which there was a fix/workaround in: > > > > vsftpd (2.3.2-3+squeeze2) stable-security; urgency=high > > > > * Non-maintainer upload by the Security Team. > > * Disable network isolation due to a problem with cleaning up network > > namespaces fast enough in kernels < 2.6.35 (CVE-2011-2189). > > Thanks Ben Hutchings for the patch! > > * Fix possible DoS via globa expressions in STAT commands by > > limiting the matching loop (CVE-2011-0762; Closes: #622741). > > > > -- Nico Golde <nion@debian.org> Wed, 07 Sep 2011 20:39:59 +0000 > > > > Do you have an old version of vsftpd, or perhaps an upstream version > > which doesn't include the workaround? > > No, 2.3.2-3+squeeze2 is there, has been since 2012-03-22. > > > Anyway, I'm closing the bug report; please don't hijack closed bugs. > > Eh? It was not closed for being fixed, it was closed en masse on a > procedural reason that could easily be wrong, and I don't believe I was > hijacking it; you just confirmed that this is a kernel problem above, > so how could this possibly be improper?! It's not the same bug. Open a new bug report. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are.
Attachment:
signature.asc
Description: This is a digitally signed message part