Bugzilla Bug 117696

For some reason the update96 contents were omitted from the latest vmware
ebuild.  The changelog does not indicate that update96 was intentionally
removed from the package and it appears to be necessary when using the
suspend2-sources kernel.

Created an attachment (id=76127) [edit]
Patch to ebuild to re-include update96 contents.

Included patch that makes things work for me again.

I have had the same problem on x86 and amd64.
This problem was fixed by attached solution.
Thanks a lot.

The update should not be necessary with this build, which was why it was
removed.  Adding the patch back restores support for suspend2-sources?

Yes, the vnmet.tar file in particular is much smaller, probably with an earlier
date stamp, than from update96.  I can't speak to whether the update program
does useful things for the binaries.

OK.  After looking through some more information I've come to the conclusion
that you guys are just out of luck until update97 comes out.  The reason you
guys are out of luck is because of security bug #116238 which is a remotely
executable overflow.  The newer VMware Workstation version fixes this bug,
while the vmnet.tar from update96 does not.  Since VMware did not provide a
patch, but rather a complete new build, there's little I can do about it.  I
suggest contacting VMware for support.

I also fear that this affects gentoo-sources, since they are nearly the same
codebase.

If it helps I'm currently on:

2.6.14-gentoo-r5 (Gentoo-sources)

and vmware-workstation-5.5.1.19175

and all went well with vmware-config.pl...

I am on exactly the same kernel, and my build failed, see bug 117903

/Jakob

*** Bug 117903 has been marked as a duplicate of this bug. ***

I'm reopening this bug since it doesn't compile, but I am not applying this
fix.  I don't want to reintroduce the security bug.  Instead I am trying to
find an actual patch for the security bug versus update96 (or hopefully get an
update97) for everyone.

Strangely enough, I have 0 issues getting it to compile here.

Created an attachment (id=76310) [edit]
Kernel 2.6.14-gentoo-r5 config file showing the problem

I am attaching my kernel config.  Maybe that will make it possible for you to
reproduce the problem / test a solution.  There might be a kernel config
parameter that triggers the problem.

In the meantime, I will await update97 (im)patiently :-)

/Jakob

I'm now really upset because of this bug.
Why is the old version immediately removed?
Why is this new version set stable without test it?

I HIGHLY recommend to either fix this ASAP or put the old version in again
and mark this new version unstable.

I tried with several kernel version without any success.
On my system the emergeing workes fine, but the vmware-config.pl failes with
the following error:

Building the vmnet module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config9/vmnet-only'
make -C /lib/modules/2.6.15/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/.
modules
make[1]: Entering directory `/usr/src/linux-2.6.15'
  CC [M]  /tmp/vmware-config9/vmnet-only/driver.o
/tmp/vmware-config9/vmnet-only/driver.c: In function `VNetProcessOwnsPort':
/tmp/vmware-config9/vmnet-only/driver.c:1396: error: structure has no member
named `max_fds'
make[2]: *** [/tmp/vmware-config9/vmnet-only/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-config9/vmnet-only] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.15'
make: *** [vmnet.ko] Error 2
make: Leaving directory `/tmp/vmware-config9/vmnet-only'
Unable to build the vmnet module.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

I would like to add a comment too: Since this is not a remote exploitable bug,
but requires a malicious user with an "evil" virtual machine, I think it is an
overreaction to remove the old version completely as long as the new version is
not usable with the default kernel (gentoo-sources).  I suggest that the old
version is put back, but hard-masked.  Then we have to make an effort to reopen
the security hole, but we have the option if the new package does not work.

VMware version 4.5 is anyway a security hole (bug 104480), or it that perhaps
also fixed in the new version ...

I'd like to second that. My system is now broken because my setup relies on the
vmnet interfaces, and I can't do anything right now without having this fixed.
I'm not amused by deleting the old version completely. Would you PLEASE put the
old version back into portage?!

Maik

