VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (2005 - 2007 of 16363)

Ticket Resolution Summary Owner Reporter
#7705 fixed Memory leak in sf_lookup (vboxsf.ko module) => Fixed in SVN Eugene
Description

A small memory leak seems to happen in the kernel module from VirtualBox Guest Additions (Linux) responsible for shared folder support (vboxsf.ko).

Consider sf_lookup() function from dirops.c (SVN: trunk/src/VBox/Additions/linux/sharedfolders/dirops.c, revision 33540).

The call to sf_path_from_dentry() allocates memory for 'path' structure and fills it appropriately. But if the call to sf_stat() located just below in sf_lookup() returns -ENOENT, that memory will probably never be freed.

This happens if some process tries to access a non-existent entry in the shared folders: a file that is about to be created or is simply missing, etc.

To make it clearer, here are two (of possibly many) ways of how the problem could be reproduced (assume 'vbshare' is the device for a shared folder and that folder contains neither 'aaa' subfolder nor 'ccc.txt' file).

Variant 1:

# mount -t vboxsf vbshare /mnt/shared
# ls /mnt/shared/aaa
# umount vbshare

8 bytes are leaked.

Variant 2:

# mount -t vboxsf vbshare /mnt/shared
# echo 123 > /mnt/shared/ccc.txt
# umount vbshare

12 bytes are leaked.

Host OS: Windows XP SP3 Pro x86

Guest OS: OpenSuSE Linux 11.3 x86

#7720 fixed g_vbgldata.mutexHGCMHandle is never destroyed (vboxsf.ko module) => Fixed in SVN Eugene
Description

When vboxsf kernel module performs its finalization tasks, the contents of g_vbgldata structure are zeroed before RTSemFastMutexDestroy() is called for g_vbgldata.mutexHGCMHandle.

File: trunk/src/VBox/Additions/common/VBoxGuestLib/Init.cpp from SVN rev. 33540.

Consider VbglTerminate() function (Init.cpp:252). It calls vbglTerminateCommon() and then vbglR0HGCMTerminate(). It seems that the intention was to destroy g_vbgldata.mutexHGCMHandle in the latter. However, vbglTerminateCommon() zeroes the contents of g_vbgldata after it does its part of cleaning up (Init.cpp:164):

DECLVBGL(void) vbglTerminateCommon (void)
{
    VbglPhysHeapTerminate ();

    RT_ZERO(g_vbgldata); 

    return;
}

After that, the value of g_vbgldata.mutexHGCMHandle is lost and the structure it points to will never be released: vbglR0HGCMTerminate() will call RTSemFastMutexDestroy(0) in this case.

The consequences of this problem are probably not that critical. It seems, this results only in a small memory leak (36 bytes on my machine) each time vboxsf module is unloaded, but still.

Host OS: Windows XP SP3 Pro x86
Guest OS: OpenSuSE Linux 11.3 x86

#8185 fixed Possible memory leak in sf_follow_link (vboxsf.ko module) => Fixed in SVN Eugene
Description

There is a possibility for a memory leak in sf_follow_link() function (src/VBox/Additions/linux/sharedfolders/lnkops.c).

The page allocated there via get_zeroed_page(GFP_KERNEL) will probably never be freed if vboxReadLink() fails. This happens, for example, when the shared folder contains a Windows symlink (a junction, to be exact) to a directory and one tries to list the contents of that directory from the guest or just cd to it via the link.

If I understand correctly what happens there, neither vboxReadLink() nor sf_follow_link() free that page, so it remains allocated and the pointer to it is lost when sf_follow_link() ends.

Host: Windows XP SP3 x86
Guest: OpenSUSE 11.3 x86
Guest Additions: 4.0.3 (r69551)

Attached are the VM log, VM configuration and the file with the call stacks of the memory leaks of this kind.

This problem as well as those reported in tickets #7705 and #7720 was detected by KEDR analysis system for Linux kernel modules.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy