cc4919da89
XSA-197 Issue Description: > The compiler can emit optimizations in qemu which can lead to double > fetch vulnerabilities. Specifically data on the rings shared > between qemu and the hypervisor (which the guest under control can > obtain mappings of) can be fetched twice (during which time the > guest can alter the contents) possibly leading to arbitrary code > execution in qemu. More: https://xenbits.xen.org/xsa/advisory-197.html XSA-199 Issue Description: > The code in qemu which implements ioport read/write looks up the > specified ioport address in a dispatch table. The argument to the > dispatch function is a uint32_t, and is used without a range check, > even though the table has entries for only 2^16 ioports. > > When qemu is used as a standalone emulator, ioport accesses are > generated only from cpu instructions emulated by qemu, and are > therefore necessarily 16-bit, so there is no vulnerability. > > When qemu is used as a device model within Xen, io requests are > generated by the hypervisor and read by qemu from a shared ring. The > entries in this ring use a common structure, including a 64-bit > address field, for various accesses, including ioport addresses. > > Xen will write only 16-bit address ioport accesses. However, > depending on the Xen and qemu version, the ring may be writeable by > the guest. If so, the guest can generate out-of-range ioport > accesses, resulting in wild pointer accesses within qemu. More: https://xenbits.xen.org/xsa/advisory-199.html XSA-207 Issue Description: > Certain internal state is set up, during domain construction, in > preparation for possible pass-through device assignment. On ARM and > AMD V-i hardware this setup includes memory allocation. On guest > teardown, cleanup was erroneously only performed when the guest > actually had a pass-through device assigned. More: https://xenbits.xen.org/xsa/advisory-207.html XSA-209 Issue Description: > When doing bitblt copy backwards, qemu should negate the blit width. > This avoids an oob access before the start of video memory. More: https://xenbits.xen.org/xsa/advisory-208.html XSA-208 Issue Description: > In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine > cirrus_bitblt_cputovideo fails to check wethehr the specified memory > region is safe. More: https://xenbits.xen.org/xsa/advisory-209.html |
||
|---|---|---|
| .github | ||
| doc | ||
| lib | ||
| maintainers | ||
| nixos | ||
| pkgs | ||
| .editorconfig | ||
| .gitignore | ||
| .mention-bot | ||
| .travis.yml | ||
| .version | ||
| COPYING | ||
| default.nix | ||
| README.md | ||
Nixpkgs is a collection of packages for the Nix package manager. It is periodically built and tested by the hydra build daemon as so-called channels. To get channel information via git, add nixpkgs-channels as a remote:
% git remote add channels git://github.com/NixOS/nixpkgs-channels.git
For stability and maximum binary package support, it is recommended to maintain
custom changes on top of one of the channels, e.g. nixos-16.09 for the latest
release and nixos-unstable for the latest successful build of master:
% git remote update channels
% git rebase channels/nixos-16.09
For pull-requests, please rebase onto nixpkgs master.
NixOS linux distribution source code is located inside
nixos/ folder.
- NixOS installation instructions
- Documentation (Nix Expression Language chapter)
- Manual (How to write packages for Nix)
- Manual (NixOS)
- Nix Wiki (deprecated, see milestone "Move the Wiki!")
- Continuous package builds for unstable/master
- Continuous package builds for 16.09 release
- Tests for unstable/master
- Tests for 16.09 release
Communication: