Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

lid argument [4.840690] exe (993) used greatest stack depth: 12872 bytes left Thank you! ср, 13 июн. 2018 г. в 0:35, Ernesto A. Fernández : > > Hi: > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > Hello, > > > > > [1] https:/

Re: PROBLEM: [kernel BUG at fs/fat/inode.c:162] when writing to a broken VFAT

Thank you, it works! сб, 2 июн. 2018 г. в 14:19, OGAWA Hirofumi : > > Anatoly Trosinenko writes: > > > Description: > > > > Writing to some file on a broken VFAT partition causes kernel bug > > Thanks. This patch should fix this issue. > -- > OGAWA Hirofu

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

Hi, thank you! Excuse me for disturbance. вс, 3 июн. 2018 г. в 21:50, Ernesto A. Fernández : > > Hi, thank you for your report. > > On Sun, Jun 03, 2018 at 06:52:19PM +0300, Anatoly Trosinenko wrote: > > How to reproduce: > > 1. Take kernel source v4.17-rc7 > >

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

y been added to the -mm tree. > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > Now, when mounting the attached hfsplus_16mb_segv to /mnt and > > performing `dd if=/dev/zero of=/mnt/xyz bs=567879 count=1` I get > > > > [1.646451] BUG: unable

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

Thank you! > This patch returns better error (-EIO) for me. This works for me likewise. > (But note, the corrupted FS image doesn't guarantee POSIX behavior.) Oops, I was just doing some testing and thought that correct behavior for crafted FS is to return arbitrary valid error code (like

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

Thanks for explanation! Best regards, Anatoly вс, 15 июл. 2018 г. в 18:26, OGAWA Hirofumi : > > Anatoly Trosinenko writes: > > >> This patch returns better error (-EIO) for me. > > > > This works for me likewise. > > Thanks for testing. > > >> (Bu

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

8 г. в 21:38, Ernesto A. Fernández : > > On Tue, Jul 10, 2018 at 08:28:37PM +0300, Anatoly Trosinenko wrote: > > Thank you, > > > > When applied this single patch on v4.18-rc4 and performed "echo > > > /mnt/xyz" on hfsplus_16mb_hang image, I get about 14 pairs of l

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

s) Thanks, Anatoly пн, 9 июл. 2018 г. в 23:35, Ernesto A. Fernández : > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > And when I mount hfsplus_16mb_hang and perform `echo > /mnt/xyz`, it hangs. > > I just sent you a patch for this final report. Let me know if it works > for you.

Unlinking a file on a broken UDF image causes kernel BUG

When unlinking a file on a fuzzed UDF image, the kernel BUG is triggered. How to reproduce (with kvm-xfstests): 1) Checkout udf/for_next (commit 3df77b04f) 2) Copy x86_64-config-4.14 to .config, execute `make olddefconfig`, then enable UDF support and compile the kernel 3) Copy the attached

XFS: Hang and dmesg flood on mounting invalid FS image

Hello, When mounting a broken XFS image, the kernel hangs and floods dmesg with stack traces. How to reproduce with kvm-xfstests: 1) Checkout v4.19, copy x86_64-config-4.14 to .config, `make olddefconfig` and compile 2) Unpack the attached image (128 Mb uncompressed) to /tmp/kvm-xfstests-$USER

Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image

t... # 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 : > > On Sun, 28 Oct 2018, Anatoly Trosinenko wrote: > > > Hello, > > > > W

Re: XFS: Hang and dmesg flood on mounting invalid FS image

> How did the corruption occur? It is a fuzzed image. Most probably, it was artificially "patched" by fuzzer. Or do you mean "what particular bytes were changed"? Best regards Anatoly пн, 29 окт. 2018 г. в 4:32, Dave Chinner : > > On Sun, Oct 28, 2018 at 08:50:4

Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image

Tested in fresh torvalds/master branch. Thank you! Best regards Anatoly пн, 29 окт. 2018 г. в 19:03, Nicolas Pitre : > > 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

NFSd: NULL-dereference when writing to v4_end_grace when server is not yet started

Hello, When manually exploring the kernel NFSd feature, I have stumbled upon a NULL-dereference when writing to v4_end_grace when server is not yet started. How to reproduce with kvm-xfstests: 1) Checkout fresh master Linux branch (tested with commit e195ca6cb) 2) Copy x84_64-config-4.14 to

Re: [UDF] BUG: KASAN: slab-out-of-bounds in iput+0x8df/0xa80

Thank you! Best regards Anatoly чт, 6 сент. 2018 г. в 19:12, Jan Kara : > > On Thu 28-06-18 22:48:51, Anatoly Trosinenko wrote: > > Mounting broken UDF image causes KASAN warning on v4.18-rc2. > > > > How to reproduce: > > 1. Compile v4.18-rc2 kernel with the

Re: NULL pointer dereference when writing fuzzed data to /dev/uhid

> fuzzed data is hard to discriminate from valid data. Just in case it can be helpful... If it is about manually "parsing" descriptors to understand what is wrong by hands, then maybe Kaitai Struct parser generator can help. I understand it is probably not suited well for in-kernel binary

Re: NULL pointer dereference when writing fuzzed data to /dev/uhid

Thank you for the explanation! Best regards Anatoly пн, 14 янв. 2019 г. в 17:55, Benjamin Tissoires : > > On Mon, Jan 14, 2019 at 3:23 PM Anatoly Trosinenko > wrote: > > > > > fuzzed data is hard to discriminate from valid data. > > > > Just in case it can b

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

s) Thanks, Anatoly пн, 9 июл. 2018 г. в 23:35, Ernesto A. Fernández : > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > And when I mount hfsplus_16mb_hang and perform `echo > /mnt/xyz`, it hangs. > > I just sent you a patch for this final report. Let me know if it works > for you.

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