I really hate repeating myself, but I apparently did not make it clear enough. 
I will *NOT* add the old version back into portage proper.  You are free to
pull the old version from viewcvs.gentoo.org and use it in your overlay.  You
are free to switch to vanilla-sources, which works fine.  You're also free to
update the current ebuild using the patch attached in this bug, but I am not
reintroducing a vulnerable package in the tree and no amount of begging or
whining is going to change my position on this.  I have already explained
myself and really would appreciate it if you guys would actually listen to what
I have to say rather than continuing to spam this bug with incessant whimpering
about my refusal to backpedal on a security issue.  The VMware team for Gentoo
is effectually only myself and I am trying to find the cause of this error, but
there's only so much that I can do.  If you want to be actually helpful, you
could try finding the changes between update96 and the package's vmnet that
resolves the compilation issue, without reintroducing the security bug. 
Begging and pleading doesn't help anyone.

If you would have looked into comment #11 you would have seen that I AM using
the vanilla-sources. So, you're not right...

All I to say about your comment is... a lot...

Making a program unusable is also a way to make it secure.
Why are you blaming us personally? Did we?
It sounds a bit like "What do you insignificant users want?"

BTW, do you know "How to irritate people" with John Clease???

Just confirming that I hit the same problem on Linux sancy 2.6.14-gentoo-r5 #1
PREEMPT Thu Jan 12 09:03:32 CET 2006 i686 Intel(R) Pentium(R) M processor
1400MHz GenuineIntel GNU/Linux.

In fact I was stupid enough to upgrade the kernel today. I should not have done
that.  I have seen this issue immediately after the new vmware release was out:
it would not compile against 2.6.14-gentoo-r4.  Fortunately I could get by with
just removing /etc/vmware/not_configured and using the modules from the
previous release.  That worked, though might have been insecure.

However this breakes if you upgrade your kernel.  I either have to go back to
my old kernel or do major hacking on modules.  So if you have not upgraded your
kernel since your old working vmware installation, you may still find a
workaround in removing /etc/vmware/not_configured.

Just to be explicit about the workaround:  The patch that is attached to this
bug will allow you to compile the modules under 2.6.14-r5 (at least).  Because
it's the only way I could find to get up and running again (and not obvious to
the end-user):

1) Download this patch (also above):  
         http://bugs.gentoo.org/attachment.cgi?id=76127

2) `cd /usr/portage/app-emulation/vmware-workstation`
3) `patch vmware-workstation-4.5.3.19414.ebuild ~/<the_patch_file>`
4) `ebuild /usr/portage/app-emulation/vmware-workstation digest`
5) `emerge -av vmware-workstation`

Now vmware-config.pl should work (with the security caveats above, etc...)

I have a question - The sources to vmnet & friends are in a tarball.  Does
portage have a way to patch a binary file, or should I extract it, patch the
file and re-generate the tarball?

I can do either, if binary patching is supported, but it may be easier to do
binary.

PS: I'm planning to figure out the bare minimum patch necessary to allow vmnet
to compile.  It shouldn't be *that* hard... It's only C after all ;)

I have the patch, but I need some help with the kernel #defines.  Since this
problem appeared only recently, there is a specific version where it was
introduced.  I'll try to find exactly what version that is, but I'm not really
familiar with how the kernel identifies itself so that I can #ifdef out the
patched section appropriately.

Anyone?

Created an attachment (id=76981) [edit]
New ebuild with vmnet patch.

A first-cut at a new ebuild and patch.  This patch *ASSUMES* that the new
structure went in at 2.6.14 vanilla.  If that's incorrect in some way, this
patch will break vmnet builds for some people.  But, it's something that can be
tweaked if necessary.
I did figure out the kernel versioning so that's set, it's just the precise
numbers that'll need to be tweaked.

Created an attachment (id=76982) [edit]
Patch for new kernel structure in 2.6.14+

This is the additional patch for vmnet to work with kernels >= 2.6.14.

Paul, you are a giant among men, and don't let anyone tell you otherwise... :P

Can some of the rest of you try this ebuild and verify that this works?  I'll
try it out this weekend and see what my results are, if I don't get some
confirmations before then.

