grsecurity forums

After enabling qgroups on btrfs file system:

Code: Select all

kernel: PAX: From IP: refcount overflow detected in: rsync:5602, uid/euid: 250/250
kernel: CPU: 2 PID: 5602 Comm: rsync Not tainted 4.4.2-hardened #1
kernel: Hardware name: Hewlett-Packard HP EliteBook 8560w/1631, BIOS 68SVD Ver. F.50 08/04/2014
kernel: task: ffff8801df856480 ti: ffff8801df8572c8 task.ti: ffff8801df8572c8
kernel: RIP: 0010:[<ffffffff9251b1b5>]  [<ffffffff9251b1b5>] btrfs_qgroup_reserve_meta+0x65/0x80
kernel: RSP: 0018:ffffc900087ebca0  EFLAGS: 00000a06
kernel: RAX: 0000000000000000 RBX: ffff880231c9d000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: ffffc900087ebc68 RDI: ffff880231cc2540
kernel: RBP: 000000000002c000 R08: 0000000000000000 R09: ffff8802350001c0
kernel: R10: 0000000000000100 R11: 00000000000000fe R12: 8000000000000000
kernel: R13: ffff880231c9d000 R14: 000000000000000b R15: 000000000002c000
kernel: FS:  000003a67e513700(0000) GS:ffff88023dc80000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00000047347a9fd8 CR3: 0000000012f3a000 CR4: 00000000000606f0
kernel: Stack:
kernel:  0000000000000002 0000000000000201 ffffffff924a007a 0000000000000000
kernel:  0000000000000000 0000000000000000 537e0c59b2a7eab5 ffff88008e9967d0
kernel:  ffffc900087ebd90 0000000000504e37 ffff8801d8a3ec28 ffff880082788c48
kernel: Call Trace:
kernel:  [<ffffffff924a007a>] ? start_transaction+0x33a/0x420
kernel:  [<ffffffff924b3493>] ? btrfs_rename2+0x193/0x910
kernel:  [<ffffffff92213678>] ? vfs_rename+0x5b8/0x910
kernel:  [<ffffffff9220fb01>] ? follow_dotdot_rcu+0xb1/0x170
kernel:  [<ffffffff92218c22>] ? SyS_rename+0x3d2/0x460
kernel:  [<ffffffff92f22ed8>] ? entry_SYSCALL_64_fastpath+0x12/0x88
kernel: Code: 00 00 f7 d8 21 e8 39 c5 75 2c 48 63 f5 48 89 df e8 01 c8 ff ff 85 c0 78 16 f0 01 ab fc 04 00 00 71 09 f0 29 ab fc 04 00 00 cd 04 <eb> 02 31 c0 5b 5d 4c 09 24 24 c3 0f 0b 0f 1f 40 00 66 2e 0f 1f
kernel: PAX: From IP: refcount overflow detected in: rsync:5601, uid/euid: 250/250
kernel: CPU: 4 PID: 5601 Comm: rsync Not tainted 4.4.2-hardened #1
kernel: Hardware name: Hewlett-Packard HP EliteBook 8560w/1631, BIOS 68SVD Ver. F.50 08/04/2014
kernel: task: ffff8801df256180 ti: ffff8801df256fc8 task.ti: ffff8801df256fc8
kernel: RIP: 0010:[<ffffffff9251b1b5>]  [<ffffffff9251b1b5>] btrfs_qgroup_reserve_meta+0x65/0x80
kernel: RSP: 0018:ffffc900087e3d88  EFLAGS: 00000a06
kernel: RAX: 0000000000000000 RBX: ffff880231c9d000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: ffffc900087e3d50 RDI: ffff880231cc2540
kernel: RBP: 0000000000014000 R08: 0000000000000000 R09: ffff8802350001c0
kernel: R10: 0000000000000000 R11: ffff880233316d60 R12: 8000000000000000
kernel: R13: ffff880231c9d000 R14: 0000000000000005 R15: 0000000000014000
kernel: FS:  000003a67e513700(0000) GS:ffff88023dd00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 000000473030a6f8 CR3: 0000000012f3e000 CR4: 00000000000606f0
kernel: Stack:
kernel:  0000000000000002 0000000000000201 ffffffff924a007a c20817f964c63696
kernel:  ffff880233316d60 ffff8801d9f9f768 ffff8800ab184c00 ffff8801d9f9f768
kernel:  0000000000000005 ffff880231c9d000 0000000000000005 ffff8801edc7f650
kernel: Call Trace:
kernel:  [<ffffffff924a007a>] ? start_transaction+0x33a/0x420
kernel:  [<ffffffff924a0632>] ? btrfs_start_transaction_fallback_global_rsv+0x22/0xc0
kernel:  [<ffffffff924ace9f>] ? btrfs_unlink+0x2f/0x100
kernel:  [<ffffffff92212a44>] ? vfs_unlink+0x124/0x1c0
kernel:  [<ffffffff92216981>] ? do_unlinkat+0x2c1/0x360
kernel:  [<ffffffff92f22ed8>] ? entry_SYSCALL_64_fastpath+0x12/0x88
kernel: Code: 00 00 f7 d8 21 e8 39 c5 75 2c 48 63 f5 48 89 df e8 01 c8 ff ff 85 c0 78 16 f0 01 ab fc 04 00 00 71 09 f0 29 ab fc 04 00 00 cd 04 <eb> 02 31 c0 5b 5d 4c 09 24 24 c3 0f 0b 0f 1f 40 00 66 2e 0f 1f
kernel: PAX: From IP: refcount overflow detected in: emerge:5598, uid/euid: 0/0
kernel: CPU: 0 PID: 5598 Comm: emerge Not tainted 4.4.2-hardened #1
kernel: Hardware name: Hewlett-Packard HP EliteBook 8560w/1631, BIOS 68SVD Ver. F.50 08/04/2014
kernel: task: ffff8801de91e380 ti: ffff8801de91f1c8 task.ti: ffff8801de91f1c8
kernel: RIP: 0010:[<ffffffff9251b1b5>]  [<ffffffff9251b1b5>] btrfs_qgroup_reserve_meta+0x65/0x80
kernel: RSP: 0018:ffffc900087cbcc8  EFLAGS: 00000a06
kernel: RAX: 0000000000000000 RBX: ffff880231c9d000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: ffffc900087cbc90 RDI: ffff880231cc2540
kernel: RBP: 0000000000014000 R08: 0000000000000000 R09: ffff8802350001c0
kernel: R10: 0000000000000000 R11: ffff880233316d60 R12: 8000000000000000
kernel: R13: ffff880231c9d000 R14: 0000000000000005 R15: 0000000000014000
kernel: FS:  0000037577af5700(0000) GS:ffff88023dc00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000037577ae2e60 CR3: 0000000012f36000 CR4: 00000000000606f0
kernel: Stack:
kernel:  0000000000000002 0000000000000201 ffffffff924a007a ffffffff920dc399
kernel:  00000000ffffbe12 0000000000000002 ffff8801ebdfc478 ffff88021f49d908
kernel:  0000000000000005 ffff880231c9d000 0000000000000005 ffff8801ebdfc478
kernel: Call Trace:
kernel:  [<ffffffff924a007a>] ? start_transaction+0x33a/0x420
kernel:  [<ffffffff920dc399>] ? capable_wrt_inode_uidgid+0x59/0x70
kernel:  [<ffffffff924a0632>] ? btrfs_start_transaction_fallback_global_rsv+0x22/0xc0
kernel:  [<ffffffff924ace9f>] ? btrfs_unlink+0x2f/0x100
kernel:  [<ffffffff92212a44>] ? vfs_unlink+0x124/0x1c0
kernel:  [<ffffffff92216981>] ? do_unlinkat+0x2c1/0x360
kernel:  [<ffffffff92f22ed8>] ? entry_SYSCALL_64_fastpath+0x12/0x88
kernel:  [<ffffffff9218c6fb>] ? __context_tracking_enter+0x1b/0x90
kernel: Code: 00 00 f7 d8 21 e8 39 c5 75 2c 48 63 f5 48 89 df e8 01 c8 ff ff 85 c0 78 16 f0 01 ab fc 04 00 00 71 09 f0 29 ab fc 04 00 00 cd 04 <eb> 02 31 c0 5b 5d 4c 09 24 24 c3 0f 0b 0f 1f 40 00 66 2e 0f 1f


