aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2019-12-05T07:44:28Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10624borgbackup and missing FUSE support2019-12-05T07:44:28ZLubos Dolezalborgbackup and missing FUSE support@\# borg -V
borg 1.1.10
1. borg mount $BORG\_REPO /mnt/backup/
borg mount not available: loading FUSE support failed \[ImportError:
No module named ‘llfuse’\]
@
*(from redmine: issue id 10624, created on 2019-06-26)*@\# borg -V
borg 1.1.10
1. borg mount $BORG\_REPO /mnt/backup/
borg mount not available: loading FUSE support failed \[ImportError:
No module named ‘llfuse’\]
@
*(from redmine: issue id 10624, created on 2019-06-26)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10623[3.10] evince: uninitialized memory use in function tiff_document_render() an...2019-07-23T11:06:32ZAlicha CH[3.10] evince: uninitialized memory use in function tiff_document_render() and tiff_document_get_thumbnail() (CVE-2019-11459)The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when pr...The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when processing certain TIFF image files.
### Reference:
https://gitlab.gnome.org/GNOME/evince/issues/1129
### Patch:
https://gitlab.gnome.org/GNOME/evince/commit/234f034a4d15cd46dd556f4945f99fbd57ef5f15
*(from redmine: issue id 10623, created on 2019-06-25, closed on 2019-07-09)*
* Relations:
* parent #10621
* Changesets:
* Revision c0566a6218a27e10bfdb13b56c92fe18ff7b71c7 by Natanael Copa on 2019-07-08T12:57:17Z:
```
community/evince: fix CVE-2019-11459
remove unused patch
fixes #10623
```3.10.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/10622[3.11] evince: uninitialized memory use in function tiff_document_render() an...2019-07-23T11:06:33ZAlicha CH[3.11] evince: uninitialized memory use in function tiff_document_render() and tiff_document_get_thumbnail() (CVE-2019-11459)The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when pr...The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when processing certain TIFF image files.
### Reference:
https://gitlab.gnome.org/GNOME/evince/issues/1129
### Patch:
https://gitlab.gnome.org/GNOME/evince/commit/234f034a4d15cd46dd556f4945f99fbd57ef5f15
*(from redmine: issue id 10622, created on 2019-06-25, closed on 2019-07-09)*
* Relations:
* parent #10621
* Changesets:
* Revision 21b65c26f6a56dd83992ba9783befc0455e3bdb0 by Natanael Copa on 2019-07-08T12:20:43Z:
```
community/evince: fix CVE-2019-11459
remove unused patch
fixes #10622
```3.11.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/10621evince: uninitialized memory use in function tiff_document_render() and tiff_...2019-07-23T11:06:34ZAlicha CHevince: uninitialized memory use in function tiff_document_render() and tiff_document_get_thumbnail() (CVE-2019-11459)The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when pr...The tiff\_document\_render() and tiff\_document\_get\_thumbnail()
functions in the TIFF document backend in GNOME Evince through 3.32.0
did
not handle errors from TIFFReadRGBAImageOriented(), leading to
uninitialized memory use when processing certain TIFF image files.
### Reference:
https://gitlab.gnome.org/GNOME/evince/issues/1129
### Patch:
https://gitlab.gnome.org/GNOME/evince/commit/234f034a4d15cd46dd556f4945f99fbd57ef5f15
*(from redmine: issue id 10621, created on 2019-06-25, closed on 2019-07-09)*
* Relations:
* child #10622
* child #10623https://gitlab.alpinelinux.org/alpine/aports/-/issues/10620[3.7] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-...2019-07-23T11:06:35ZAlicha CH[3.7] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10620, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* parent #10615
* Changesets:
* Revision 8cad441d0bb3d51026cb0231485848ce9a821e6a by Francesco Colista on 2019-07-03T14:49:20Z:
```
main/libvirt: security upgrade to 5.5.0
(CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)
Fixes #10620
```3.7.4Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10619[3.8] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-...2019-07-23T11:06:36ZAlicha CH[3.8] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10619, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* parent #10615
* Changesets:
* Revision 911332961e1fa7187cf3869595066bb18d226e27 by Francesco Colista on 2019-07-03T14:39:40Z:
```
main/libvirt: security upgrade to 5.5.0
(CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)
Fixes #10619
```3.8.5Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10618[3.9] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-...2019-07-23T11:06:37ZAlicha CH[3.9] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10618, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* parent #10615
* Changesets:
* Revision 011b9d5c5ae0af504ab1bb28a042d56676636a00 by Francesco Colista on 2019-07-03T14:22:00Z:
```
main/libvirt: security upgrade
(CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)
Fixes #10618
```3.9.5Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10617[3.10] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE...2019-07-23T11:06:38ZAlicha CH[3.10] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10617, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* parent #10615
* Changesets:
* Revision d8c86688b6afbadd18a78b88a430ed4cabe78e7c by Francesco Colista on 2019-07-03T09:39:08Z:
```
main/libvirt: security upgrade to 5.5.0
This upgrade fixes the following CVE:
- CVE-2019-10168
- CVE-2019-10167
- CVE-2019-10166
- CVE-2019-10161
Fixes #10617
```3.10.1Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10616[3.11] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE...2019-07-23T11:06:40ZAlicha CH[3.11] libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10616, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* parent #106153.11.0Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10615libvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-1...2019-07-23T11:06:41ZAlicha CHlibvirt: Multiple vulnerabilities (CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168)CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDo...CVE-2019-10161: arbitrary file read/exec via virDomainSaveImageGetXMLDesc API
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which
would be accessed with the permissions of the libvirtd process. An
attacker with access to the libvirtd socket could use this to probe
the
existence of arbitrary files, cause denial of service or cause
libvirtd
to execute arbitrary programs.
This vulnerability was first present in libvirt v0.9.4.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10161
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10161
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580
CVE-2019-10166: virDomainManagedSaveDefineXML API exposed to readonly clients
-----------------------------------------------------------------------------
It was discovered that libvirtd would permit readonly clients to use
the
virDomainManagedSaveDefineXML() API, which would permit them to modify
managed save state files. If a managed save had already been created
by
a privileged user, a local attacker could modify this file such that
libvirtd would execute an arbitrary program when the domain was resumed.
This vulnerability was first present in libvirt v3.6.1.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10166
https://security-tracker.debian.org/tracker/CVE-2019-10166
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=db0b78457f183e4c7ac45bc94de86044a1e2056a
CVE-2019-10167: arbitrary command execution via virConnectGetDomainCapabilities API
-----------------------------------------------------------------------------------
The virConnectGetDomainCapabilities() libvirt API accepts an
“emulatorbin”
argument to specify the program providing emulation for a domain.
Since
v1.2.19, libvirt will execute that program to probe the domain’s
capabilities. Read-only clients could specify an arbitrary path for
this
argument, causing libvirtd to execute a crafted executable with its own
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://security-tracker.debian.org/tracker/CVE-2019-10167
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8afa68bac0cf99d1f8aaa6566685c43c22622f26
CVE-2019-10168: arbitrary command execution via virConnectBaselineHypervisorCPU and virConnectCompareHypervisorCPU APIs
-----------------------------------------------------------------------------------------------------------------------
The virConnectBaselineHypervisorCPU() and
virConnectCompareHypervisorCPU()
libvirt APIs accept an “emulator” argument to specify the program
providing
emulation for a domain. Since v1.2.19, libvirt will execute that program
to
probe the domain’s capabilities. Read-only clients could specify an
arbitrary
path for this argument, causing libvirtd to execute a crafted executable
with
its own privileges.
### Fixed In Version:
libvirt 4.10.1, libvirt 5.4.1
### References:
https://bugzilla.redhat.com/show\_bug.cgi?id=CVE-2019-10168
https://security-tracker.debian.org/tracker/CVE-2019-10168
### Patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf6c2830b6c338b1f5699b095df36f374777b291
*(from redmine: issue id 10615, created on 2019-06-25, closed on 2019-07-04)*
* Relations:
* child #10616
* child #10617
* child #10618
* child #10619
* child #10620Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10614Syslinux should use /boot/syslinux instead /boot2019-07-23T11:06:42ZalgitbotSyslinux should use /boot/syslinux instead /bootAll the scripts eg **update-extlinux** installing extlinux into
**/boot**
This is kindly wrong because syslinux is searching **ldlinux.c32** in
"/boot/syslinux",
"/syslinux",
"/"
but not in **/boot**
It will work fine if ...All the scripts eg **update-extlinux** installing extlinux into
**/boot**
This is kindly wrong because syslinux is searching **ldlinux.c32** in
"/boot/syslinux",
"/syslinux",
"/"
but not in **/boot**
It will work fine if **/boot** located on separated partition, but it
will not work if you would try to install alpine linux using single
partition.
Look more:
https://www.syslinux.org/archives/2012-December/019143.html
https://github.com/geneC/syslinux/blob/2ea44cbedb297bd6b409d5c1e0402d5f89592be4/core/elflink/load\_env32.c\#L167-L169
*(from redmine: issue id 10614, created on 2019-06-24, closed on 2019-06-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10613HDF5 version2019-07-24T22:46:45ZalgitbotHDF5 versionIn commit 2df9ee77b86b192cc2be14300c13df3593dd0f69
<https://git.alpinelinux.org/aports/commit/?id=2df9ee77b86b192cc2be14300c13df3593dd0f69>
it seems that the HDF5 library version was upgraded to 1.10.5, but the
headers were not, ...In commit 2df9ee77b86b192cc2be14300c13df3593dd0f69
<https://git.alpinelinux.org/aports/commit/?id=2df9ee77b86b192cc2be14300c13df3593dd0f69>
it seems that the HDF5 library version was upgraded to 1.10.5, but the
headers were not, causing a python script using h5py to fail. Let me
know
if there is any other information that would be helpful.
Headers are 1.10.4, library is 1.10.5
SUMMARY OF THE HDF5 CONFIGURATION
=
General Information:
—————————-
HDF5 Version: 1.10.5
Configured on: 2019-06-20
Configured by: Unix Makefiles
Host system: Linux-4.14.89-0-vanilla
Uname information: Linux
Byte sex: little-endian
Installation point: /usr
Alpine Linux 3.8
Using packages (gitlab CI environment):
\- echo “`edge http://dl-cdn.alpinelinux.org/alpine/edge/main" >>
/etc/apk/repositories
- echo "`edge http://dl-cdn.alpinelinux.org/alpine/edge/community”
>>
/etc/apk/repositories
- echo "`edge http://dl-cdn.alpinelinux.org/alpine/edge/testing" >>
/etc/apk/repositories
- apk update
- apk add --update g++`edge gcc@edge gfortran@edge make python git
bash
bc wget zlib-dev hwloc@edge openmpi-dev@edge openssh-client
py2-h5py@edge
py2-numpy@edge hdf5@edge
Best,
Sherwood Richers, III
N3AS Postdoctoral Fellow
North Carolina State University
sites.google.com/view/sherwoodrichers
*(from redmine: issue id 10613, created on 2019-06-24)*LeoLeohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10612Missing proj4-dev2020-04-27T09:19:43ZNikola RadovanovicMissing proj4-devHi, while running my Docker image, it turns out suddenly proj4-dev
package is missing. Can someone please take a look?
Kindest regards
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-...Hi, while running my Docker image, it turns out suddenly proj4-dev
package is missing. Can someone please take a look?
Kindest regards
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
v3.9.4-48-g0e9f47894f [http://dl-cdn.alpinelinux.org/alpine/v3.9/main]
v3.9.4-45-ge50d4dec98 [http://dl-cdn.alpinelinux.org/alpine/v3.9/community]
OK: 9771 distinct packages available
(1/17) Installing binutils (2.31.1-r2)
(2/17) Installing libmagic (5.36-r0)
(3/17) Installing file (5.36-r0)
(4/17) Installing gmp (6.1.2-r1)
(5/17) Installing isl (0.18-r0)
(6/17) Installing libgomp (8.3.0-r0)
(7/17) Installing libatomic (8.3.0-r0)
(8/17) Installing mpfr3 (3.1.5-r1)
(9/17) Installing mpc1 (1.0.3-r1)
(10/17) Installing gcc (8.3.0-r0)
(11/17) Installing musl-dev (1.1.20-r4)
(12/17) Installing libc-dev (0.7.1-r0)
(13/17) Installing g++ (8.3.0-r0)
(14/17) Installing make (4.2.1-r2)
(15/17) Installing fortify-headers (1.0-r0)
(16/17) Installing build-base (0.5-r1)
(17/17) Installing wget (1.20.3-r0)
Executing busybox-1.29.3-r10.trigger
OK: 209 MiB in 48 packages
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
ERROR: unsatisfiable constraints:
proj4-dev (missing):
required by: world[proj4-dev]
ERROR: Service 'postgres' failed to build: The command '/bin/sh -c apk update && apk add bash wget build-base gcc g++ make && apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/testing gdal-dev geos-dev json-c-dev libpq libxml2-dev musl-dev pcre-dev perl postgresql postgresql-contrib proj4-dev && rm -rf /var/cache/apk/' returned a non-zero code: 1
*(from redmine: issue id 10612, created on 2019-06-24, closed on 2019-06-28)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10611Chromium for armhf2019-10-17T15:00:55ZMichal ArtazovChromium for armhfHi,
I see that Chromium used to be enabled but then it was disabled again in
commit 40635ea8bac5ac0c8b8f25bbd78c06f6c81eb9ae with comment “arm builds
need more work as they need clang”. I’m not sure what exactly that
implies but I’d li...Hi,
I see that Chromium used to be enabled but then it was disabled again in
commit 40635ea8bac5ac0c8b8f25bbd78c06f6c81eb9ae with comment “arm builds
need more work as they need clang”. I’m not sure what exactly that
implies but I’d like to ask, if there are any plans to make this
available any time soon. We really needs it for Raspberry Pi. Thanks!
*(from redmine: issue id 10611, created on 2019-06-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10610Cross Compile Bootstrapping OpenSSH fails2021-06-10T11:50:00ZAnthony DaviesCross Compile Bootstrapping OpenSSH failsFails due to requiring libedit to compile.
Fix was to add modify built packages to compile ncurses, libedit then
openssh.
*(from redmine: issue id 10610, created on 2019-06-24)*Fails due to requiring libedit to compile.
Fix was to add modify built packages to compile ncurses, libedit then
openssh.
*(from redmine: issue id 10610, created on 2019-06-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10609Go bootstrap compile fails for cross compile2019-08-10T05:39:13ZAnthony DaviesGo bootstrap compile fails for cross compileWhen running ./bootstrap.sh from aports when community/go attempts to
compile the dependency check faisl due to searching build-base-armhf (in
my instance) in the cross compiled community repo rather then the main
repo (based on manually...When running ./bootstrap.sh from aports when community/go attempts to
compile the dependency check faisl due to searching build-base-armhf (in
my instance) in the cross compiled community repo rather then the main
repo (based on manually running CHOST=armhf BOOTSTRAP=bootimage abuild
-rv) copying the go aports to main and replacing community/go with go in
bootstrap.sh resolved the issue for me.
*(from redmine: issue id 10609, created on 2019-06-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10608popt can't download source2019-07-23T10:34:23ZAnthony Daviespopt can't download sourcepopt won’t compile as rpm5.org has disappeared off the internet and has
been failing to resolve for a number of weeks.
Need to find a new source for the popt packate. I used
ftp://anduin.linuxfromscratch.org/BLFS/
*(from redmine: issu...popt won’t compile as rpm5.org has disappeared off the internet and has
been failing to resolve for a number of weeks.
Need to find a new source for the popt packate. I used
ftp://anduin.linuxfromscratch.org/BLFS/
*(from redmine: issue id 10608, created on 2019-06-24)*Anthony DaviesAnthony Davieshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10607aports/scripts/bootstrap.sh doesn't show usage2022-07-26T21:54:31ZAnthony Daviesaports/scripts/bootstrap.sh doesn't show usageWhen executing bootstrap.sh an error is given “&gt;&gt;>ERROR:
CBUILDROOT not set for” rather then displaying the usage of the command.
*(from redmine: issue id 10607, created on 2019-06-24)*When executing bootstrap.sh an error is given “>>>ERROR:
CBUILDROOT not set for” rather then displaying the usage of the command.
*(from redmine: issue id 10607, created on 2019-06-24)*Anthony DaviesAnthony Davieshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10605OpenSMTPd 6.4.x2019-12-05T07:45:11ZKévin GuignardOpenSMTPd 6.4.xOpenSMTPd package is already available, but not the latest version
**6.4.1** *<span lang="1"></span>*.
However since **6.4.0** *<span lang="2"></span>* the configuration file
syntax has been completely reworked, breaking compatibility w...OpenSMTPd package is already available, but not the latest version
**6.4.1** *<span lang="1"></span>*.
However since **6.4.0** *<span lang="2"></span>* the configuration file
syntax has been completely reworked, breaking compatibility with
previous configuration files
and OpenSMTPD now depends on LibreSSL as an SSL library (efforts will no
longer be done to support OpenSSL too).
Do you plan to provide OpenSMTPd, maybe in a new package
“opensmtpd-6.4”, with the new features (including the incoming ECDSA
support) ?
*<span lang="1"></span>*
https://www.opensmtpd.org/announces/release-6.4.1.txt
*<span lang="2"></span>*
https://www.opensmtpd.org/announces/release-6.4.0.txt
*(from redmine: issue id 10605, created on 2019-06-23)*3.11.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/10604util-linux-dev conflicts with ossp-uuid (from testing?!)2019-07-23T10:35:34ZOliver Smithutil-linux-dev conflicts with ossp-uuid (from testing?!)We’re currently seeing this error in Alpine edge:
ERROR: unsatisfiable constraints:
util-linux-dev-2.33.2-r0:
conflicts: ossp-uuid-1.6.2-r0[pc:uuid=2.33.2]
satisfies: glib-dev-2.60.4-r0[util-linux-dev]
...We’re currently seeing this error in Alpine edge:
ERROR: unsatisfiable constraints:
util-linux-dev-2.33.2-r0:
conflicts: ossp-uuid-1.6.2-r0[pc:uuid=2.33.2]
satisfies: glib-dev-2.60.4-r0[util-linux-dev]
glib-dev-2.60.4-r0[pc:mount>=2.23]
dbus-dev-1.12.16-r0[util-linux-dev]
.pmbootstrap-20190623.123939[util-linux-dev]
fontconfig-dev-2.13.1-r0[pc:uuid]
ossp-uuid-1.6.2-r0:
conflicts: util-linux-dev-2.33.2-r0[pc:uuid=1.6.2]
satisfies: .pmbootstrap-20190623.123939[ossp-uuid]
fontconfig-dev-2.13.1-r0[pc:uuid]
I’ve tried to rebuild ossp-uuid, that did not help it. So I guess we
need to rebuild util-linux-dev, but that did not work out of the box, at
least in my setup.
...
>>> blkid*: Running split function blkid...
>>> blkid*: Preparing subpackage blkid...
>>> blkid*: Stripping binaries
>>> blkid*: Running postcheck for blkid
>>> setpriv*: Running split function setpriv...
>>> setpriv*: Preparing subpackage setpriv...
>>> setpriv*: Stripping binaries
>>> setpriv*: Running postcheck for setpriv
>>> py-libmount*: Running split function _py...
mv: can't rename '/home/pmos/build/pkg/util-linux/usr/lib/python*': No such file or directory
>>> ERROR: py-libmount*: _py failed
>>> ERROR: util-linux*: prepare_subpackages failed
>>> ERROR: util-linux: rootpkg failed
Both util-linux-dev and ossp-uuid are Alpine packages, so this should
not be postmarketOS related.
*(from redmine: issue id 10604, created on 2019-06-23)*LeoLeo