Bug 108531
| Summary: | btrfs crashes (with grsec)/has size overflow in extend_map (reading from written/moved files) | ||
|---|---|---|---|
| Product: | File System | Reporter: | alex (devkral) |
| Component: | btrfs | Assignee: | Josef Bacik (josef) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | high | CC: | dsterba, kernel_bugs, pageexec, szg00000 |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.2.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | output kernel | ||
I had same bug. I reported it there https://bugs.gentoo.org/show_bug.cgi?id=567046 After I applied this patch https://projects.archlinux.org/svntogit/community.git/tree/trunk/btrfs-overflow.patch?h=packages/linux-grsec btrfs didn't crash anymore. But as you can see in my bug report on gentoo em->block_len and merge->block_len has many times value ffffffffffffffff I can reproduce it locally, still investigating. Patch is included in new Gentoo packages. Did you know if values 0xffffffffffffffff on em->block_len and merge->block_len are correct? Or this patch is only workaround to handle overflow in filesystem without crash? |
Created attachment 195591 [details] output kernel Trigger: I ran my backup script accidentally over a directory where a program of mine heavily wrote in files,moved them. This seems to have triggered a size overflow in btrfs/extend_map.c (line 238) which was reported and blocked by pax. It seems that reading from written or moved files can trigger this bug. I don't know exactly if it is a btrfs upstream bug or a grsec bug. My linux distro is Archlinux, with the exact kernel version: linux-grsec 4.2.6.201511232037-1.