i think this is a real bug, please report it to the btrfs developers. what happens is that btrfs_root.qgroup_meta_rsv is an atomic_t which is an int type underneath and you managed to trigger an atomic_add on it that caused a signed overflow (ebp held the increment itself, we don't know from the logs the pre-increment value of the qgroup_meta_rsv field). to me this indicates that this quantity may not always fit 32 bits and would probably have to become atomic64_t.

Hello!

Could it be that I hit the same bug or is it independant? (ArchLinux with linux-grsec)

Code: Select all

Mar 10 16:58:22 kernel: PAX: From 131.159.195.35: refcount overflow detected in: cp:5748, uid/euid: 0/0
Mar 10 16:58:22 kernel: CPU: 0 PID: 5748 Comm: cp Not tainted 4.4.4.201603032158-1-grsec #1
Mar 10 16:58:22 kernel: Hardware name: Red Hat KVM, BIOS seabios-1.7.5-11.el7 04/01/2014
Mar 10 16:58:22 kernel: task: ffff8801b79cbf00 ti: ffff8801b79cc928 task.ti: ffff8801b79cc928
Mar 10 16:58:22 kernel: RIP: 0010:[<ffffffffc02a26a3>]  [<ffffffffc02a26a3>] btrfs_qgroup_reserve_meta+0x73/0x90 [btrfs]
Mar 10 16:58:22 kernel: RSP: 0018:ffffc9000574baf8  EFLAGS: 00000a06
Mar 10 16:58:22 kernel: RAX: 0000000000000000 RBX: ffff8801a1e0e868 RCX: 0000000000000000
Mar 10 16:58:22 kernel: RDX: ffff8801b7d3bbe8 RSI: ffffc9000574bab0 RDI: ffff8800bad78d68
Mar 10 16:58:22 kernel: RBP: ffffc9000574bb08 R08: 0000000000000000 R09: ffff88009c010048
Mar 10 16:58:22 kernel: R10: ffff8801a1e0e868 R11: 0000000000080000 R12: 0000000000008000
Mar 10 16:58:22 kernel: R13: ffff8800bad78000 R14: 0000000000000002 R15: ffff88009d4f2efc
Mar 10 16:58:22 kernel: FS:  000003ac65d8c700(0000) GS:ffff8801bfc00000(0000) knlGS:0000000000000000
Mar 10 16:58:22 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 10 16:58:22 kernel: CR2: 00000000006641a8 CR3: 0000000032609000 CR4: 00000000001606f0
Mar 10 16:58:22 kernel: Stack:
Mar 10 16:58:22 kernel:  ffff88009d4f3090 ffff8801a1e0e868 ffffc9000574bb78 ffffffffc02114b9
Mar 10 16:58:22 kernel:  ffff8800bad78148 0000000000000002 01ff88009d4f3090 0000000000001000
Mar 10 16:58:22 kernel:  ffff880100000001 00000000000c0000 0000000000001000 0000000000000150
Mar 10 16:58:22 kernel: Call Trace:
Mar 10 16:58:22 kernel:  [<ffffffffc02114b9>] btrfs_delalloc_reserve_metadata+0x149/0x3d0 [btrfs]
Mar 10 16:58:22 kernel:  [<ffffffffc023f2ab>] __btrfs_buffered_write.isra.5+0x2db/0xec0 [btrfs]
Mar 10 16:58:22 kernel:  [<ffffffffc02488fc>] ? __btrfs_getxattr+0xac/0x150 [btrfs]
Mar 10 16:58:22 kernel:  [<ffffffffc0248ece>] ? btrfs_getxattr+0x5e/0x80 [btrfs]
Mar 10 16:58:22 kernel:  [<ffffffffc024509b>] btrfs_file_write_iter+0x2ab/0x9e0 [btrfs]
Mar 10 16:58:22 kernel:  [<ffffffffb21ae229>] __vfs_write+0x109/0x140
Mar 10 16:58:22 kernel:  [<ffffffffb21aef35>] vfs_write+0xe5/0x280
Mar 10 16:58:22 kernel:  [<ffffffffb21b0099>] SyS_write+0x59/0xd0
Mar 10 16:58:22 kernel:  [<ffffffffb25fb970>] entry_SYSCALL_64_fastpath+0x12/0x86
Mar 10 16:58:22 kernel: Code: 44 21 e0 41 39 c4 75 32 49 63 f4 48 89 df e8 b5 cb ff ff 85 c0 78 18 f0 44 01 a3 fc 04 00 00 71 0a f0 44 29 a3 fc 04 00 00 cd 04 <eb> 02 31 c0 5b 41 5c 5d 48 0f ba 2c 24 3f c3 0f 0b 66 90 66 2e

Currently, I cannot copy a directory tree from a btrfs subvolume onto a tree with several mounted btrfs subvolumes in it. Is there a trivial way to "safely" get around this problem temporarily?

Thank you

it's the same underlying problem and one of you guys should really work it out with upstream developers because we won't be solve this ourselves. as for a workaround, however unsafe it may be, you can just disable the REFCOUNT kernel config option.