Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
> This should be fixed, but > it's not as big an issue as the deadlock. Filesystems usually don't need > to worry about protecting a crafted image from acting weird and causing > damage to itself. I just thought that deadlocking a single thread is not much worse than further damaging already damaged FS and is not very dangerous (since it's not a NULL dereference or something like this). If it is or only malicious image can probably be damaged this way then I have no objections or further requests, so please excuse me for unclear wordings. Thanks, Anatoly вт, 10 июл. 2018 г. в 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 lines > > > > hfsplus: unable to mark blocks free: error -5 > > hfsplus: can't free extent > > > > Then `echo` exits with "No space left on device" error. > > Truncation does not return error codes in hfsplus, hence this weird "No > space left" that comes from somewhere else. This should be fixed, but > it's not as big an issue as the deadlock. Filesystems usually don't need > to worry about protecting a crafted image from acting weird and causing > damage to itself. > > >Then it > > permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds > > with no space left on device (but file *is* created and is cattable). > > I don't know what is safer, but now it doesn't deadlock. :) Maybe it > > is even worth to remount FS r/o, I don't know. (Please excuse me for > > speculations) > > It's not strange that the /mnt/1 file could be created but not written > to, since the first operation doesn't usually require allocating blocks. > > > > > Thanks, > > Anatoly > > OK, I'll take a look at the truncation error codes as soon as I'm done > with the other deadlocks I found. It could take a while. > > Thanks for the testing. > Ernest > > > пн, 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
> This should be fixed, but > it's not as big an issue as the deadlock. Filesystems usually don't need > to worry about protecting a crafted image from acting weird and causing > damage to itself. I just thought that deadlocking a single thread is not much worse than further damaging already damaged FS and is not very dangerous (since it's not a NULL dereference or something like this). If it is or only malicious image can probably be damaged this way then I have no objections or further requests, so please excuse me for unclear wordings. Thanks, Anatoly вт, 10 июл. 2018 г. в 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 lines > > > > hfsplus: unable to mark blocks free: error -5 > > hfsplus: can't free extent > > > > Then `echo` exits with "No space left on device" error. > > Truncation does not return error codes in hfsplus, hence this weird "No > space left" that comes from somewhere else. This should be fixed, but > it's not as big an issue as the deadlock. Filesystems usually don't need > to worry about protecting a crafted image from acting weird and causing > damage to itself. > > >Then it > > permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds > > with no space left on device (but file *is* created and is cattable). > > I don't know what is safer, but now it doesn't deadlock. :) Maybe it > > is even worth to remount FS r/o, I don't know. (Please excuse me for > > speculations) > > It's not strange that the /mnt/1 file could be created but not written > to, since the first operation doesn't usually require allocating blocks. > > > > > Thanks, > > Anatoly > > OK, I'll take a look at the truncation error codes as soon as I'm done > with the other deadlocks I found. It could take a while. > > Thanks for the testing. > Ernest > > > пн, 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
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 lines > > hfsplus: unable to mark blocks free: error -5 > hfsplus: can't free extent > > Then `echo` exits with "No space left on device" error. Truncation does not return error codes in hfsplus, hence this weird "No space left" that comes from somewhere else. This should be fixed, but it's not as big an issue as the deadlock. Filesystems usually don't need to worry about protecting a crafted image from acting weird and causing damage to itself. >Then it > permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds > with no space left on device (but file *is* created and is cattable). > I don't know what is safer, but now it doesn't deadlock. :) Maybe it > is even worth to remount FS r/o, I don't know. (Please excuse me for > speculations) It's not strange that the /mnt/1 file could be created but not written to, since the first operation doesn't usually require allocating blocks. > > Thanks, > Anatoly OK, I'll take a look at the truncation error codes as soon as I'm done with the other deadlocks I found. It could take a while. Thanks for the testing. Ernest > пн, 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
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 lines > > hfsplus: unable to mark blocks free: error -5 > hfsplus: can't free extent > > Then `echo` exits with "No space left on device" error. Truncation does not return error codes in hfsplus, hence this weird "No space left" that comes from somewhere else. This should be fixed, but it's not as big an issue as the deadlock. Filesystems usually don't need to worry about protecting a crafted image from acting weird and causing damage to itself. >Then it > permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds > with no space left on device (but file *is* created and is cattable). > I don't know what is safer, but now it doesn't deadlock. :) Maybe it > is even worth to remount FS r/o, I don't know. (Please excuse me for > speculations) It's not strange that the /mnt/1 file could be created but not written to, since the first operation doesn't usually require allocating blocks. > > Thanks, > Anatoly OK, I'll take a look at the truncation error codes as soon as I'm done with the other deadlocks I found. It could take a while. Thanks for the testing. Ernest > пн, 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
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 lines hfsplus: unable to mark blocks free: error -5 hfsplus: can't free extent Then `echo` exits with "No space left on device" error. Then it permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds with no space left on device (but file *is* created and is cattable). I don't know what is safer, but now it doesn't deadlock. :) Maybe it is even worth to remount FS r/o, I don't know. (Please excuse me for speculations) 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
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 lines hfsplus: unable to mark blocks free: error -5 hfsplus: can't free extent Then `echo` exits with "No space left on device" error. Then it permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds with no space left on device (but file *is* created and is cattable). I don't know what is safer, but now it doesn't deadlock. :) Maybe it is even worth to remount FS r/o, I don't know. (Please excuse me for speculations) 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
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
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
Thank you, now (with just this patch applied on top of v4.18-rc2) it just (asynchronously?) writes `hfsplus: b-tree write err: -5, ino: 3` to dmesg and does not segfaults. пт, 29 июн. 2018 г. в 21:45, Ernesto A. Fernández : > > Hi again: > > A patch for your original report has already 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 to handle kernel NULL pointer dereference > > at 0043 > > I just sent you a patch for this second report. It's really simple, so > it would be great if you could take a look at it and review it yourself. > Otherwise it's not very likely to get picked up. > > Thanks, > Ernest -- С уважением, Анатолий Тросиненко e-mail: anatoly.trosine...@gmail.com
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Thank you, now (with just this patch applied on top of v4.18-rc2) it just (asynchronously?) writes `hfsplus: b-tree write err: -5, ino: 3` to dmesg and does not segfaults. пт, 29 июн. 2018 г. в 21:45, Ernesto A. Fernández : > > Hi again: > > A patch for your original report has already 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 to handle kernel NULL pointer dereference > > at 0043 > > I just sent you a patch for this second report. It's really simple, so > it would be great if you could take a look at it and review it yourself. > Otherwise it's not very likely to get picked up. > > Thanks, > Ernest -- С уважением, Анатолий Тросиненко e-mail: anatoly.trosine...@gmail.com
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
On Fri, Jun 29, 2018 at 03:45:43PM -0300, Ernesto A. Fernández wrote: > Hi again: > > A patch for your original report has already 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 to handle kernel NULL pointer dereference > > at 0043 > > I just sent you a patch for this second report. It's really simple, so > it would be great if you could take a look at it and review it yourself. > Otherwise it's not very likely to get picked up. Never mind, it got picked up already. > > Thanks, > Ernest
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
On Fri, Jun 29, 2018 at 03:45:43PM -0300, Ernesto A. Fernández wrote: > Hi again: > > A patch for your original report has already 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 to handle kernel NULL pointer dereference > > at 0043 > > I just sent you a patch for this second report. It's really simple, so > it would be great if you could take a look at it and review it yourself. > Otherwise it's not very likely to get picked up. Never mind, it got picked up already. > > Thanks, > Ernest
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hi again: A patch for your original report has already 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 to handle kernel NULL pointer dereference > at 0043 I just sent you a patch for this second report. It's really simple, so it would be great if you could take a look at it and review it yourself. Otherwise it's not very likely to get picked up. Thanks, Ernest
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hi again: A patch for your original report has already 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 to handle kernel NULL pointer dereference > at 0043 I just sent you a patch for this second report. It's really simple, so it would be great if you could take a look at it and review it yourself. Otherwise it's not very likely to get picked up. Thanks, Ernest
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hello, > but was the original issue solved? Yes, after removing the suggested line and applying patch [2] on top of v4.17, when I try to mount the original FS image, mount just returns Invalid argument, no kernel NULL pointer dereferences anymore: mount: mounting /dev/sda on /mnt failed: Invalid 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://www.spinics.net/lists/linux-fsdevel/msg125241.html > > > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html > > > > If I get it right, the first patch is already upstreamed in some > > modified form and cannot be applied on top of vanilla v4.17. > > The first part of the patchset was already picked up, but your report > is related to the second part, which is the link at [1]. It should > still apply. > > > When I > > apply the second one I get > > > > $ patch -p1 < ../hfsplus-2.patch > > patching file fs/hfsplus/dir.c > > patching file fs/hfsplus/hfsplus_fs.h > > patching file fs/hfsplus/inode.c > > patching file fs/hfsplus/super.c > > Hunk #3 FAILED at 567. > > Hunk #4 succeeded at 586 (offset 1 line). > > 1 out of 4 hunks FAILED -- saving rejects to file fs/hfsplus/super.c.rej > > $ cat fs/hfsplus/super.c.rej > > --- fs/hfsplus/super.c > > +++ fs/hfsplus/super.c > > @@ -567,11 +547,6 @@ static int hfsplus_fill_super(struct super_block > > *sb, void *data, int silent) > > sbi->nls = nls; > > return 0; > > > > -out_put_hidden_dir: > > - iput(sbi->hidden_dir); > > -out_put_root: > > - dput(sb->s_root); > > - sb->s_root = NULL; > > out_put_alloc_file: > > iput(sbi->alloc_file); > > out_close_attr_tree: > > That's because a patch by Tetsuo Handa added a call to > cancel_delayed_work_sync() after the out_put_hidden_dir tag. Just remove > that line before applying the patch. > > > > > Looks, like manually removing this hunk cannot change anything > > (because of previous return), so just left as is. > > Ok, that should be enough for testing. The rest of your mail seems like a > separate bug report, though. I'll take a look at it, but was the original > issue solved? > > > > > 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 to handle kernel NULL pointer dereference > > at 0043 > > [1.64] PGD 1d4d2067 P4D 1d4d2067 PUD 1d4bc067 PMD 0 > > [1.646870] Oops: [#1] SMP NOPTI > > [1.647002] Modules linked in: > > [1.647209] CPU: 0 PID: 991 Comm: init Not tainted 4.17.0+ #1 > > [1.647291] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > BIOS 1.10.2-1ubuntu1 04/01/2014 > > [1.647456] RIP: 0010:hfsplus_bnode_put+0x9/0xc0 > > [1.647522] RSP: 0018:b750409b7a58 EFLAGS: 0282 > > [1.647607] RAX: a3b31e713000 RBX: 0a00 RCX: > > 1100 > > [1.647696] RDX: RSI: 85ca56d0 RDI: > > fffb > > [1.647787] RBP: a3b31d473288 R08: R09: > > b750409b7960 > > [1.647877] R10: R11: a3b31df0e618 R12: > > b750409b7ad0 > > [1.647967] R13: a3b31d473180 R14: a3b31d432a00 R15: > > 000a > > [1.648089] FS: 01dd48c0() GS:a3b31f80() > > knlGS: > > [1.648192] CS: 0010 DS: ES: CR0: 80050033 > > [1.648268] CR2: 0043 CR3: 1d4c4000 CR4: > > 06f0 > > [1.648406] Call Trace: > > [1.648883] hfsplus_brec_find+0x3c/0x150 > > [1.648970] ? hfsplus_brec_remove+0x160/0x160 > > [1.649037] hfsplus_ext_read_extent.part.6+0xba/0x190 > > [1.649118] ? clean_bdev_aliases+0x81/0x1d0 > > [1.649178] hfsplus_file_extend+0x16b/0x3a0 > > [1.649238] hfsplus_get_block+0x60/0x250 > > [1.649293] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649352] __block_write_begin_int+0x134/0x550 > > [1.649414] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649476] ? percpu_counter_add_batch+0x48/0x60 > > [1.649537] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649596] block_write_begin+0x3f/0xa0 > > [1.649652] cont_write_begin+0x232/0x330 > > [1.649713] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649776] hfsplus_write_begin+0x2f/0x70 > > [1.649834] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649902] generic_perform_write+0xb1/0x1b0 > > [1.649965] __generic_file_write_iter+0xfd/0x190 > > [1.650031] generic_file_write_iter+0xe1/0x1e0 > > [1.650095] __vfs_write+0xfc/0x160 > > [1.650148] vfs_write+0xa8/0x190 > > [1.650196] ksys_write+0x4d/0xb0 > > [1.650245] do_syscall_64+0x43/0xf0 > > [1.650301] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [1.650465] RIP:
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hello, > but was the original issue solved? Yes, after removing the suggested line and applying patch [2] on top of v4.17, when I try to mount the original FS image, mount just returns Invalid argument, no kernel NULL pointer dereferences anymore: mount: mounting /dev/sda on /mnt failed: Invalid 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://www.spinics.net/lists/linux-fsdevel/msg125241.html > > > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html > > > > If I get it right, the first patch is already upstreamed in some > > modified form and cannot be applied on top of vanilla v4.17. > > The first part of the patchset was already picked up, but your report > is related to the second part, which is the link at [1]. It should > still apply. > > > When I > > apply the second one I get > > > > $ patch -p1 < ../hfsplus-2.patch > > patching file fs/hfsplus/dir.c > > patching file fs/hfsplus/hfsplus_fs.h > > patching file fs/hfsplus/inode.c > > patching file fs/hfsplus/super.c > > Hunk #3 FAILED at 567. > > Hunk #4 succeeded at 586 (offset 1 line). > > 1 out of 4 hunks FAILED -- saving rejects to file fs/hfsplus/super.c.rej > > $ cat fs/hfsplus/super.c.rej > > --- fs/hfsplus/super.c > > +++ fs/hfsplus/super.c > > @@ -567,11 +547,6 @@ static int hfsplus_fill_super(struct super_block > > *sb, void *data, int silent) > > sbi->nls = nls; > > return 0; > > > > -out_put_hidden_dir: > > - iput(sbi->hidden_dir); > > -out_put_root: > > - dput(sb->s_root); > > - sb->s_root = NULL; > > out_put_alloc_file: > > iput(sbi->alloc_file); > > out_close_attr_tree: > > That's because a patch by Tetsuo Handa added a call to > cancel_delayed_work_sync() after the out_put_hidden_dir tag. Just remove > that line before applying the patch. > > > > > Looks, like manually removing this hunk cannot change anything > > (because of previous return), so just left as is. > > Ok, that should be enough for testing. The rest of your mail seems like a > separate bug report, though. I'll take a look at it, but was the original > issue solved? > > > > > 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 to handle kernel NULL pointer dereference > > at 0043 > > [1.64] PGD 1d4d2067 P4D 1d4d2067 PUD 1d4bc067 PMD 0 > > [1.646870] Oops: [#1] SMP NOPTI > > [1.647002] Modules linked in: > > [1.647209] CPU: 0 PID: 991 Comm: init Not tainted 4.17.0+ #1 > > [1.647291] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > BIOS 1.10.2-1ubuntu1 04/01/2014 > > [1.647456] RIP: 0010:hfsplus_bnode_put+0x9/0xc0 > > [1.647522] RSP: 0018:b750409b7a58 EFLAGS: 0282 > > [1.647607] RAX: a3b31e713000 RBX: 0a00 RCX: > > 1100 > > [1.647696] RDX: RSI: 85ca56d0 RDI: > > fffb > > [1.647787] RBP: a3b31d473288 R08: R09: > > b750409b7960 > > [1.647877] R10: R11: a3b31df0e618 R12: > > b750409b7ad0 > > [1.647967] R13: a3b31d473180 R14: a3b31d432a00 R15: > > 000a > > [1.648089] FS: 01dd48c0() GS:a3b31f80() > > knlGS: > > [1.648192] CS: 0010 DS: ES: CR0: 80050033 > > [1.648268] CR2: 0043 CR3: 1d4c4000 CR4: > > 06f0 > > [1.648406] Call Trace: > > [1.648883] hfsplus_brec_find+0x3c/0x150 > > [1.648970] ? hfsplus_brec_remove+0x160/0x160 > > [1.649037] hfsplus_ext_read_extent.part.6+0xba/0x190 > > [1.649118] ? clean_bdev_aliases+0x81/0x1d0 > > [1.649178] hfsplus_file_extend+0x16b/0x3a0 > > [1.649238] hfsplus_get_block+0x60/0x250 > > [1.649293] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649352] __block_write_begin_int+0x134/0x550 > > [1.649414] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649476] ? percpu_counter_add_batch+0x48/0x60 > > [1.649537] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649596] block_write_begin+0x3f/0xa0 > > [1.649652] cont_write_begin+0x232/0x330 > > [1.649713] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649776] hfsplus_write_begin+0x2f/0x70 > > [1.649834] ? hfsplus_file_extend+0x3a0/0x3a0 > > [1.649902] generic_perform_write+0xb1/0x1b0 > > [1.649965] __generic_file_write_iter+0xfd/0x190 > > [1.650031] generic_file_write_iter+0xe1/0x1e0 > > [1.650095] __vfs_write+0xfc/0x160 > > [1.650148] vfs_write+0xa8/0x190 > > [1.650196] ksys_write+0x4d/0xb0 > > [1.650245] do_syscall_64+0x43/0xf0 > > [1.650301] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [1.650465] RIP:
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hi: On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > Hello, > > > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html > > If I get it right, the first patch is already upstreamed in some > modified form and cannot be applied on top of vanilla v4.17. The first part of the patchset was already picked up, but your report is related to the second part, which is the link at [1]. It should still apply. > When I > apply the second one I get > > $ patch -p1 < ../hfsplus-2.patch > patching file fs/hfsplus/dir.c > patching file fs/hfsplus/hfsplus_fs.h > patching file fs/hfsplus/inode.c > patching file fs/hfsplus/super.c > Hunk #3 FAILED at 567. > Hunk #4 succeeded at 586 (offset 1 line). > 1 out of 4 hunks FAILED -- saving rejects to file fs/hfsplus/super.c.rej > $ cat fs/hfsplus/super.c.rej > --- fs/hfsplus/super.c > +++ fs/hfsplus/super.c > @@ -567,11 +547,6 @@ static int hfsplus_fill_super(struct super_block > *sb, void *data, int silent) > sbi->nls = nls; > return 0; > > -out_put_hidden_dir: > - iput(sbi->hidden_dir); > -out_put_root: > - dput(sb->s_root); > - sb->s_root = NULL; > out_put_alloc_file: > iput(sbi->alloc_file); > out_close_attr_tree: That's because a patch by Tetsuo Handa added a call to cancel_delayed_work_sync() after the out_put_hidden_dir tag. Just remove that line before applying the patch. > > Looks, like manually removing this hunk cannot change anything > (because of previous return), so just left as is. Ok, that should be enough for testing. The rest of your mail seems like a separate bug report, though. I'll take a look at it, but was the original issue solved? > > 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 to handle kernel NULL pointer dereference > at 0043 > [1.64] PGD 1d4d2067 P4D 1d4d2067 PUD 1d4bc067 PMD 0 > [1.646870] Oops: [#1] SMP NOPTI > [1.647002] Modules linked in: > [1.647209] CPU: 0 PID: 991 Comm: init Not tainted 4.17.0+ #1 > [1.647291] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.10.2-1ubuntu1 04/01/2014 > [1.647456] RIP: 0010:hfsplus_bnode_put+0x9/0xc0 > [1.647522] RSP: 0018:b750409b7a58 EFLAGS: 0282 > [1.647607] RAX: a3b31e713000 RBX: 0a00 RCX: > 1100 > [1.647696] RDX: RSI: 85ca56d0 RDI: > fffb > [1.647787] RBP: a3b31d473288 R08: R09: > b750409b7960 > [1.647877] R10: R11: a3b31df0e618 R12: > b750409b7ad0 > [1.647967] R13: a3b31d473180 R14: a3b31d432a00 R15: > 000a > [1.648089] FS: 01dd48c0() GS:a3b31f80() > knlGS: > [1.648192] CS: 0010 DS: ES: CR0: 80050033 > [1.648268] CR2: 0043 CR3: 1d4c4000 CR4: > 06f0 > [1.648406] Call Trace: > [1.648883] hfsplus_brec_find+0x3c/0x150 > [1.648970] ? hfsplus_brec_remove+0x160/0x160 > [1.649037] hfsplus_ext_read_extent.part.6+0xba/0x190 > [1.649118] ? clean_bdev_aliases+0x81/0x1d0 > [1.649178] hfsplus_file_extend+0x16b/0x3a0 > [1.649238] hfsplus_get_block+0x60/0x250 > [1.649293] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649352] __block_write_begin_int+0x134/0x550 > [1.649414] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649476] ? percpu_counter_add_batch+0x48/0x60 > [1.649537] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649596] block_write_begin+0x3f/0xa0 > [1.649652] cont_write_begin+0x232/0x330 > [1.649713] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649776] hfsplus_write_begin+0x2f/0x70 > [1.649834] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649902] generic_perform_write+0xb1/0x1b0 > [1.649965] __generic_file_write_iter+0xfd/0x190 > [1.650031] generic_file_write_iter+0xe1/0x1e0 > [1.650095] __vfs_write+0xfc/0x160 > [1.650148] vfs_write+0xa8/0x190 > [1.650196] ksys_write+0x4d/0xb0 > [1.650245] do_syscall_64+0x43/0xf0 > [1.650301] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [1.650465] RIP: 0033:0x486804 > [1.650510] RSP: 002b:7ffd156ba4e8 EFLAGS: 0246 ORIG_RAX: > 0001 > [1.650611] RAX: ffda RBX: 01dd48a0 RCX: > 00486804 > [1.650695] RDX: 0008aa47 RSI: 7ff996f60010 RDI: > 0001 > [1.650779] RBP: 0001 R08: R09: > 000a > [1.650863] R10: 01b6 R11: 0246 R12: > 7ff996f60010 > [1.650946] R13: 0008aa47 R14: 7ff996f60010 R15: > > [1.651058] Code: 39 5a 68 77 ce 48 89 ef 5b 5d e9 03 c7 ef ff 0f > 1f 00 48 85 ff 74 04 3e ff 47 48 f3 c3 0f 1f
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
Hi: On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote: > Hello, > > > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html > > If I get it right, the first patch is already upstreamed in some > modified form and cannot be applied on top of vanilla v4.17. The first part of the patchset was already picked up, but your report is related to the second part, which is the link at [1]. It should still apply. > When I > apply the second one I get > > $ patch -p1 < ../hfsplus-2.patch > patching file fs/hfsplus/dir.c > patching file fs/hfsplus/hfsplus_fs.h > patching file fs/hfsplus/inode.c > patching file fs/hfsplus/super.c > Hunk #3 FAILED at 567. > Hunk #4 succeeded at 586 (offset 1 line). > 1 out of 4 hunks FAILED -- saving rejects to file fs/hfsplus/super.c.rej > $ cat fs/hfsplus/super.c.rej > --- fs/hfsplus/super.c > +++ fs/hfsplus/super.c > @@ -567,11 +547,6 @@ static int hfsplus_fill_super(struct super_block > *sb, void *data, int silent) > sbi->nls = nls; > return 0; > > -out_put_hidden_dir: > - iput(sbi->hidden_dir); > -out_put_root: > - dput(sb->s_root); > - sb->s_root = NULL; > out_put_alloc_file: > iput(sbi->alloc_file); > out_close_attr_tree: That's because a patch by Tetsuo Handa added a call to cancel_delayed_work_sync() after the out_put_hidden_dir tag. Just remove that line before applying the patch. > > Looks, like manually removing this hunk cannot change anything > (because of previous return), so just left as is. Ok, that should be enough for testing. The rest of your mail seems like a separate bug report, though. I'll take a look at it, but was the original issue solved? > > 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 to handle kernel NULL pointer dereference > at 0043 > [1.64] PGD 1d4d2067 P4D 1d4d2067 PUD 1d4bc067 PMD 0 > [1.646870] Oops: [#1] SMP NOPTI > [1.647002] Modules linked in: > [1.647209] CPU: 0 PID: 991 Comm: init Not tainted 4.17.0+ #1 > [1.647291] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.10.2-1ubuntu1 04/01/2014 > [1.647456] RIP: 0010:hfsplus_bnode_put+0x9/0xc0 > [1.647522] RSP: 0018:b750409b7a58 EFLAGS: 0282 > [1.647607] RAX: a3b31e713000 RBX: 0a00 RCX: > 1100 > [1.647696] RDX: RSI: 85ca56d0 RDI: > fffb > [1.647787] RBP: a3b31d473288 R08: R09: > b750409b7960 > [1.647877] R10: R11: a3b31df0e618 R12: > b750409b7ad0 > [1.647967] R13: a3b31d473180 R14: a3b31d432a00 R15: > 000a > [1.648089] FS: 01dd48c0() GS:a3b31f80() > knlGS: > [1.648192] CS: 0010 DS: ES: CR0: 80050033 > [1.648268] CR2: 0043 CR3: 1d4c4000 CR4: > 06f0 > [1.648406] Call Trace: > [1.648883] hfsplus_brec_find+0x3c/0x150 > [1.648970] ? hfsplus_brec_remove+0x160/0x160 > [1.649037] hfsplus_ext_read_extent.part.6+0xba/0x190 > [1.649118] ? clean_bdev_aliases+0x81/0x1d0 > [1.649178] hfsplus_file_extend+0x16b/0x3a0 > [1.649238] hfsplus_get_block+0x60/0x250 > [1.649293] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649352] __block_write_begin_int+0x134/0x550 > [1.649414] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649476] ? percpu_counter_add_batch+0x48/0x60 > [1.649537] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649596] block_write_begin+0x3f/0xa0 > [1.649652] cont_write_begin+0x232/0x330 > [1.649713] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649776] hfsplus_write_begin+0x2f/0x70 > [1.649834] ? hfsplus_file_extend+0x3a0/0x3a0 > [1.649902] generic_perform_write+0xb1/0x1b0 > [1.649965] __generic_file_write_iter+0xfd/0x190 > [1.650031] generic_file_write_iter+0xe1/0x1e0 > [1.650095] __vfs_write+0xfc/0x160 > [1.650148] vfs_write+0xa8/0x190 > [1.650196] ksys_write+0x4d/0xb0 > [1.650245] do_syscall_64+0x43/0xf0 > [1.650301] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [1.650465] RIP: 0033:0x486804 > [1.650510] RSP: 002b:7ffd156ba4e8 EFLAGS: 0246 ORIG_RAX: > 0001 > [1.650611] RAX: ffda RBX: 01dd48a0 RCX: > 00486804 > [1.650695] RDX: 0008aa47 RSI: 7ff996f60010 RDI: > 0001 > [1.650779] RBP: 0001 R08: R09: > 000a > [1.650863] R10: 01b6 R11: 0246 R12: > 7ff996f60010 > [1.650946] R13: 0008aa47 R14: 7ff996f60010 R15: > > [1.651058] Code: 39 5a 68 77 ce 48 89 ef 5b 5d e9 03 c7 ef ff 0f > 1f 00 48 85 ff 74 04 3e ff 47 48 f3 c3 0f 1f
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
On Sun 2018-06-03 15:49:56, Ernesto A. Fernández wrote: 1;2802;0c> 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 > > 2. Compile it with the config attached > > 3. Unpack and mount the attached FS image as hfsplus. > > We are aware of this issue and I've sent some patches [1][2]. It's hard > to get reviewers interested in hfsplus, so I don't know when it will be > fixed. I guess Anatoly can still test the patches, and add Tested-by tags if they help. No guarantees, but that may make it easier to get the patches merged. Thanks, Pavel > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
On Sun 2018-06-03 15:49:56, Ernesto A. Fernández wrote: 1;2802;0c> 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 > > 2. Compile it with the config attached > > 3. Unpack and mount the attached FS image as hfsplus. > > We are aware of this issue and I've sent some patches [1][2]. It's hard > to get reviewers interested in hfsplus, so I don't know when it will be > fixed. I guess Anatoly can still test the patches, and add Tested-by tags if they help. No guarantees, but that may make it easier to get the patches merged. Thanks, Pavel > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
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 > > 2. Compile it with the config attached > > 3. Unpack and mount the attached FS image as hfsplus. > > We are aware of this issue and I've sent some patches [1][2]. It's hard > to get reviewers interested in hfsplus, so I don't know when it will be > fixed. > > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html -- С уважением, Анатолий Тросиненко e-mail: anatoly.trosine...@gmail.com
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 > > 2. Compile it with the config attached > > 3. Unpack and mount the attached FS image as hfsplus. > > We are aware of this issue and I've sent some patches [1][2]. It's hard > to get reviewers interested in hfsplus, so I don't know when it will be > fixed. > > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html -- С уважением, Анатолий Тросиненко e-mail: anatoly.trosine...@gmail.com
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
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 > 2. Compile it with the config attached > 3. Unpack and mount the attached FS image as hfsplus. We are aware of this issue and I've sent some patches [1][2]. It's hard to get reviewers interested in hfsplus, so I don't know when it will be fixed. [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html
Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
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 > 2. Compile it with the config attached > 3. Unpack and mount the attached FS image as hfsplus. We are aware of this issue and I've sent some patches [1][2]. It's hard to get reviewers interested in hfsplus, so I don't know when it will be fixed. [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html
