potential memory leak in grsec with UDEREF (amd64)

[adren]

Hello,

I'm using grsecurity since 2005 (2.6.10) and between 2.6.33.2 and 2.6.33.3, UDEREF was introduced for the x86_64 platform.

As it looked interesting, I've tried it but over the 2 weeks following 2.6.33.3, I've experienced major memory leaks that made the computer very slow after 36 hours or so doing nothing special.
This computer has 8GB of RAM that would completely fill, and after 48 hours, the clogging process is so deep that I could manage to type a few command (vvvveeerrrryyyy sslllloooowwwlllyyy) but then, even the 'reboot' command would never end (I let it run once for 30mn and finally gave up).

n.b.: for those who are interested, here is a commented munin graph showing the different phases of kernel testing on a computer used primarily as a desktop
http://adren.org/~cyril/bug_grsec_leak.png
- on the daily graph, you can see that the very last hours with a 2.6.33.3 without UDEREF (everything is back to normal)
- before that, as well on the weekly and monthly graph (week 18), some pics of abnormal memory hog when everything is consumed (the green spot representing the "apps" memory)
- for the rest of the year and more clearly on the monthly (weeks 14-17), everyhting is fine and the memory is used between 1 to 2GB for the applications

the most intriguing aspect of this comes from the fact that I couldn't tell from which application the problem came (both htop or memstat wouldn't show enormous amount of RAM being used by some processes)


My biggest concern is that I'm apparently the only one to suffer from such regressions of grsec (grsecurity-2.1.14-2.6.33.3-201004292005.patch to be more precise).
Has anyone else noticed the same symptoms on his computer?

[specs]

It is not only the combination of 2.6.33.3, grsecurity, an AMD64 and UDEREF.
I haven't experienced problems with the combination yet.
Perhaps you should look at http://en.wikibooks.org/wiki/Grsecurity/Reporting_Bugs first.

Depending on your configuration you might need to gather some information as root or you might need to change the configuration for information gathering.
I think of options like GRKERNSEC_ACL_HIDEKERN and GRKERNSEC_PROC.

[adren]

just for the record, here is the epilogue of this bug:

Brad and the PaX team helped me to narrow down the regression

finally, the problem is CONFIG_PAX_MEMORY_UDEREF in conjunction with CONFIG_PARAVIRT
when both kernel options are set, the system is consuming all the memory in few hours (depending on how much RAM you have) until the host computer is unusable