PAX: size overflow detected in function pnp_assign_resources

[foxxx0]

Hey guys,

I've been running grsec on most of my machines for a couple of months now and I am pretty happy with it.

However I couldn't get grsec running on my router box, which just dies immediately with a kernel panic.
Finally I was able to setup a serial console on boot to catch the full trace of what's happening:

Code: Select all

Loading ../vmlinuz-linux-grsec... ok
Loading ../intel-ucode.img...ok
Loading ../initramfs-linux-grsec.img...ok
[    0.289594] PAX: size overflow detected in function pnp_assign_resources drivers/pnp/manager.c:230 cicus.41_50 max, count: 1, decl: pnp_add_dma_resource; num: 2; context: fndecl;
[    0.480686] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.480686]
[    0.590516] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.7.201606280009-1-grsec #1
[    0.682484] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-S0891/MS-S0891, BIOS ES089IMS.210 01/22/2015
[    0.799482]  0000000000000002 0000000000000000 0000000000000086 0000000000000000
[    0.888839]  ffffc9000001ba38 ffffffffaf329863 ffff880216124008 0000000000000000
[    0.978159]  ffffffffaf950170 ffffc9000001bad8 ffffc9000001bac8 ffffffffaf14557a
[    1.067489] Call Trace:
[    1.096927]  [<ffffffffaf329863>] dump_stack+0x76/0xd3
[    1.158602]  [<ffffffffaf14557a>] panic+0xdb/0x25c
[    1.216110]  [<ffffffffaf0759f0>] do_exit+0xb90/0xba0
[    1.276737]  [<ffffffffaf075aa7>] do_group_exit+0x37/0xc0
[    1.341526]  [<ffffffffaf1e7b08>] report_size_overflow+0x78/0x90
[    1.413593]  [<ffffffffaf40e19f>] pnp_assign_resources+0x72f/0xaf0
[    1.487742]  [<ffffffffaf3310ab>] ? rb_insert_color+0x1cb/0x310
[    1.558778]  [<ffffffffaf27af2a>] ? kernfs_activate+0x8a/0x100
[    1.628764]  [<ffffffffaf27a786>] ? kernfs_link_sibling+0x96/0xd0
[    1.701864]  [<ffffffffaf40e78e>] pnp_auto_config_dev+0x3e/0xb0
[    1.772889]  [<ffffffffaf40e825>] pnp_activate_dev+0x25/0x60
[    1.840796]  [<ffffffffaf40c61b>] pnp_device_probe+0xab/0xf0
[    1.908713]  [<ffffffffaf478162>] ? devices_kset_move_last+0x52/0x70
[    1.984931]  [<ffffffffaf47c75b>] driver_probe_device+0x11b/0x380
[    2.058039]  [<ffffffffaf47ca5c>] __driver_attach+0x9c/0xb0
[    2.124905]  [<ffffffffaf47c9c0>] ? driver_probe_device+0x380/0x380
[    2.200094]  [<ffffffffaf479e24>] bus_for_each_dev+0x94/0x100
[    2.269041]  [<ffffffffaf47bdcd>] driver_attach+0x1d/0x40
[    2.333827]  [<ffffffffaf47b84d>] bus_add_driver+0x11d/0x230
[    2.401735]  [<ffffffffafe4fb02>] ? univ8250_console_init+0x3c/0x3c
[    2.476924]  [<ffffffffaf47d387>] driver_register+0x57/0xe0
[    2.543790]  [<ffffffffaf40c3f0>] pnp_register_driver+0x20/0x40
[    2.614818]  [<ffffffffaf443ed0>] serial8250_pnp_init+0x10/0x30
[    2.685846]  [<ffffffffafe4fb72>] serial8250_init+0x70/0x178
[    2.753752]  [<ffffffffafe4fb02>] ? univ8250_console_init+0x3c/0x3c
[    2.828940]  [<ffffffffaf0004eb>] do_one_initcall+0x9b/0x1c0
[    2.896847]  [<ffffffffafe12a16>] ? initcall_blacklist+0x107/0x107
[    2.970996]  [<ffffffffafe134c3>] kernel_init_freeable+0x183/0x225
[    3.045148]  [<ffffffffaf678320>] ? rest_init+0xa8/0xa8
[    3.107848]  [<ffffffffaf678329>] kernel_init+0x9/0x100
[    3.170557]  [<ffffffffaf687b3e>] ret_from_fork+0x3e/0x70
[    3.235345]  [<ffffffffaf678320>] ? rest_init+0xa8/0xa8
[    3.298056] Kernel Offset: 0x2e000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    3.429229] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    3.429229]
[    3.548412] tsc: Refined TSC clocksource calibration: 3392.144 MHz
[    3.622512] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x30e5517d4e4, max_idle_ns: 440795261668 ns

Judging by the results I got from googling "PAX: size overflow detected" this is considered a bug in grsec and "simply" needs to be fixed.

Would be great to get some feedback.

[PaX Team]

this is an integer truncation bug in the upstream kernel (not grsec), the following patch should fix it:

Code: Select all

--- a/drivers/pnp/base.h 2015-06-22 11:14:33.380675235 +0200
+++ b/drivers/pnp/base.h  2016-07-12 10:17:03.951990733 +0200
@@ -163,7 +163,7 @@ struct pnp_resource *pnp_add_resource(st
                                      struct resource *res);
 struct pnp_resource *pnp_add_irq_resource(struct pnp_dev *dev, int irq,
                                          int flags);
-struct pnp_resource *pnp_add_dma_resource(struct pnp_dev *dev, int dma,
+struct pnp_resource *pnp_add_dma_resource(struct pnp_dev *dev, resource_size_t dma,
                                          int flags);
 struct pnp_resource *pnp_add_io_resource(struct pnp_dev *dev,
                                         resource_size_t start,
--- a/drivers/pnp/resource.c     2015-04-13 11:21:28.578616034 +0200
+++ b/drivers/pnp/resource.c      2016-07-12 10:23:08.274441934 +0200
@@ -543,7 +543,7 @@ struct pnp_resource *pnp_add_irq_resourc
        return pnp_res;
 }

-struct pnp_resource *pnp_add_dma_resource(struct pnp_dev *dev, int dma,
+struct pnp_resource *pnp_add_dma_resource(struct pnp_dev *dev, resource_size_t dma,
                                          int flags)
 {
        struct pnp_resource *pnp_res;
@@ -551,7 +551,7 @@ struct pnp_resource *pnp_add_dma_resourc

        pnp_res = pnp_new_resource(dev);
        if (!pnp_res) {
-               dev_err(&dev->dev, "can't add resource for DMA %d\n", dma);
+               dev_err(&dev->dev, "can't add resource for DMA %lld\n", dma);
                return NULL;
        }



[foxxx0]

Wow, that was quick.

Building the kernel took a while and I was finally able to test it: works perfectly
Awesome work you guys.

How do we proceed on this? I am about to submit this bug to upstream kernel if there are no objections?!

[PaX Team]

it's up to the reporters to work with upstream since most of the time they're the only ones who can reproduce the problem (if at all) and thus work with upstream to verify any potential fix (and this way they'll also get proper credit for reporting & testing). there're also times when we can't fix the problem ourselves as the code requires domain specific knowledge we just don't have (e.g., the drbd report we got yesterday), in that case we'll redirect such reporters to upstream right away.

[foxxx0]

Alright, here is the according upstream Kernel Bug: https://bugzilla.kernel.org/show_bug.cgi?id=123211