Created attachment 417452 [details] dmesg Please see attached kernel log. This errors appears right after the KVM guest is started.
Created attachment 417454 [details] kernel-config
I didn't see such errors with hardened-sources-4.2.6-r1 and older.
this is a false positive due to gcc turning the 0xff bitmask operation on exitintinfo into a simple typecast. the overflow plugin already has special detection for certain type combinations but adding u32->u8 there would also eliminate other useful checks so we'll just disable overflow checking on all vmcb_control_area fields instead.
(In reply to PaX Team from comment #3) > this is a false positive due to gcc turning the 0xff bitmask operation on > exitintinfo into a simple typecast. the overflow plugin already has special > detection for certain type combinations but adding u32->u8 there would also > eliminate other useful checks so we'll just disable overflow checking on all > vmcb_control_area fields instead. People have been asking for a new stable release of the kernel in the 4.2 series. I get this is a false positive but should we wait for a fix? I don't want a bunch of duplicate bugs. It has been hard stabilizing kernels for gentoo since the upstream stable series was restricted to the public since fixes to existing bugs are often mixed with new features that introduce their own bugs. Advice?
well, the size overflow plugin will continue to have false positives, so that will always stand in the way of stabilization. if i were you i'd just let people know that they should be careful and not enable it if they don't want to risk the FPs.
4.2.6-r5 is affected with this bug too.
(In reply to Martin Filo from comment #6) > 4.2.6-r5 is affected with this bug too. which grsec version is that?
(In reply to PaX Team from comment #7) > (In reply to Martin Filo from comment #6) > > 4.2.6-r5 is affected with this bug too. > > which grsec version is that? 4.2.6-r5 -> grsecurity-3.1-4.2.6-201511182042 4.2.6-r6 -> grsecurity-3.1-4.2.6-201511232037
(In reply to Anthony Basile from comment #8) > 4.2.6-r5 -> grsecurity-3.1-4.2.6-201511182042 > > 4.2.6-r6 -> grsecurity-3.1-4.2.6-201511232037 ah, so one issue should be fixed in -r6 but there's another one which we'll fix in the next patch.
(In reply to PaX Team from comment #9) > (In reply to Anthony Basile from comment #8) > > 4.2.6-r5 -> grsecurity-3.1-4.2.6-201511182042 > > > > 4.2.6-r6 -> grsecurity-3.1-4.2.6-201511232037 > > ah, so one issue should be fixed in -r6 but there's another one which we'll > fix in the next patch. With -r6 I get: PAX: size overflow detected in function __make_request drivers/md/raid10.c:1436 cicus.1022_569 max, count: 231, decl: sector; num: 0; context: r10bio; Is it an issue you mentioned or should I open another bug?
(In reply to Alexander Tsoy from comment #10) > With -r6 I get: > PAX: size overflow detected in function __make_request > drivers/md/raid10.c:1436 cicus.1022_569 max, count: 231, decl: sector; num: > 0; context: r10bio; > > Is it an issue you mentioned or should I open another bug? it's a new one ;), you can open a separate bug about it (and CC Emese/me at least). the code basically computes int=u64+int-u64 so we'd have to see the runtime values of r10_bio->sector, max_sectors and bio->bi_iter.bi_sector. do you need a patch to print them out or can you figure it out yourself?
(In reply to PaX Team from comment #11) > it's a new one ;), you can open a separate bug about it (and CC Emese/me at > least). the code basically computes int=u64+int-u64 so we'd have to see the > runtime values of r10_bio->sector, max_sectors and bio->bi_iter.bi_sector. > do you need a patch to print them out or can you figure it out yourself? i'll actually have a fix for this in the patch though it'd still be nice to get the runtime values of these variables.
(In reply to PaX Team from comment #12) Sorry for delay. I opened bug #567012
(In reply to Alexander Tsoy from comment #13) > (In reply to PaX Team from comment #12) > > Sorry for delay. I opened bug #567012 did you confirm that the original bug in the title is fixed? if so we should close this bug.
(In reply to Anthony Basile from comment #14) > did you confirm that the original bug in the title is fixed? if so we > should close this bug. I cannot verify that.
Due bug 567048, I can't test r6.
(In reply to Alexander Tsoy from comment #15) > (In reply to Anthony Basile from comment #14) > > did you confirm that the original bug in the title is fixed? if so we > > should close this bug. > > I cannot verify that. -r7 is OK. So I'm closing this bug.
