Home host updated successfully, no issue.

Home host, no XOSTOR, updated fine, no issue with my usual VMs.

@nick.lloyd As mentionned by Olivier the documentation has a mail to contact us, which will create a ticket internally, unrelated to support, that will reach the security team directly.

The question that I'm asking here is how does the Vates Team evaluate these vulnerabilities, Qualys, Greenbone, something else?

I'm not sure what you mean by evaluate vulnerability, especially the list about Qualys, Greenbone…

If you mean how do we track and process them, I cannot talk about XO side, but I can shed some light on XCP-ng side:

• we have an internal dependency-track (DT) with various projects (8.2 default install, 8.2 available packages, same split for 8.3), with a custom SBOM generation, to feed DT
  • this is based on CVEs and their Common Platform Enumeration (CPE)
  • the main issue here is that not all CVEs fill the CPEs the same way, so there may be some misses
  • we're trying to improve the SBOM generation to minimize this
• we also monitor the oss-security mailing list, and some other sources
• DT reports the CVEs that matched, and we can keep them in or mark them internally as not impacted, fixed, etc
• we evaluate the priority for us based on their general criticality, but modulate this depending on if it is in base install or not, if it is a part of the software that is meant to be used as a server, if it related to remote acces, and more
• the one we're impacted by and feel are important, we either update to the latest package version, but now that CentOS 7 is end of life, that's less likely to happen, or try to backport the fix ourselves when possible.

That's for the dom0 side, on the hypervisor side, we're part of the security list of the Xen Project, so we receive the XSAs and integrate them as fast as we can in following our release process, sometime integrating the patches ourselves, sometime going with the XenServer fixes. If we integrate them ourselves we most of the time remove our own integration and move to the one from XenServer as the people working on these fixes are mostly the ones working on the XSAs in the first place so they have a better knowledge and insigts than us.

I hope this answers this question.

Is the Vates team open to the community reporting these vulnerabilities openly or would a ticket be best?

On XCP-ng side, everything that are packages from open source would be reports of publicly disclosed CVEs, so you can openly report them. If people were to find new vulnerabilities it would depend, but should follow a classic private disclosure in the first place:

• if it's in an open source package, the upstream would be the best place to do so
• On the same idea if it's regarding Xen, XAPI, or other Xen Project software, reporting them upstream through the security process is the best way, and it could be nice to drop us a ticket for a heads up too, but that's not mandatory
• if it is for some of the packages directly coming from us, creating a ticket for us to be able to work on it before a public disclosure would be best.

Sorry, you asked about the whole ecosystem, but I'm only able to answer from the XCP-ng side of things.

Running tcpdump switches the interface to promiscuous to allow all traffic that reaches the NIC to be dumped. So I assume the issue you had on your switches allowed traffic to reach the host, that was forwarding it to the VMs, and wasn't dropped because tcpdump switched the VIF into promiscuous mode.

If it seems resolved, that's good, otherwise let us know if we need to investigate further on this

@carldotcliff if you are 100% positive you see traffic on the VM that should not reach them, it is worth opening a ticket as this is not an intended behavior. If you do, tell in the ticket that this was discussed in the forum with David (me), so our support team can assign it to me if they want to.

For the dropped packets, I do not see any on my home setup, which is a pretty "small" network, in our lab, we do have some on our hosts. On bigger network, that could be pretty much anything, broadcast or multicast reaching the host that the NIC is chosing to drop itself, some NIC will also drop some discovery protocol frames, it would be hard to identify unfortunately, but that would not worry me as long as it is not a high count and not impacting performances.

I think the promisc mode is due to the fact the interfaces end up in OVS bridges, without that, the traffic coming from the outside to the VMs MAC addresses would be dropped.

Once it reach the OVS bridge the interface is in, it is up to OVS to act as a switch and only forward packets to the MAC he knows on its ports so all the traffic should not be forwarded to all the VIFs.

I just tested on 8.2 and 8.3:

• tcpdumpping icmp on 2 VMs, pinging VM1 does not show traffic on VM2, pinging VM2 does not show traffic on VM1, pinging the host show no traffic on the VMs
• tcpdumpping everything, only ignoring ssh (as I was logged in on both VM in ssh), the only traffic I see is the multicast traffic on the network.

So to answer your question, yes it is normal the NICs are in promiscuous, but that should not lead to all traffic going to all the VMs.

@irtaza9 Xen Orchestra premium (and from sources) has an SDN Controller plugin, it allows to create private networks and relies on GRE or VXLAN to create private networks, so as long as there are IP connectivity this can do the trick.

There are 2 blog posts on the subject:
https://xen-orchestra.com/blog/xo-sdn-controller/
https://xen-orchestra.com/blog/devblog-3-extending-the-sdn-controller/

And the documentation:
https://docs.xen-orchestra.com/sdn_controller

There are 2 main issues:

