From ${URL} : A flaw was found in the way qemu validates addresses when guest accesses the config space of a virtio device. If the virtio device has zero/small sized config space, such as virtio-rng, a privileged guest user could use this flaw to access the matching host's qemu address space and thus increase their privileges on the host. Acknowledgements: This issue was found by Jason Wang of Red Hat. References: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05013.html Proposed upstream patch: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05254.html @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not
The issue only exists with older kernels when there is no min_mmap_addr with a newer qemu (1.3.0 or newer). Not sure what maintainers really can do/should do. Really up to the security team. No current sys-kernel/gentoo-sources in tree are affected with any app-emulation/qemu in tree.
@Cardoe: before I close this, could you please clarify which kernel versions would be affected?
@kernel, can we confirm if any of the in tree security supported kernels are vulnerable?
(In reply to Doug Goldstein from comment #1) > No current sys-kernel/gentoo-sources in tree are affected with any > app-emulation/qemu in tree. I suggest we resolve this issue now? qemu is currently at version 2.7.0.
(In reply to Chris Reffett from comment #2) > @Cardoe: before I close this, could you please clarify which kernel versions > would be affected? Since kernel v2.6.23-rc1, mmap protection was available in kernels containing commit ed0321895182ffb6ecf210e066d87911b270d587. However, this protection was disabled per default. This became at least configurable with >=2.6.25-rc1 due to commit a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84. Looks like until 2.6.31-rc7, the protection was still disabled per default. So vanilla kernels shipping commit 788084aba2ab7348257597496befcbccabdc98a3 were the first kernels with mmap_min_addr != 0 per default. Debian set a value >0 with their 2.6.26-21 kernel package for the first time. I haven't checked if Gentoo ever patched any available kernel sources before upstream activated protection per default but there are indications (https://forums.gentoo.org/viewtopic-p-5891369.html) that at least gentoo-sources-2.6.30-r4 has set a value of 4096. So a safe answer to Chris' question is <*-sources-2.6.31 in the assumption that we didn't mess with this option. Closing because repository is clean. All done.
