aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2021-01-29T01:16:23Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10627clang requires a few gcc libraries, which supposed to be privided by compiler-rt2021-01-29T01:16:23ZTrevis Schifferclang requires a few gcc libraries, which supposed to be privided by compiler-rtHello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
...Hello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
crtbegin.o
crtend.o
Above libs are not usable without gcc libs (Thus I guess GPL is still
enforced?).
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtendS.o: No such file or directory
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
b17wise@eula47 /tmp % sudo apk add gcc
[sudo] password for b17wise:
(1/8) Installing binutils (2.32-r0)
(2/8) Installing isl (0.18-r0)
(3/8) Installing libgomp (8.3.0-r0)
(4/8) Installing libatomic (8.3.0-r0)
(5/8) Installing mpfr3 (3.1.5-r1)
(6/8) Installing mpc1 (1.1.0-r0)
(7/8) Installing gcc (8.3.0-r0)
(8/8) Installing gcc-zsh-completion (5.7.1-r0)
Executing busybox-1.30.1-r2.trigger
OK: 2012 MiB in 482 packages
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
b17wise@eula47 /tmp % ./hello
Hello, Alpine
b17wise@eula47 /tmp % apk info -L gcc | grep -e *crtendS*
b17wise@eula47 /tmp % apk info -L gcc | grep crt
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbegin.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtend.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginT.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec32.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec80.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec64.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtendS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtfastmath.o
Full log can be found here: http://0x0.st/z2k6.txt
Also there was an issue raised in 2017: https://reviews.llvm.org/D28791
*(from redmine: issue id 10627, created on 2019-06-27)*3.10.6https://gitlab.alpinelinux.org/alpine/aports/-/issues/10626[3.11] bind: Race condition when discarding malformed packets can cause bind ...2019-08-08T10:00:24ZAlicha CH[3.11] bind: Race condition when discarding malformed packets can cause bind to exit with assertion failure (CVE-2019-6471)A race condition which may occur when discarding malformed packets can
result in BIND exiting due to a REQUIRE assertion failure in
dispatch.c.
An attacker who can cause a resolver to perform queries which will be
answered by a server ...A race condition which may occur when discarding malformed packets can
result in BIND exiting due to a REQUIRE assertion failure in
dispatch.c.
An attacker who can cause a resolver to perform queries which will be
answered by a server which responds with deliberately malformed
answers
can cause named to exit, denying service to clients.
### Versions affected:
BIND 9.11.0 ->9.11.7, 9.12.0 ->9.12.4-P1, 9.14.0 ->9.14.2.
Also all releases of the BIND 9.13 development branch and
version 9.15.0 of the BIND 9.15 development branch. BIND Supported
Preview Edition versions 9.11.3-S1 ->9.11.7-S1.
### Fixed In Version:
bind 9.11.8, bind 9.12.4-P2, bind 9.14.3, bind 9.15.1
### References:
https://kb.isc.org/docs/cve-2019-6471
*(from redmine: issue id 10626, created on 2019-06-27)*3.11.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/10625Failed to update readline2020-03-16T01:19:29ZRoi GreenbergFailed to update readlineHi.
I have a container with many APKs install on it. I’m to update readline,
but I’m getting the following error:
`bash-4.4# apk add readline -l
ERROR: unsatisfiable constraints:
Huh? Error reporter did not find the broken constrai...Hi.
I have a container with many APKs install on it. I’m to update readline,
but I’m getting the following error:
`bash-4.4# apk add readline -l
ERROR: unsatisfiable constraints:
Huh? Error reporter did not find the broken constraints.
`
I tried to manually update any previous dependencies but nothing helps.
I will appreciate any help!
*(from redmine: issue id 10625, created on 2019-06-26)*https://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 Davies