Hello,
When reading a file from a fuzzed cramfs image, unhandled kernel
paging request occurs.
How to reproduce with kvm-xfstests:
1) Checkout the v4.19 tag, copy x86_64-config-4.14 to .config, perform
`make olddefconfig`
2) Enable Cramfs in the config, then compile
3) In the `kvm-xfstests shell` perform:
root@kvm-xfstests:~# mount /vtmp
root@kvm-xfstests:~# mount /vtmp/cramfs.img /mnt
root@kvm-xfstests:~# cat /mnt/xyz
[ 13.984751] BUG: unable to handle kernel paging request at 00000000bc4f563c
[ 13.985476] PGD 8000000078767067 P4D 8000000078767067 PUD 0
[ 13.986052] Oops: 0000 [#1] SMP PTI
[ 13.986343] CPU: 0 PID: 367 Comm: cat Not tainted 4.19.0-xfstests #1
[ 13.986861] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.1-1ubuntu1 04/01/2014
[ 13.987591] RIP: 0010:memcpy_erms+0x6/0x10
[ 13.987930] Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48
c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8
48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40
38 fe
[ 13.989446] RSP: 0018:ffff9acac0953c10 EFLAGS: 00010282
[ 13.989876] RAX: ffff932677601000 RBX: ffff932677601000 RCX: 000000000000000d
[ 13.990458] RDX: 000000000000000d RSI: 00000000bc4f563c RDI: ffff932677601000
[ 13.991038] RBP: 000000000000000d R08: 00000000ffffffff R09: 00000000fffffffc
[ 13.991620] R10: ffff93267bf23638 R11: 0000000000000000 R12: ffffc55241a1d038
[ 13.992201] R13: 000000000000000d R14: ffff93267855d000 R15: 0000000000000ff3
[ 13.992786] FS: 0000000000000000(0000) GS:ffff93267da00000(0063)
knlGS:00000000f7eec800
[ 13.993443] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 13.993913] CR2: 00000000bc4f563c CR3: 000000007853e004 CR4: 0000000000360ef0
[ 13.994496] Call Trace:
[ 13.994706] cramfs_readpage+0x1ee/0x310
[ 13.995032] read_pages+0x128/0x170
[ 13.995324] __do_page_cache_readahead+0x2ba/0x2e0
[ 13.995720] ondemand_readahead+0x248/0x460
[ 13.996066] generic_file_buffered_read+0x494/0x700
[ 13.996472] __vfs_read+0x136/0x190
[ 13.996846] vfs_read+0x9f/0x130
[ 13.997116] ksys_read+0x52/0xc0
[ 13.997386] do_fast_syscall_32+0x9d/0x2f0
[ 13.997725] entry_SYSENTER_compat+0x84/0x96
[ 13.998077] CR2: 00000000bc4f563c
[ 13.998354] ---[ end trace 4763da97df55a7c9 ]---
[ 13.998734] RIP: 0010:memcpy_erms+0x6/0x10
[ 13.999072] Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48
c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8
48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40
38 fe
[ 14.000584] RSP: 0018:ffff9acac0953c10 EFLAGS: 00010282
[ 14.001011] RAX: ffff932677601000 RBX: ffff932677601000 RCX: 000000000000000d
[ 14.001591] RDX: 000000000000000d RSI: 00000000bc4f563c RDI: ffff932677601000
[ 14.002170] RBP: 000000000000000d R08: 00000000ffffffff R09: 00000000fffffffc
[ 14.002750] R10: ffff93267bf23638 R11: 0000000000000000 R12: ffffc55241a1d038
[ 14.003330] R13: 000000000000000d R14: ffff93267855d000 R15: 0000000000000ff3
[ 14.003910] FS: 0000000000000000(0000) GS:ffff93267da00000(0063)
knlGS:00000000f7eec800
[ 14.004569] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 14.005037] CR2: 00000000bc4f563c CR3: 000000007853e004 CR4: 0000000000360ef0
[ 14.005618] BUG: sleeping function called from invalid context at
include/linux/percpu-rwsem.h:34
[ 14.006337] in_atomic(): 0, irqs_disabled(): 1, pid: 367, name: cat
[ 14.006847] INFO: lockdep is turned off.
[ 14.007172] irq event stamp: 1266
[ 14.007448] hardirqs last enabled at (1265): [<ffffffffba692cb9>]
_raw_spin_unlock_irq+0x29/0x40
[ 14.008166] hardirqs last disabled at (1266): [<ffffffffb9e01574>]
trace_hardirqs_off_thunk+0x1a/0x1c
[ 14.008916] softirqs last enabled at (0): [<ffffffffb9e8329a>]
copy_process.part.6+0x76a/0x1ec0
[ 14.009628] softirqs last disabled at (0): [<0000000000000000>]
(null)
[ 14.010229] CPU: 0 PID: 367 Comm: cat Tainted: G D
4.19.0-xfstests #1
[ 14.010857] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.1-1ubuntu1 04/01/2014
[ 14.011582] Call Trace:
[ 14.011790] dump_stack+0x85/0xc0
[ 14.012067] ___might_sleep.cold.13+0xac/0xbc
[ 14.012436] exit_signals+0x1c/0x200
[ 14.012733] do_exit+0xac/0xb00
[ 14.012996] ? ksys_read+0x52/0xc0
[ 14.013279] rewind_stack_do_exit+0x17/0x20
Killed
root@kvm-xfstests:~#
Best regards
Anatoly
On Sun, 28 Oct 2018, Anatoly Trosinenko wrote:
> Hello,
>
> When reading a file from a fuzzed cramfs image, unhandled kernel
> paging request occurs.
Hmmm... It doesn't show up on my test system.
> How to reproduce with kvm-xfstests:
> 1) Checkout the v4.19 tag, copy x86_64-config-4.14 to .config, perform
> `make olddefconfig`
> 2) Enable Cramfs in the config, then compile
> 3) In the `kvm-xfstests shell` perform:
>
> root@kvm-xfstests:~# mount /vtmp
> root@kvm-xfstests:~# mount /vtmp/cramfs.img /mnt
How do I populate /vtmp? Mine is empty at this point. I imagine I should
put the cramfs image somewhere on the host, but I'm not that familiar
withkvm.
Nicolas
> How do I populate /vtmp? Mine is empty at this point. I imagine I should
put the cramfs image somewhere on the host, but I'm not that familiar
withkvm.
Oops, forgot to say, it is the /tmp/kvm-xfstests-$USER directory on
the host (it will be created when you first launch kvm-xfstests and it
is "live", i.e. like NFS, not like "pack to ext4 image then boot and
mount").
> Hmmm... It doesn't show up on my test system.
Mounted it on my host Ubuntu 18.10 amd64, executed `cat /mnt/xyz` and
it was "Killed". Maybe it is something freshly added or
arch-dependent...
# uname -a
Linux trosinenko-pc 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11
15:13:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Best regards
Anatoly
пн, 29 окт. 2018 г. в 6:43, Nicolas Pitre <[email protected]>:
>
> On Sun, 28 Oct 2018, Anatoly Trosinenko wrote:
>
> > Hello,
> >
> > When reading a file from a fuzzed cramfs image, unhandled kernel
> > paging request occurs.
>
> Hmmm... It doesn't show up on my test system.
>
> > How to reproduce with kvm-xfstests:
> > 1) Checkout the v4.19 tag, copy x86_64-config-4.14 to .config, perform
> > `make olddefconfig`
> > 2) Enable Cramfs in the config, then compile
> > 3) In the `kvm-xfstests shell` perform:
> >
> > root@kvm-xfstests:~# mount /vtmp
> > root@kvm-xfstests:~# mount /vtmp/cramfs.img /mnt
>
> How do I populate /vtmp? Mine is empty at this point. I imagine I should
> put the cramfs image somewhere on the host, but I'm not that familiar
> withkvm.
>
>
> Nicolas
On Mon, 29 Oct 2018, Anatoly Trosinenko wrote:
> > How do I populate /vtmp? Mine is empty at this point. I imagine I
> > should put the cramfs image somewhere on the host, but I'm not that
> > familiar withkvm.
>
> Oops, forgot to say, it is the /tmp/kvm-xfstests-$USER directory on
> the host (it will be created when you first launch kvm-xfstests and it
> is "live", i.e. like NFS, not like "pack to ext4 image then boot and
> mount").
OK, I reproduced it. The fix is as follows:
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index f408994fc6..6e000392e4 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -202,7 +202,8 @@ static void *cramfs_blkdev_read(struct super_block *sb, unsigned int offset,
continue;
blk_offset = (blocknr - buffer_blocknr[i]) << PAGE_SHIFT;
blk_offset += offset;
- if (blk_offset + len > BUFFER_SIZE)
+ if (blk_offset > BUFFER_SIZE ||
+ blk_offset + len > BUFFER_SIZE)
continue;
return read_buffers[i] + blk_offset;
}
User space will get a bunch of zeroes rather than an explicit error in
this case. There is just so many ways to corrupt a cramfs image without
detecting it afterwards that I don't think it is worth doing more than
making sure the system won't be compromized.
> > Hmmm... It doesn't show up on my test system.
>
> Mounted it on my host Ubuntu 18.10 amd64, executed `cat /mnt/xyz` and
> it was "Killed". Maybe it is something freshly added or
> arch-dependent...
It actually depends on whether there is something mapped immediately
next to the cramfs cache buffer.
In any case, this is a nice catch. Thank you for reporting it.
Nicolas
Tested in fresh torvalds/master branch. Thank you!
Best regards
Anatoly
пн, 29 окт. 2018 г. в 19:03, Nicolas Pitre <[email protected]>:
>
> On Mon, 29 Oct 2018, Anatoly Trosinenko wrote:
>
> > > How do I populate /vtmp? Mine is empty at this point. I imagine I
> > > should put the cramfs image somewhere on the host, but I'm not that
> > > familiar withkvm.
> >
> > Oops, forgot to say, it is the /tmp/kvm-xfstests-$USER directory on
> > the host (it will be created when you first launch kvm-xfstests and it
> > is "live", i.e. like NFS, not like "pack to ext4 image then boot and
> > mount").
>
> OK, I reproduced it. The fix is as follows:
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index f408994fc6..6e000392e4 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -202,7 +202,8 @@ static void *cramfs_blkdev_read(struct super_block *sb, unsigned int offset,
> continue;
> blk_offset = (blocknr - buffer_blocknr[i]) << PAGE_SHIFT;
> blk_offset += offset;
> - if (blk_offset + len > BUFFER_SIZE)
> + if (blk_offset > BUFFER_SIZE ||
> + blk_offset + len > BUFFER_SIZE)
> continue;
> return read_buffers[i] + blk_offset;
> }
>
> User space will get a bunch of zeroes rather than an explicit error in
> this case. There is just so many ways to corrupt a cramfs image without
> detecting it afterwards that I don't think it is worth doing more than
> making sure the system won't be compromized.
>
> > > Hmmm... It doesn't show up on my test system.
> >
> > Mounted it on my host Ubuntu 18.10 amd64, executed `cat /mnt/xyz` and
> > it was "Killed". Maybe it is something freshly added or
> > arch-dependent...
>
> It actually depends on whether there is something mapped immediately
> next to the cramfs cache buffer.
>
> In any case, this is a nice catch. Thank you for reporting it.
>
>
> Nicolas