i hit another size overflow error using current hardened-source: --8<-- [ 32.818724] PAX: size overflow detected in function drbd_md_read drivers/block/drbd/drbd_main.c:3308 cicus.1150_220 max, count: 141, decl: al_offset; num: 0; context: drbd_md; [ 32.863179] CPU: 2 PID: 5410 Comm: drbdsetup Not tainted 4.6.3-hardened-r2-dom0-kvm-at-gw24 #5 [ 32.863181] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./J1900N-D3V, BIOS F1 01/22/2014 [ 32.863183] 0000000000000006 ffffffffb64d6f54 ffff88043fd0d050 ffffffffb6ca6eb2 [ 32.863188] 0000000000000cec ffffffffb61e916e ffff88041fc32978 ffff88041fc32800 [ 32.863192] ffffc90000ffba80 ffff88041f805000 ffffffffb65f6a33 000000000000003c [ 32.863195] Call Trace: [ 32.863204] [<ffffffffb64d6f54>] ? dump_stack+0x47/0x6f [ 32.863208] [<ffffffffb61e916e>] ? report_size_overflow+0x35/0x7b [ 32.863213] [<ffffffffb65f6a33>] ? drbd_md_read+0x26e/0x5c4 [ 32.863217] [<ffffffffb650c846>] ? lc_create+0x1d0/0x239 [ 32.863220] [<ffffffffb6602ae4>] ? drbd_adm_attach+0x39b/0xfd8 [ 32.863223] [<ffffffffb6602ae4>] ? drbd_adm_attach+0x39b/0xfd8 [ 32.863226] [<ffffffffb64cf0c5>] ? gr_task_acl_is_capable+0x1f/0x173 [ 32.863231] [<ffffffffb68603a6>] ? genl_family_rcv_msg+0x2a7/0x349 [ 32.863234] [<ffffffffb6860482>] ? genl_rcv_msg+0x3a/0x5f [ 32.863237] [<ffffffffb6860482>] ? genl_rcv_msg+0x3a/0x5f [ 32.863240] [<ffffffffb6860448>] ? genl_family_rcv_msg+0x349/0x349 [ 32.863243] [<ffffffffb685fc8c>] ? netlink_rcv_skb+0x60/0x10a [ 32.863246] [<ffffffffb686003b>] ? genl_rcv+0x1f/0x34 [ 32.863248] [<ffffffffb685e23d>] ? netlink_unicast+0x132/0x1e3 [ 32.863251] [<ffffffffb685eb4b>] ? netlink_sendmsg+0x41f/0x440 [ 32.863255] [<ffffffffb67fad19>] ? sock_sendmsg+0x38/0x57 [ 32.863257] [<ffffffffb67fada9>] ? sock_write_iter+0x71/0x94 [ 32.863260] [<ffffffffb61e0139>] ? __vfs_write+0xc0/0xf9 [ 32.863263] [<ffffffffb61e0407>] ? vfs_write+0x17a/0x2b8 [ 32.863266] [<ffffffffb61e062a>] ? sys_write+0x4c/0x99 [ 32.863269] [<ffffffffb61e062a>] ? sys_write+0x4c/0x99 [ 32.863273] [<ffffffffb6990353>] ? entry_SYSCALL_64_fastpath+0x13/0xa3 --8<--
FYI: hardened-sources-4.5.7-r7 works (not hit by size overflow in drbd).
this is an integer conversion problem in drbd: 3308 »·······bdev->md.al_offset = be32_to_cpu(buffer->al_offset); 3309 »·······bdev->md.bm_offset = be32_to_cpu(buffer->bm_offset); the left hand side fields are s32 whereas the right hand side ones are u32 so there can be runtime values that cannot be converted without a value loss. i'm not sure whether this code works as intended so feel free to take it up with the drbd maintainers and we'll disable tracking these fields in the size overflow plugin for now.
(In reply to PaX Team from comment #2) > this is an integer conversion problem in drbd: > > 3308 »·······bdev->md.al_offset = be32_to_cpu(buffer->al_offset); > 3309 »·······bdev->md.bm_offset = be32_to_cpu(buffer->bm_offset); > > the left hand side fields are s32 whereas the right hand side ones are u32 > so there can be runtime values that cannot be converted without a value > loss. i'm not sure whether this code works as intended so feel free to take > it up with the drbd maintainers and we'll disable tracking these fields in > the size overflow plugin for now. is this fixed in grsecurity-3.1-4.6.4-201607112205.patch ?
(In reply to Anthony Basile from comment #3) > is this fixed in grsecurity-3.1-4.6.4-201607112205.patch ? it's 'fixed' in that we turned off size overflow instrumentation on assignments to these fields, so end users should be fine. the proper solution would be for upstream to figure out why they mix different integer types here and preferably stick to one type only so that we can reenable the instrumentation.
(In reply to PaX Team from comment #4) > (In reply to Anthony Basile from comment #3) > > is this fixed in grsecurity-3.1-4.6.4-201607112205.patch ? > > it's 'fixed' in that we turned off size overflow instrumentation on > assignments to these fields, so end users should be fine. the proper > solution would be for upstream to figure out why they mix different integer > types here and preferably stick to one type only so that we can reenable the > instrumentation. yeah not idea, but okay for a workaround until drbd people address this. mixing types sometimes has its place, but i get the feeling they're just not being careful here.
Happened with me today, on kernel 4.6.5-hardened...
(In reply to Mark (voidzero) from comment #6) > Happened with me today, on kernel 4.6.5-hardened... can you post the kernel logs?
