-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742 / XSA-403 version 3 Linux disk/nic frontends data leaks UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). IMPACT ====== An untrusted backend can access data not intended to be shared. If such mappings are made with write permissions the backend could also cause malfunctions and/or crashes to consumers of contiguous data in the shared pages. VULNERABLE SYSTEMS ================== All Linux guests using PV devices are vulnerable in case potentially malicious PV device backends are being used. MITIGATION ========== There is no mitigation available other than not using PV devices in case a backend is suspected to be potentially malicious. CREDITS ======= The issue related to not zeroing memory areas used for shared communications was discovered by Roger Pau Monné of Citrix. The issue related to leaking contiguous data in granted pages was disclosed publicly. RESOLUTION ========== Applying the attached patches to Linux makes the disk and network frontends capable of protecting themselves against potentially malicious backends. The signaling of whether a frontend should consider a backend as potentially malicious can be done from either the Linux kernel command line or the toolstack. Two different patches are provided for each Xen branch, but only the first patch will be applied to the official Xen repository for each branch. For the xen-unstable branch patch 1 introduces a new field to the disk and nic configurations that allow signaling on a per-device basis whether the backend should be trusted. This is an ABI incompatible change, and cannot be applied to stable branches. Patch 2 introduces support to libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in order to set whether disk and network frontends should be trusted in the absence of a per-device setting. Patch 2 is provided as a courtesy for users of stable branches that might come to rely on this behavior. For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces support to libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in order to set whether disk and network backends should be trusted. Patch 2 reverts patch 1 and instead provides the more fine grained per-device options that break the libxl ABI. Note that applying patch 2 to any of the stable releases will require a rebuild of any consumers of the libxl library, as it introduces an ABI breakage and hence won't be applied to the official repository stable branches. Users of stable releases wanting to use the functionality provided by patch 2 will need to apply it manually. Regardless of the combinations of patches applied, in the absence of any environment variable mentioned above backends will be trusted by default. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa403/xsa403-?.patch xen-unstable xsa403/xsa403-4.16-?.patch Xen 4.16.x - Xen 4.15.x xsa403/xsa403-4.14-?.patch Xen 4.14.x - Xen 4.13.x xsa403/xsa403-linux-*.patch Linux 5.18 $ sha256sum xsa403*/* f28624407a3f040456ef2c52a18d8dcf486274ea082335ea38c9791646f4989c xsa403/xsa403-1.patch e06451655775009ceaf460bbba65374c05203eed295ff43fc5fa32a8d390a94a xsa403/xsa403-2.patch 5efb8af5ed5614f5e2e8d606a9debb3503cd9e114551525826fc5a7f9de91c02 xsa403/xsa403-4.14-1.patch 9ead8c6e4d694f3042c8d2fab4ea81619c4a9fc2aa7a0f485e9c873d927d283c xsa403/xsa403-4.14-2.patch ae778d5731ae663cca32d59ed9b1be51200b85c441771a9c6657c112e9550a15 xsa403/xsa403-4.16-1.patch 8ef7bd06f646fa72f22892d2b72ae44ff4e6c00d9817d52a71262be174862ee3 xsa403/xsa403-4.16-2.patch 8192d0c313448d7aa12c13d1632db3bd68835c19f60c237b87548d5c528852b0 xsa403/xsa403-linux-1.patch 4b288d3266f9396bedc7de823909aed4d1a89fe86b2edd1d625b0e32741688cf xsa403/xsa403-linux-2.patch dddf68625be516f0524fe7bb439272769cf7d612e15e00ac936bc047fd182f8a xsa403/xsa403-linux-3.patch 4e38a50a0e5ec6e90d2fffef003f8eb93a68518f4636c15cd59568ddf1861988 xsa403/xsa403-linux-4.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the patches need to be applied in the affected guests. Switching from PV to non-PV devices is observable by the guests and has usually a bad performance impact. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmLEFf0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZSVkIALkao7hSqBVJhnVifpXpLn+mxfECoI6lgQ1sphz6 oJ7U2QxuI6j6gVSUPk3GglYjKurGBYZjBAX6fBU8po9Zdagz/iuOXCif41NHobP8 POscgXMjKR4HPE8liXNYzSbTAbn7qiyNCxBO5yGK/jPMIC8K9+0ed+9ese6VVXSj 4buiqlkLb9FP5xTCGbtt/raZoGVVRx+LLhwC8dlNXllEvI1cJIK18pfnPF+ZUQwL kXAx2figt3ZE1yNVv4Efnp2bMvv/XUGNU6X/ONP7wCKChzTOGdMyPMBJ1r73ceAn TSvVuWDBoiWCLVIY1leTjRx9xxbQq84htGG68i8nQrHckz8= =Wl2G -----END PGP SIGNATURE-----