Custom Query (16363 matches)
Results (2005 - 2007 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #7705 | fixed | Memory leak in sf_lookup (vboxsf.ko module) => Fixed in SVN | ||
| 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 | ||
| 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 |
|||
| #8185 | fixed | Possible memory leak in sf_follow_link (vboxsf.ko module) => Fixed in SVN | ||
| 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 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. |
|||

