PAX: size overflow detected in function diMount fs/jfs/jfs_i

[g66]

This problem has persisted since 4.2.6-201511182042 and is still there with 4.4.3.201603012143 making
it unable to boot:

fsck.jfs version 1.1.15, 04-Mar-2011
processing started: 3/3/2016 18:30:56
The current device is: /dev/mapper/root
Block size in bytes: 4096
Filesystem size in blocks: 52396158
**Phase 0 - Replay Journal Log
Filesystem is clean
:: mounting '/dev/mapper/root' on real root

PAX: size overflow detected in function diMount fs/jfs/jfs_imap.c:143
cicus.261_68 max, count: 21, decl: inofree; num 0; context: iagctl;
Killed
You are now being dropped into an emergency shell
sh: can't access tty; job control turned off

This is all which is printed to screen.

[PaX Team]

this looks like an upstream kernel problem, iagctl.inofree is an int whereas iagctl_disk.inofree is an u32 and the size overflow instrumentation caught an out-of-range u32 value being converted to an int. my guess is that struct iagctl should have all u32 members but only the jfs developers can tell for sure and make the proper changes throughout the jfs codebase.

[shaggy]

I'm the jfs maintainer and this problem was brought to my attention.

Valid values of iagctl.inofree should either be less than 1048576 or -1. Maybe the -1 is the problem. I'm not familiar with how PAX works, so I don't know if there is a simpler solution to this problem than just changing the structure members to be unsigned. Trying to make the __le32 counterparts signed would be more complicated. Some other kernel code introduced a sle32 type and helpers, but they are not in a common header file.

[PaX Team]

hi, thanks for dropping by . the size overflow feature that triggered here adds runtime checks for all kinds of integer operations that are somehow related to sizes of memory allocations or copying to/from userland (the gcc plugin discovers all this after an initial seed set of manually marked functions, see the blog for the gory details: viewtopic.php?f=7&t=3043).

the code that triggered a runtime violation of a type range mismatch is this:

Code: Select all

imap->im_agctl[index].inofree = le32_to_cpu(dinom_le->in_agctl[index].inofree);

at the type level this is a u32->int assignment and whatever value there was in the u32 type, didn't fit the int type. if -1 (stored as UINT_MAX) was in there, then that'd certainly explain the symptoms. as for fixing it, we can either remove this field from instrumentation (we usually do this if the object in question isn't actually allocation/copy size related) or we can patch the code so that proper/consistent types are used (this is preferable as cleaning up mismatched types can uncover further problems along the way too).

[g66]

I noticed a minor mistake in my original post. The last working version is 4.2.6-201511182042.
Every linux-grsec kernel since has not booted.

[Rick]

Hello, I ran into this bug as well, and was wondering whether there was an issue opened in some bug tracking facility that I could track.

It looks like a reasonably easy to fix bug, and I might even take a shot myself, but my C is pretty rusty....

I'm looking forward to any kind of update -- g66, did you follow this issue up?