• being the star topology with an elected center that will be a bottleneck as all the traffic on this network will go through it
• there is (for now) no automated way to have a network management (dhcp, dns, gateway…), that should be part of our microsegmentation solution later on, but no ETA at this time

Is that answering your question?

To be honnest, I'm unsure, generally the XSAs have pretty clear impact description, here it just states:

resulting in e.g. guest user processes
being able to read data they ought not have access to.

No detail here if that's only inside the guest or if it could maybe reach data outside its domain scope. So I would not be able to say, but generally it is pretty clear in XSAs when there is a risk of accessing other guests data, my assumption would be that this is only inside the guest domain.

Hello @NielsH, no, that XSA is on the guest side, the fixes will be in the kernel used by the guest, unless we missed something, there is currently nothing to be done on the host kernel side.

Thanks for letting us know, and I'm happy you have thing working nicely now.
I think to mark this as resolved you need to convert your original post as a question, and it can then be marked as resolved. I actually cannot do it myself, I think only a few people have the permission to do it for others at Vates.

Wow, that's not great indeed.

The console too small, is pretty odd, as this should be at least the standard 80x24 for any kind of VGA.

Have you tried, from the idrac to login on the third terminal (alt+F3) ? It would be good to see if you can login or if the update + failing disk really broke everything. On the 2nd terminal (alt+F2) you should have system messages too, which in the ideal case should be empty…

Can you clarify a few points:

• is the SMB server always the same and the windows server, 11 and debian 12 are just client?
• Is the server a physical host outside of your pool or a VM?
• what is the server a windows, linux, freenas or a physical NAS?

It's just to get a better understanding of the setup.

On the guest tools and PV drivers side I'm not familiar with them myself on windows, maybe @dinhngtu could have some more insight?

Updated my machine at home, no issue so far.

We have 2 packages updated for the first 8.3 security update, a bit late to be part of the final ISO but they will be available at release time. For people willing to test them and provide feedback, see the announcement below.

---

New security update candidates (xen, intel-microcode)

A new XSA was published on September 24th 2024.
Intel published a microcode update on the September 10th 2024.

---

• XSA-462 a malicious HVM or PVH guest can trigger a DoS of the host.

---

SECURITY UPDATES

• xen-*:
      * Fix XSA-462 - x86: Deadlock in vlapic_error(). The handling of x86's APIC (Advanced Programmable Interrupt Controller) allows a guest to configure an illegal vector to handle error interrupts. This causes the vlapic_error() to recurse, this is protected, but the lock used for this protection will try to be taken recursiveley, leading to a deadlock.
• intel-microcode:
      * Latest Intel microcode update, still named IPU 2024.3, including security updates for:
          * INTEL-SA-01103
          * INTEL-SA-01097

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-candidates
yum update "xen-*" intel-microcode --enablerepo=xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

• xen: xen-4.17.5-3.xcpng8.3
• intel_microcode: intel-microcode-20240815-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the update

Until 8.3 release.

Update published: https://xcp-ng.org/blog/2024/09/27/september-2024-security-updates/

Thank you for the tests!

So if the initrd has been regenerated, it's likely the second part that fails, otherwise it is dracut, which is more of an issue.

@Andrew If I understand correctly that is ran after regenerating the initrd, but to be sure, can you check the date of your /boot/initrd-4.19.0+1.img on this host?

New security update candidates (xen, microcode_ctl)

A new XSA was published on September 24th 2024.
Intel published a microcode update on the September 10th 2024.
We also included an updated xcp-ng-release for testing, althrough not related to security.

---

• XSA-462 a malicious HVM or PVH guest can trigger a DoS of the host.

---

SECURITY UPDATES

• xen-*:
      * Fix XSA-462 - x86: Deadlock in vlapic_error(). The handling of x86's APIC (Advanced Programmable Interrupt Controller) allows a guest to configure an illegal vector to handle error interrupts. This causes the vlapic_error() to recurse, this is protected, but the lock used for this protection will try to be taken recursiveley, leading to a deadlock.
• microcode_ctl:
      * Latest Intel microcode update, still named IPU 2024.3, including security updates for:
          * INTEL-SA-01103
          * INTEL-SA-01097

Other updates

• xcp-ng-release:
      * Update the "XOA Quick deploy" feature in the host's web page.
      *  Point at repo.vates.tech for CentOS since mirrorlist.centos.org was cut
      * Add "(EOL)" to repo descriptions for EOL repos
      * Drop unused repos

Test on XCP-ng 8.2

yum clean metadata --enablerepo=xcp-ng-candidates
yum update "xen-*" microcode_ctl xcp-ng-release --enablerepo=xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

• xen: 4.13.5-9.44.1.xcpng8.2
• microcode_ctl: microcode_ctl-2.1-26.xs29.5.xcpng8.2
• xcp-ng-release: xcp-ng-release-8.2.1-13

What to test

Normal use and anything else you want to test.

Test window before official release of the update

~ 1 day because of security updates.

Update published https://xcp-ng.org/blog/2024/08/16/august-security-update/

Thank you all for testing