Thanks for the new ebuild!  Unfortunately, it does not quite solve the problem.
 The module builds, but it cannot load into the kernel.


   [ ... ]
Building the vmnet module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config4/vmnet-only'
make -C /lib/modules/2.6.14-gentoo-r5/build/include/.. SUBDIRS=$PWD
SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.14-gentoo-r5'
  CC [M]  /tmp/vmware-config4/vmnet-only/driver.o
  CC [M]  /tmp/vmware-config4/vmnet-only/hub.o
  CC [M]  /tmp/vmware-config4/vmnet-only/userif.o
In file included from /tmp/vmware-config4/vmnet-only/userif.c:45:
/tmp/vmware-config4/vmnet-only/pgtbl.h: In function `PgtblVa2PTELocked':
/tmp/vmware-config4/vmnet-only/pgtbl.h:81: warning: passing arg 1 of
`pmd_offset' from incompatible pointer type
/tmp/vmware-config4/vmnet-only/userif.c: In function `VNetUserIfMapUint32Ptr':
/tmp/vmware-config4/vmnet-only/userif.c:156: warning: implicit declaration of
function `verify_area'
/tmp/vmware-config4/vmnet-only/userif.c: In function `VNetCopyDatagramToUser':
/tmp/vmware-config4/vmnet-only/userif.c:563: warning: implicit declaration of
function `skb_copy_datagram'
  CC [M]  /tmp/vmware-config4/vmnet-only/netif.o
  CC [M]  /tmp/vmware-config4/vmnet-only/bridge.o
