Arch Linux

Confirming this happening on 4.2.6.201511211841-1 with btrfs (as my rootfs). Firefox was the catalyst for me - after opening it it wasn't interruptable and then shortly after there was an entire system freeze (REISUBing didn't work).
Attached kernel log of the pax overflow error, it's similar to the original.

They're already aware of the ext4 issue so hopefully it will be fixed soon. Can watch to see what happens here:

https://forums.grsecurity.net/viewtopic.php?f=3&t=4324?

The btrfs issue is one that they didn't already have reported so it would be helpful to gather some more information about it. This case is likely a real bug in the kernel that's being caught rather than a false positive. I attached a patch for logging the values before the overflow occurs which might be helpful to figure out what's going on (can add it with the others in the PKGBUILD with patch -p1). It assigns the maximum possible value in some places via (u64)-1 and it might be what's triggering this.

It will probably spam the logs quite a bit when there's disk activity, but the only bit that's actually relevant is whatever it logs directly before the SIZE_OVERFLOW failure. Could get saner logging by branching on an overflow check but it's not really worth the trouble.

I tried building from ABS with the patch included but grsecurity-3.1-4.2.6-201511211841.patch is 404ing. Was it removed because of these issues?

No, the older patches are just always removed. I need to update the package in the repositories.

You just need to change the timestamp variable to 201511232037 and it should work.

Yep, it's u64 size. See attached log - these were the very last lines in the journal before reboot.

The ext4 issue should be fixed in the upcoming patch, see https://forums.grsecurity.net/viewtopic.php?f=3&t=4324#p15800

Experiencing the same issue when attempting to copy a large file across hard drives.

~ > mount | grep btrfs
/dev/mapper/crypt on / type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache,commit=300,subvolid=5,subvol=/)

https://gist.githubusercontent.com/Manouchehri/08ad11ea73accb2df108/raw/799cc66c2757af112e9d53553fa00f480c1d7184/dmesg.log

What's the last known good kernel? 4.2.6.201511182042-1 or 4.2.6.201511141543-1?

Downgrading to 4.2.6.201511182042-1 seems to have done the trick for the moment.

~ > sudo pacman -U /var/cache/pacman/pkg/linux-grsec-4.2.6.201511182042-1-x86_64.pkg.tar.xz
~ > reboot
~ > uname -a
Linux archbox 4.2.6.201511182042-1-grsec #1 SMP PREEMPT Wed Nov 18 23:28:18 EST 2015 x86_64 GNU/Linux

there's a proposed fix on the btrfs list now: http://marc.info/?t=144862133900003&r=1&w=2

The original fix wasn't complete but I've tested the revised one with a btrfs loop filesystem and at the very least the basic SQLite test suite passes. It looks quite sane to me (i.e. it won't do anything bad) but there could be overflows left.

Anyway, I included the revised patch in the current package so it's my fault if anything horrible happens :).

https://projects.archlinux.org/svntogit/community.git/tree/trunk/btrfs-overflow.patch?h=packages/linux-grsec

Thanks Daniel, 4.2.6.201511282239-1 looks good on my end.

I may have spoken too soon.

Chromium has crashed my system twice in the past hour. Not sure if it's related; my logs are missing information about the crash, so unfortunately I don't have any more details.