grsecurity forums

This happened with Gentoo hardened-sources 2.6.36-r6 with grsecurity-2.2.1-2.6.36.2-201012121726.patch applied.
I wondered why there was no core dump following an X crash and then checked dmesg:

Pid: 2917, comm: X Not tainted 2.6.36-hardened-r6 #1
Call Trace:
[33172.346750] [<ffffffffxxxxxxxxx>] ? i915_gem_alloc_object+0x41/0xd0
[33172.346753] [<ffffffffxxxxxxxxx>] ? i915_gem_create_ioctl+0x3e/0xb0

I will send additional info via email upon request.

Best

Hugo Mildenberger wrote:Pid: 2917, comm: X Not tainted 2.6.36-hardened-r6 #1
Call Trace:
[33172.346750] [<ffffffffxxxxxxxxx>] ? i915_gem_alloc_object+0x41/0xd0
[33172.346753] [<ffffffffxxxxxxxxx>] ? i915_gem_create_ioctl+0x3e/0xb0

I will send additional info via email upon request.

please send me the entire log of this event if you got it (backtrace, registers, etc) and your vmlinux (not bzImage). from a quick look it seems that the only refcount related operations are in drm_gem_object_init called from i915_gem_alloc_object and there're actually two candidates (->object_count and ->object_memory), neither of which seems to be a false positive so this is worth a look and possibly some debugging. is this something you can reproduce at will?

while looking at the code some more i figured some debug info could already be helpful. if you enable CONFIG_DEBUG_FS then you'll find /sys/kernel/debug/dri/*/vma and /sys/kernel/debug/dri/*/gem_objects on your system, i'd be interested in their content around the time the refcount overflow is detected (perhaps take regular snapshots of them).

Ok, sent info from dmesg via board pm to Pax Team and vmlinux via email to Brad. An upload directory would be convenient.

thanks for the log, i see what it is now. it's the ->object_memory counter that has a sign overflow (i.e., it reached 2GB) and i'm not sure what kind of system you need to reach 4GB (and wraparound, even on vanilla) but it's probably not far in the future. what i don't know is whether this whole GEM code is supposed to deal with memory sizes over 32 bit or not, clearly this part isn't . so for now i'll disable overflow checking on drm_device.{object_memory,pin_memory,gtt_memory} as they're not used for anything but debugging/reporting purposes only but you should probably ask some DRM/GEM people whether this potential overflow condition presents any problems in their design or not.

Hmm, any idea whom to contact about this? libdrm mailing list?

As far as I know GEM is currently part of the vanilla kernel. At least it was introduced in 2.6.28.
http://www.phoronix.com/scan.php?page=n ... &px=Njc4OQ

LKML looks like a good place to start.