VirtualBox

Opened 6 years ago

Last modified 6 years ago

#17972 new defect

vboxsf module crashes guest OS after accessing host-side symlinks in shared folder

Reported by: Konstantin Vlasov Owned by:
Component: shared folders Version: VirtualBox 5.2.18
Keywords: Cc:
Guest type: Linux Host type: Windows

Description

Host OS: Windows 7 x64 Enterprise
Guest OS: CentOS 7 x64, kernel 3.10.0-862.11.6.el7.x86_64

Scenario:

  • A shared folder is configured, with host path "d:\VirtualBox Shared", under name "shared".
  • HOST: Create a file symlink d:\VirtualBox Shared\2\test.txt pointing to a file C:\Temp\test.txt:
    C:\>mklink "d:\VirtualBox Shared\2\test.txt" c:\Temp\test.txt
    symbolic link created for d:\VirtualBox Shared\2\test.txt <<===>> c:\Temp\test.txt
    
  • GUEST: try to access the symlink (in the last output, the link target is blinking, indicating it's inaccessible):
    flint@localhost / $ cp /media/sf_shared/2/test* /tmp
    cp: cannot stat ‘/media/sf_shared/2/test.txt’: No such file or directory
    flint@localhost / $ ls -l /media/sf_shared/2/test.txt
    lrwxrwx--- 1 root vboxsf 0 Sep  7 18:39 /media/sf_shared/2/test.txt -> C:/Temp/test.txt
    
  • HOST: Delete the link and replace it with a plain file:
    C:\>del "d:\VirtualBox Shared\2\test.txt"
    
    C:\>copy nul "d:\VirtualBox Shared\2\test.txt"
            1 file(s) copied.
    
  • GUEST: try to acccess the replaced file again:
    flint@localhost / $ cp /media/sf_shared/2/test* /tmp
    

Result: guest OS crashes and reboots. My friend helped with analyzing the dump, and concluded that the crash occurred in the vboxsf.ko module. Most of the dentry->d_inode->i_op callback fields on this file have zero values (all of them, except for getattr and setattr).

The dmesg is attached; kernel core dump can be downloaded from here: ​https://drive.google.com/open?id=1yFrDInJg8bgWXv-8kErs31W8Vn90aRYo

Attachments (1)

vmcore-dmesg.txt (35.9 KB ) - added by Konstantin Vlasov 6 years ago.
dmesg from the crashed kernel

Download all attachments as: .zip

Change History (2)

by Konstantin Vlasov, 6 years ago

Attachment: vmcore-dmesg.txt added

dmesg from the crashed kernel

comment:1 by Eugene, 6 years ago

Here is the crash info, for readability:

[  391.367312] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  391.367400] IP: [<          (null)>]           (null)
[  391.367443] PGD 8000000044143067 PUD 4dd8a067 PMD 0
[  391.367490] Oops: 0010 [#1] SMP
[  391.367526] Modules linked in: fuse vboxsf(OE) sunrpc dm_mirror dm_region_hash dm_log dm_mod joydev intel_powerclamp iosf_mbi crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd ppdev vboxguest(OE) pcspkr snd_intel8x0 vboxvideo(OE) snd_ac97_codec ttm ac97_bus snd_seq drm_kms_helper snd_seq_device sg snd_pcm syscopyarea snd_timer sysfillrect sysimgblt fb_sys_fops snd soundcore drm i2c_piix4 parport_pc i2c_core video parport ip_tables xfs libcrc32c sr_mod sd_mod crc_t10dif cdrom crct10dif_generic ahci virtio_net libahci libata crct10dif_pclmul crct10dif_common crc32c_intel virtio_pci serio_raw virtio_ring virtio
[  391.367590] CPU: 0 PID: 3504 Comm: cp Kdump: loaded Tainted: G           OE  ------------   3.10.0-862.11.6.el7.x86_64 #1
[  391.367677] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  391.367728] task: ffff9d9d6579dee0 ti: ffff9d9d39c7c000 task.ti: ffff9d9d39c7c000
[  391.367789] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
[  391.367837] RSP: 0018:ffff9d9d39c7fcb8  EFLAGS: 00010246
[  391.367881] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000020
[  391.367927] RDX: ffffffffffffffe0 RSI: ffff9d9d39c7fd90 RDI: ffff9d9d3d29a780
[  391.367976] RBP: ffff9d9d39c7fd48 R08: 000000005b929c87 R09: 000000005b929c87
[  391.368022] R10: 0000000000000000 R11: ffffdba701e79f00 R12: ffff9d9d6579dee0
[  391.368071] R13: ffff9d9d39c7fd90 R14: ffff9d9d39c7fd08 R15: ffff9d9d3d29a780
[  391.368118] FS:  00007f9062fc6840(0000) GS:ffff9d9d7fc00000(0000) knlGS:0000000000000000
[  391.369400] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  391.369864] CR2: 0000000000000000 CR3: 000000007a768000 CR4: 00000000000606f0
[  391.370583] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  391.371433] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  391.371983] Call Trace:
[  391.372664]  [<ffffffff8ee2e1e7>] ? path_lookupat+0x337/0x8b0
[  391.373484]  [<ffffffff8ee2e78b>] filename_lookup+0x2b/0xc0
[  391.374047]  [<ffffffff8ee31bc7>] user_path_at_empty+0x67/0xc0
[  391.374691]  [<ffffffff8edcae3d>] ? handle_mm_fault+0x39d/0x9b0
[  391.375506]  [<ffffffff8ee31c31>] user_path_at+0x11/0x20
[  391.376030]  [<ffffffff8ee24c13>] vfs_fstatat+0x63/0xc0
[  391.376676]  [<ffffffff8ee2517e>] SYSC_newstat+0x2e/0x60
[  391.377464]  [<ffffffff8f3256e1>] ? system_call_after_swapgs+0xae/0x146
<...>
[  391.383442]  [<ffffffff8ee2545e>] SyS_newstat+0xe/0x10
[  391.383720]  [<ffffffff8f32579b>] system_call_fastpath+0x22/0x27
[  391.384230]  [<ffffffff8f3256e1>] ? system_call_after_swapgs+0xae/0x146
[  391.384582] Code:  Bad RIP value.
[  391.385087] RIP  [<          (null)>]           (null)
[  391.385582]  RSP <ffff9d9d39c7fcb8>
[  391.386036] CR2: 0000000000000000

