@Mikerowrites:We do have a fix internally for this issue, and we'll be shipping it next week via Workstation 16.2.4.
Sorry for being blunt but I'm afraid you - meaning rather VMware in general than just you in person - are still missing the point here. The core problem is not version X of Workstation not working correctly with version Y of Ubuntu (or Fedora or openSUSE or whatever). It's the very fact that you still think in the terms of "supported host/guest systems", i.e. you have a fixed list of versions of a very short list of distributions and completely disregard the rest.
The Linux world does not work like this. There are not 3 or 4 distributions, there are hundreds. And, worse, more and more people move to rolling style distributions where you don't have discrete sequence of versions, unless you consider every daily snapshot a "version". Corporate people often say that they cannot test all of those but that's exactly where they are missing the point. For instance, when the init script does not get started because some distributions stopped shipping chkconfig by default (and some even not at all) in order to force people to migrate to native systemd units, it's not a problem "with Tumbleweed" (or Fedora), it's a generic problem with a generic solution. The same can be said for necessary updates of the kernel modules: if an upstream change in 5.18 kernel breaks the module, it's not a problem of a specific Fedora or Tumbleweed snapshot, it's a generic problem that is inevitably going to affect more and more systems as they move to 5.18 kernel. And it should be addressed as soon as 5.18 is released (the fix can be usually prepared as soon as rc1 is out). Sure, there are also specific issues with specific versions of specific distributions but those are rare, vast majority of the problems is generic and should be treated as such.
An example: Workstation/Player 16.2.4 has been just released and it fixes (on kernel module front) one specific issue with the hack in the definition ASSERT_ON_COMPILE_SELECTOR_SIZE() macro which is going to "fix the problem on Ubuntu 22.04". More precisely, it fixes the problem on any distribution building its kernel with -fsanitize=shift. It does not, however, address any of the issues with build against 5.19 kernel (going to be released at the end of this week). Sadly, it does not address even known problems with 5.18 kernel (dropped HAVE_GET_KERNEL_NOFAULT and netif_rx_ni()) or 5.17 (net_device::dev_addr now const and accessors should be used), and AFAICS not even the include issues known since 5.15 and 5.16 (need to use kernel versions of stdarg.h and stddef.h rather than userspace ones). This is a result of thinking in the terms of fixed list of "supported releases": as long as it does not break completely (warnings are ignored, mostly) on one of them, you don't care. BtW, a fix for the "Ubuntu 22.04 issue" (exactly the same as yours, except for a comment and whitespace formatting) was known in public since January 2nd, i.e. more than half a year before 16.2.4 was released and more than 2 months before 16.2.3 was released.
To sum up: as long as you don't change your understanding of the Linux world, this is going to be a recurring issue and people are inevitably going to be annoyed.