/tmp/vmware-config4/vmnet-only/bridge.c: In function `VNetBridgeUp':
/tmp/vmware-config4/vmnet-only/bridge.c:586: warning: passing arg 3 of
`sk_alloc' makes pointer from integer without a cast
/tmp/vmware-config4/vmnet-only/bridge.c:586: warning: passing arg 4 of
`sk_alloc' makes integer from pointer without a cast
/tmp/vmware-config4/vmnet-only/bridge.c:598: warning: assignment from
incompatible pointer type
  CC [M]  /tmp/vmware-config4/vmnet-only/procfs.o
  LD [M]  /tmp/vmware-config4/vmnet-only/vmnet.o
  Building modules, stage 2.
  MODPOST
*** Warning: "verify_area" [/tmp/vmware-config4/vmnet-only/vmnet.ko] undefined!
*** Warning: "skb_copy_datagram" [/tmp/vmware-config4/vmnet-only/vmnet.ko]
undefined!
  CC      /tmp/vmware-config4/vmnet-only/vmnet.mod.o
  LD [M]  /tmp/vmware-config4/vmnet-only/vmnet.ko
make[1]: Leaving directory `/usr/src/linux-2.6.14-gentoo-r5'
cp -f vmnet.ko ./../vmnet.o
make: Leaving directory `/tmp/vmware-config4/vmnet-only'
Unable to make a vmnet module that can be loaded in the running kernel:
insmod: error inserting '/tmp/vmware-config4/vmnet.o': -1 Unknown symbol in
module
There is probably a slight difference in the kernel configuration between the
set of C header files you specified and your running kernel.  You may want to
rebuild a kernel based on that directory, or specify another directory.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

Looks like I'll need to a little more work.  I couldn't test it as I'm using
the VMware installation for "real" work right now.  I'll see what else needs to
be done, unless someone else gets to it first.

Jakob, are you sure your /usr/src/linux link is pointing to your current
kernel's sources and it has the same .config as your running kernel?

(In reply to comment #25)
> Jakob, are you sure your /usr/src/linux link is pointing to your current
> kernel's sources and it has the same .config as your running kernel?
> 

Yes, I am sure.  But just to double-check, I went to that directory, did a
"make" and a "make install modules_install" and rebooted.  No change.

/Jakob

Created an attachment (id=77001) [edit]
Patch for new kernel structure in 2.6.14+

Updated vmnet_2.6.14.patch. - Still untested...
It now compiles without errors so it *should* work.  Please test.

This patch doesn't work.  It causes kernel panics and outputs these errors:
Jan 13 18:05:10 ex1503 vmnet-dhcpd: receive_packet failed on vmnet1: Bad
address

Also for vmnet8 and vmnet0...  Bad patch!
I'm not sure I have the expertise to fix it unfortunately.

Hi Paul,

skb_copy_datagram can't simply be renamed to skb_copy_datagram_iovec. You have
to include a short wrapper, e.g. from http://lkml.org/lkml/2005/1/22/60
(No need to patch the kernel. Just cut and paste the wrapper to some vmware
source file.)

Ooh.  Ok, I'll give that a stab and post another patch.  I'll try to test it a
bit first too ;)

Well, I have a patch that doesn't cause the box to immediately crash.  However
I'm sitll seeing these errors:
Jan 23 20:00:58 ex1503 vmnet-dhcpd: receive_packet failed on vmnet1: Bad
address
Jan 23 20:02:10 ex1503 vmnet-dhcpd: receive_packet failed on vmnet8: Bad
address

And no network connectivity from the virtual machine...  Any additional
thoughts or pointers?

Created an attachment (id=77964) [edit]
Patch for new kernel structure in 2.6.14+

This is the slightly updated patch with the skb_copy_datagram wrapper applied. 
I hadn't applied the patch properly in comment #31 so I have corrected that
problem.  Since this one doesn't crash my box, I wanted to update it here. 
And...

This patch appears to work...  I'll run it tomorrow and see what happens!

Well, I've been running this for 12 hours and have transferred more than 192MB
up and 77MB down through the NAT interface on my VMWare workstation and nothing
but happy messages from vmnet in the messages file.

I'd request that others try the patch and provide feedback as well.  Note, that
the LKML reference stated that the skb_datagram wrapper was removed at
2.6.11-r2, so the #if version checks start working for that code at 2.6.11.  If
this describes your kernel and it doesn't work, please post something and we'll
adjust it for the Gentoo / Suspend2 variants.

Please don't resolve this when there's no fix in the tree.

I'm guessing you're pretty much using your earlier ebuild for this, correct?

Created an attachment (id=78007) [edit]
Updated ebuild used with attachment #77964 [edit]

Ooh, sorry about that.  I'm uploading the exact ebuild I used to apply the
patch in attachment #77964 [edit].

Unfortunately when I booted my machine this morning vmnet oops'd.  Back to the
drawing board I guess...

There's a NULL pointer dereference somewhere...  I'm guessing it's in the
non-skb_datagram code because I put that together...  Hmm...

Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: registered with major=10
minor=165
Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: initialized
Jan 25 08:14:34 ex1503 /dev/vmmon: Module vmmon: unloaded
Jan 25 08:14:46 ex1503 /dev/vmmon: Module vmmon: registered with major=10
minor=165
Jan 25 08:14:46 ex1503 /dev/vmmon: Module vmmon: initialized
Jan 25 08:14:46 ex1503 parport0: PC-style at 0x378 (0x778), irq 7, using FIFO
[PCSPP,TRISTATE,COMPAT,ECP]
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15765 (vmnet-bridge)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 0 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 0 successfully opened
Jan 25 08:14:47 ex1503 bridge-eth0: peer interface eth0 not found, will wait
for it to come up
Jan 25 08:14:47 ex1503 bridge-eth0: attached
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15783 (vmnet-bridge)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 2 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 2 successfully opened
Jan 25 08:14:47 ex1503 bridge-eth1: enabling the bridge
Jan 25 08:14:47 ex1503 Unable to handle kernel NULL pointer dereference at
virtual address 00000069
Jan 25 08:14:47 ex1503 printing eip:
Jan 25 08:14:47 ex1503 c02311bd
Jan 25 08:14:47 ex1503 *pde = 00000000
Jan 25 08:14:47 ex1503 Oops: 0000 [#1]
Jan 25 08:14:47 ex1503 PREEMPT 
Jan 25 08:14:47 ex1503 Modules linked in: vmnet parport_pc vmmon ndiswrapper
ipt_MASQUERADE iptable_nat ip_nat ipt_REJECT ipt_LOG ipt_state iptable_filter
ip_tables snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_intel8x0m ohci_hcd ehci_hcd 8250_pnp floppy eth1394 ohci1394
ieee1394 nvidia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
soundcore snd_page_alloc i8xx_tco usbhid uhci_hcd intel_agp agpgart tun
irtty_sir sir_dev irda crc_ccitt ppdev parport 8250_pci 8250 serial_core
twofish dm_crypt dm_mod loop vfat fat ide_cd cdrom ip_conntrack_ftp
ip_conntrack 3c59x mii ac battery thermal acpi_cpufreq processor yenta_socket
rsrc_nonstatic pcmcia pcmcia_core firmware_class crc32 cpufreq_ondemand
cpufreq_powersave capability commoncap joydev
Jan 25 08:14:47 ex1503 CPU:    0
Jan 25 08:14:47 ex1503 EIP:    0060:[<c02311bd>]    Tainted: P      VLI
Jan 25 08:14:47 ex1503 EFLAGS: 00010282   (2.6.15-suspend2-r2) 
Jan 25 08:14:47 ex1503 EIP is at sk_alloc+0xf/0x110
Jan 25 08:14:47 ex1503 eax: 00000020   ebx: f2660a0c   ecx: 0000000b   edx:
00000001
Jan 25 08:14:47 ex1503 esi: f2660a00   edi: 00000000   ebp: f0285e78   esp:
f0285e4c
Jan 25 08:14:47 ex1503 ds: 007b   es: 007b   ss: 0068
Jan 25 08:14:47 ex1503 Process vmnet-bridge (pid: 15783, threadinfo=f0284000
task=f0a7a030)
Jan 25 08:14:47 ex1503 Stack: f0a7a15c ffffffff f0a7a030 00000003 f0285e6c
c028225b 00000001 00000286 
Jan 25 08:14:47 ex1503 f2660a0c f2660a00 00000000 f0285e9c f8d3cb7b 00000010
00000020 00000001 
Jan 25 08:14:47 ex1503 00000000 f2660a0c f78d1805 f2660a11 f0285ebc f8d3cd51
f2660a00 f8d3d962 
Jan 25 08:14:47 ex1503 Call Trace:
Jan 25 08:14:47 ex1503 [<c010320d>] show_stack+0x74/0x7c
Jan 25 08:14:47 ex1503 [<c010331b>] show_registers+0xee/0x157
Jan 25 08:14:47 ex1503 [<c01034cc>] die+0xd1/0x157
Jan 25 08:14:47 ex1503 [<c01107ed>] do_page_fault+0x358/0x486
Jan 25 08:14:47 ex1503 [<c0102ef7>] error_code+0x4f/0x54
Jan 25 08:14:47 ex1503 [<f8d3cb7b>] VNetBridgeUp+0xbe/0x199 [vmnet]
Jan 25 08:14:47 ex1503 [<f8d3cd51>] VNetBridgeNotify+0xab/0x116 [vmnet]
Jan 25 08:14:47 ex1503 [<c023720f>] register_netdevice_notifier+0x40/0x57
Jan 25 08:14:47 ex1503 [<f8d3c5a7>] VNetBridge_Create+0x77/0x212 [vmnet]
Jan 25 08:14:47 ex1503 [<f8d3a46c>] VNetFileOpIoctl+0x136/0x365 [vmnet]
Jan 25 08:14:47 ex1503 [<c01636f0>] do_ioctl+0x54/0x68
Jan 25 08:14:47 ex1503 [<c016398e>] vfs_ioctl+0x18a/0x19b
Jan 25 08:14:47 ex1503 [<c01639e5>] sys_ioctl+0x46/0x65
Jan 25 08:14:47 ex1503 [<c0102c73>] sysenter_past_esp+0x54/0x75
Jan 25 08:14:47 ex1503 Code: 8b 4d 18 e8 ca a7 f8 ff 83 f8 01 19 d2 f7 d2 83 e2
f2 8d 65 f4 89 d0 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 20 8b 55 10 8b 45 0c
<8b> 52 68 85 d2 89 55 e0 74 0d 50 52 e8 65 f9 f0 ff 5f 89 c6 58 
Jan 25 08:14:47 ex1503 <6>note: vmnet-bridge[15783] exited with preempt_count 1
Jan 25 08:14:47 ex1503 /dev/vmnet: open called by PID 15790 (vmnet-natd)
Jan 25 08:14:47 ex1503 /dev/vmnet: hub 8 does not exist, allocating memory.
Jan 25 08:14:47 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:14:53 ex1503 dhcpcd[14051]: timed out waiting for a valid DHCP server
response
Jan 25 08:14:57 ex1503 /dev/vmnet: open called by PID 15798 (vmnet-netifup)
Jan 25 08:14:57 ex1503 /dev/vmnet: hub 1 does not exist, allocating memory.
Jan 25 08:14:57 ex1503 /dev/vmnet: port on hub 1 successfully opened
Jan 25 08:14:57 ex1503 /dev/vmnet: open called by PID 15799 (vmnet-netifup)
Jan 25 08:14:57 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:15:58 ex1503 /dev/vmnet: open called by PID 15820 (vmware-vmx)
Jan 25 08:15:58 ex1503 /dev/vmnet: port on hub 8 successfully opened
Jan 25 08:15:59 ex1503 /dev/vmmon: fast clock rate 0 -> 19
Jan 25 08:16:12 ex1503 /dev/vmmon: fast clock rate 19 -> 0
Jan 25 08:16:12 ex1503 /dev/vmmon: fast clock rate 0 -> 100
Jan 25 08:16:13 ex1503 /dev/vmmon: fast clock rate 100 -> 101
Jan 25 08:20:16 ex1503 /dev/vmmon: fast clock rate 101 -> 1
Jan 25 08:20:16 ex1503 /dev/vmmon: fast clock rate 1 -> 251
Jan 25 08:21:40 ex1503 /dev/vmmon: fast clock rate 251 -> 1
Jan 25 08:21:40 ex1503 /dev/vmmon: fast clock rate 1 -> 101
Jan 25 08:21:44 ex1503 /dev/vmmon: fast clock rate 101 -> 251
Jan 25 08:22:03 ex1503 /dev/vmmon: fast clock rate 251 -> 101
Jan 25 08:23:06 ex1503 /dev/vmmon: fast clock rate 101 -> 0
Jan 25 08:23:06 ex1503 vmmon: Had to deallocate locked 98165 pages from vm
driver f2661000
Jan 25 08:23:06 ex1503 vmmon: Had to deallocate AWE 4116 pages from vm driver
f2661000
Jan 25 08:29:08 ex1503 /dev/vmmon: Module vmmon: unloaded
Jan 25 08:29:08 ex1503 bridge-eth0: detached
Jan 25 08:30:24 ex1503 shutdown[17075]: shutting down for system reboot

This is not related to suspend2-sources.

Henrik - Could you elaborate on that assertion?  I'm running suspend2-sources
and experienced (reported) the problem...  Is there a version of
suspend2-sources where this no longer occurs?

(In reply to comment #38)
> Henrik - Could you elaborate on that assertion?  I'm running suspend2-sources
> and experienced (reported) the problem...  Is there a version of
> suspend2-sources where this no longer occurs?

Not that I am aware of, but according to at least comment #7, comment #15 and
comment #16 this issue appears with gentoo-sources and vanilla-sources too.

Then let's call it linux sources >=2.6.xx where xx is appropriate...

*** Bug 122238 has been marked as a duplicate of this bug. ***

Is anything happening with this?  I'm still using the old ebuild because the
modules with the new one won't compile with hardened-sources.

The last one I wasa able to figure out still crashed or panic'd the box.  I
don't have any more ideas on how to go about fixing this.

This should be fixed in the latest revisions of the vmware-workstation and
vmware-player ebuilds.  I apologize that this took so long to get fixed.