grsecurity forums

clear

Palatinux wrote:During the latest test versions of grsec for the 3.4.4 kernel we noticed quite some size overflows while loading the kernel and waking up a computer from stand-by mode.

One of them was in drivers/base/map.c

we'd need a whole lot more information than that, i'm afraid . like exact grsec version, kernel logs of the overflow report, etc.

Is it possible to check for such overflows during a kernel compile? and if not, is it possible to include such a check? I'm sure this will reduce some grey hair on the grsec users.

the whole point of this feature is to introduce runtime checks for calculations that cannot be checked statically at compile time, so the answer is no. however the corresponding gcc plugin is still undergoing development (your problems are probably false positives but we'd need the logs to be sure), so we'll need feedback to be able to improve it further.

clear

Palatinux wrote:We just hoped you knew a way to easily debug it because we could not think of one ourselfs

we normally look at the reported code (that's why the logs would be important) and try to figure out how an integer overflow could have occured there. then if we determine that the kernel code is properly written then we know it's a false positive, so we fix the plugin, otherwise we fix the kernel code (although technically the plugin already prevents exploitation).

Normally we fix all grsec/kernel errors ourselfs, but this a function we didn't used before.

two things, 1. it's an experimental plugin for a reason for now, so maybe don't use it in production yet , 2. how about sending your fixes to grsec to us?

Plz let me know if you've already found it.

i'm afraid that without the logs we don't really know where to even start looking

clear