8 г. в 21:38, Ernesto A. Fernández : > > On Tue, Jul 10, 2018 at 08:28:37PM +0300, Anatoly Trosinenko wrote: > > Thank you, > > > > When applied this single patch on v4.18-rc4 and performed "echo > > > /mnt/xyz" on hfsplus_16mb_hang image, I get about 14 pairs of l

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

lid argument [4.840690] exe (993) used greatest stack depth: 12872 bytes left Thank you! ср, 13 июн. 2018 г. в 0:35, Ernesto A. Fernández : > > Hi: > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > Hello, > > > > > [1] https:/

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

y been added to the -mm tree. > > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > > Now, when mounting the attached hfsplus_16mb_segv to /mnt and > > performing `dd if=/dev/zero of=/mnt/xyz bs=567879 count=1` I get > > > > [1.646451] BUG: unable

Re: PROBLEM: [kernel BUG at fs/fat/inode.c:162] when writing to a broken VFAT

Thank you, it works! сб, 2 июн. 2018 г. в 14:19, OGAWA Hirofumi : > > Anatoly Trosinenko writes: > > > Description: > > > > Writing to some file on a broken VFAT partition causes kernel bug > > Thanks. This patch should fix this issue. > -- > OGAWA Hirofu

Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

Hi, thank you! Excuse me for disturbance. вс, 3 июн. 2018 г. в 21:50, Ernesto A. Fernández : > > Hi, thank you for your report. > > On Sun, Jun 03, 2018 at 06:52:19PM +0300, Anatoly Trosinenko wrote: > > How to reproduce: > > 1. Take kernel source v4.17-rc7 > >

NFSd: NULL-dereference when writing to v4_end_grace when server is not yet started

Hello, When manually exploring the kernel NFSd feature, I have stumbled upon a NULL-dereference when writing to v4_end_grace when server is not yet started. How to reproduce with kvm-xfstests: 1) Checkout fresh master Linux branch (tested with commit e195ca6cb) 2) Copy x84_64-config-4.14 to

XFS: Hang and dmesg flood on mounting invalid FS image

Hello, When mounting a broken XFS image, the kernel hangs and floods dmesg with stack traces. How to reproduce with kvm-xfstests: 1) Checkout v4.19, copy x86_64-config-4.14 to .config, `make olddefconfig` and compile 2) Unpack the attached image (128 Mb uncompressed) to /tmp/kvm-xfstests-$USER

Re: XFS: Hang and dmesg flood on mounting invalid FS image

> How did the corruption occur? It is a fuzzed image. Most probably, it was artificially "patched" by fuzzer. Or do you mean "what particular bytes were changed"? Best regards Anatoly пн, 29 окт. 2018 г. в 4:32, Dave Chinner : > > On Sun, Oct 28, 2018 at 08:50:4

Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image

t... # 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 : > > On Sun, 28 Oct 2018, Anatoly Trosinenko wrote: > > > Hello, > > > > W

Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image

Tested in fresh torvalds/master branch. Thank you! Best regards Anatoly пн, 29 окт. 2018 г. в 19:03, Nicolas Pitre : > > 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

Unlinking a file on a broken UDF image causes kernel BUG

When unlinking a file on a fuzzed UDF image, the kernel BUG is triggered. How to reproduce (with kvm-xfstests): 1) Checkout udf/for_next (commit 3df77b04f) 2) Copy x86_64-config-4.14 to .config, execute `make olddefconfig`, then enable UDF support and compile the kernel 3) Copy the attached

NULL pointer dereference when writing fuzzed data to /dev/uhid

Hello, When writing the attached file to /dev/uhid, a NULL dereference occurs in kernel. As I understand, the problem is not UHID-specific, but is related to HID subsystem. How to reproduce: 1) Checkout the fresh master branch of the Linux kernel (tested on commit 96d4f267e) 2) Compile it with

Re: NULL pointer dereference when writing fuzzed data to /dev/uhid

dereferences. Best regards Anatoly пт, 4 янв. 2019 г. в 16:25, Benjamin Tissoires : > > Hi Anatoly, > > > On Fri, Jan 4, 2019 at 1:32 PM Anatoly Trosinenko > wrote: > > > > Hello, > > > > When writing the attached file to /dev/uhid, a NULL dereference o

Re: NULL pointer dereference when writing fuzzed data to /dev/uhid

> Would you be able to share the sony.bin file? Sent it in this message. > Did you inject a particular device? If you are asking me, then no, I blindly send fuzzed data with a simple (but quite large and not very meaningful) header. That time it just turned out to be Sony-like descriptor :) Best

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

Thank you! > This patch returns better error (-EIO) for me. This works for me likewise. > (But note, the corrupted FS image doesn't guarantee POSIX behavior.) Oops, I was just doing some testing and thought that correct behavior for crafted FS is to return arbitrary valid error code (like

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

Thanks for explanation! Best regards, Anatoly вс, 15 июл. 2018 г. в 18:26, OGAWA Hirofumi : > > Anatoly Trosinenko writes: > > >> This patch returns better error (-EIO) for me. > > > > This works for me likewise. > > Thanks for testing. > > >> (Bu

Re: [UDF] BUG: KASAN: slab-out-of-bounds in iput+0x8df/0xa80

Thank you! Best regards Anatoly чт, 6 сент. 2018 г. в 19:12, Jan Kara : > > On Thu 28-06-18 22:48:51, Anatoly Trosinenko wrote: > > Mounting broken UDF image causes KASAN warning on v4.18-rc2. > > > > How to reproduce: > > 1. Compile v4.18-rc2 kernel with the