There is a memory leak occurring when I use nfs on hardened sources 2.6.32-r9. I've tested with -r11 and the problem is fixed so I did not investigate further. I can give access to the system if needed (a test system) Reproducible: Always Steps to Reproduce: 1. Boot up with hardened sources 2.6.32-r9 2. Connect to NFS (I share portage with it) 3. Use NFS (I noticed the problem with an emerge) Actual Results: kernel panic related to using too much memory Expected Results: not crashed I noticed that no swap was used.
Created attachment 242475 [details] kernel config
Created attachment 242477 [details] emerge --info
I was unable to reproduce this. Comparing kernel config files, we have identical GRSEC, PaX and NFS settings. Comparing emerge --info, we have identical profiles and toolchains. My system was a full virt domU in a xen host.
i have the same issue but the problem also occurs even if i dont use nfs and there is all ready a bug about that #324243 so question is if you can reproduce it (like i did) with out using nfs (posting my details on that other bug).
I suspect that this is just another instance of bug #324243. @Matthew Thode, can you tell us if you hit this in a virtualized guest? If so what kind of virtualization?
the only reason I don't think it's the virt env is because I don't have the mem leak on anything but 2.6.32-r9 I am using kvm.
Okay I've got a better handle on this one. To hit it you need to 1. be using hardened-sources-2.6.32-r9 2. be using virtio for your net and drive CONFIG_VIRT_TO_BUS=y CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_NET=y CONFIG_VIRTUALIZATION=y CONFIG_VIRTIO=y CONFIG_VIRTIO_RING=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_BALLOON=y When I used virtio, but I switched to hs-2.6.32-r14 the memory leak went away. I didn't test kernels between -r9 and -r14 but my suspicion is that -r9 is affected because it is the last with the grsec-2.1.14. Later ones use grsec-2.2.0. When I used any hardware emulation rather than virtio, the problem was not there for either -r9 or -r14. So you need *both* for the problem to occur. The workaround for now can be to avoid the above. When we stabilize >= -r14 I'll close this bug. Can others confirm this?
can you guys try the latest .32 and .35 PaX test patches (http://www.grsecurity.net/~paxguy1/) and let me know if you still see the memory leak? if you do, can you post /proc/slabinfo in the hope that the leaking structure will show up there?
Bug is fixed from the grsec patchset 2.2.0 on.
(In reply to comment #9) > Bug is fixed from the grsec patchset 2.2.0 on. > I'm hoping to stabilize 2.6.32-r18 and 2.6.35-r1 after the necessary grace period. Both are based on 2.2.0. As I said above, I will close this bug then.