The dump shows that the problem happened in follow_link (fs/namei.c:896) which is inlined into path_lookupat():

static __always_inline int
follow_link(struct path *link, struct nameidata *nd, void **p)
{
<...>
	nd->last_type = LAST_BIND;
	*p = dentry->d_inode->i_op->follow_link(dentry, nd);	// here
	error = PTR_ERR(*p);
<...>
}

dentry->d_inode->i_op->follow_link is NULL there.

0xffffffff8ee2e1c8 <path_lookupat+792>: movl   $0x4,0x40(%r13)
0xffffffff8ee2e1d0 <path_lookupat+800>: mov    0x30(%r15),%rax  // dentry is in %r15
0xffffffff8ee2e1d4 <path_lookupat+804>: mov    %r13,%rsi
0xffffffff8ee2e1d7 <path_lookupat+807>: mov    %r15,%rdi
0xffffffff8ee2e1da <path_lookupat+810>: mov    0x20(%rax),%rax
0xffffffff8ee2e1de <path_lookupat+814>: mov    0x8(%rax),%rax
0xffffffff8ee2e1e2 <path_lookupat+818>: callq  0xffffffff8ef5f080 <__x86_indirect_thunk_rax>

dentry is in %r15, it is 0xffff9d9d3d29a780.

crash> p ((struct dentry *)0xffff9d9d3d29a780)->d_name.name
$2 = (const unsigned char *) 0xffff9d9d3d29a7b8 "test.txt"

crash> p *((struct dentry *)0xffff9d9d3d29a780)->d_inode->i_op
$3 = {
  lookup = 0x0, 
  follow_link = 0x0, 
  permission = 0x0, 
  get_acl = 0x0, 
  readlink = 0x0, 
  put_link = 0x0, 
  create = 0x0, 
  link = 0x0, 
  unlink = 0x0, 
  symlink = 0x0, 
  mkdir = 0x0, 
  rmdir = 0x0, 
  mknod = 0x0, 
  rename = 0x0, 
  setattr = 0xffffffffc07b3c80, 
  getattr = 0xffffffffc07b3c40, 
  setxattr = 0x0, 
  getxattr = 0x0, 
  listxattr = 0x0, 
  removexattr = 0x0, 
  fiemap = 0x0, 
  update_time = 0x0, 
  atomic_open = 0x0
}

crash> p ((struct dentry *)0xffff9d9d3d29a780)->d_inode->i_op
$4 = (const struct inode_operations *) 0xffffffffc07b8480
crash> sym 0xffffffffc07b8480
ffffffffc07b8480 (d) sf_reg_iops [vboxsf]

So, the kernel tried to execute a callback from sf_reg_iops set by vboxsf, but the callback address was NULL.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use