Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #42: Linux netback driver OOB access in hash handling (XSA-270). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #42 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-270 in the XSA Tracker:
---===[ Qubes Security Bulletin #42 ]===--- 2018-08-14 Linux netback driver OOB access in hash handling (XSA-270) Summary ======== On 2018-08-14, the Xen Security Team published Xen Security Advisory 270 (XSA-270)  with the following description: | Linux's netback driver allows frontends to control mapping of requests | to request queues. When processing a request to set or change this | mapping, some input validation was missing or flawed. | | A malicious or buggy frontend may cause the (usually privileged) | backend to make out of bounds memory accesses, potentially resulting | in one or more of privilege escalation, Denial of Service (DoS), or | information leaks. Impact for Qubes ================= The bug affects only the network backend driver, which means that any qube with access to a network can attack the qube that provides it with access to that network. For example: - In a default configuration, any network-connected AppVM can attack sys-firewall, which can in turn attack sys-net. - Any qube connected to a VPN Gateway  can attack the VPN Gateway and potentially steal VPN credentials. - Any Whonix Workstation can attack the Whonix Gateway to which it is connected, potentially compromising anonymity. It is important to note, however, that dom0 and network-disconnected qubes are not affected. Patching ========= The Xen Project has provided patches to fix this issue. The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes 3.2: - kernel packages, version 4.14.57-2 - kernel-latest packages, version 4.17.9-2 For Qubes 4.0: - kernel packages, version 4.14.57-2 - kernel-latest packages, version 4.17.9-2 The kernel-latest packages are not installed by default. If you do not already have them installed, then it is not necessary to install them in order to fix this issue. However, if you already have them installed, then we recommend that you update them to the version containing the fix for this issue. The packages are to be installed in dom0 via the Qubes VM Manager or via the qubes-dom0-update command as follows: For updates from the stable repository (not immediately available): $ sudo qubes-dom0-update For updates from the security-testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing A restart of all network-providing qubes will be required afterwards. These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Linux binaries. Users who are using in-VM kernels  for any of their VMs should note that installing the packages listed above will not update their in-VM kernels. We recommend that these users install updates for their in-VM kernels when the appropriate distributions provide kernel updates that fix this issue. Credits ======== See the original Xen Security Advisory. References ===========  https://xenbits.xen.org/xsa/advisory-270.html  https://www.qubes-os.org/doc/vpn/  https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm-r40 -- The Qubes Security Team https://www.qubes-os.org/security/