An errata patch for the kernel has been released for OpenBSD 6.9 and
OpenBSD 7.0.
The kernel could leak memory when closing unix sockets.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
https://www.openbsd.org/errata70.html
Saturday, October 30, 2021
rpki-client-7.4 released
rpki-client 7.4 has just been released and will be available in the
rpki-client directory of any OpenBSD mirror soon.
rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties (RP) to
facilitate validation of a BGP announcement. The program queries the
global RPKI repository system and outputs validated ROA payloads in
the configuration format of OpenBGPD, BIRD, and also as CSV or JSON
objects for consumption by other routing stacks.
See RFC 6811 for a description of how BGP Prefix Origin Validation
secures the Internet's global routing system.
rpki-client was primarily developed by Kristaps Dzonsons, Claudio
Jeker, Job Snijders, Theo Buehler, Theo de Raadt and Sebastian Benoit
as part of the OpenBSD Project.
This release includes the following changes to the previous release:
* Added support for validating BGPsec Router Public Keys.
* Fix issues with chunked transfer encoding in the RRDP HTTP client.
* Cleanup and improvement of how IO is handled.
* Improvements in the way X509 certificates are verified.
* Make rpki-client more resilient regarding untrusted input:
- Limit the allowed character set for filename listings on
Manifests.
- Limit the length of SIA URIs.
- Limit the size of certain untrusted inputs.
- Don't exit on failures to parse x509 objects.
- Limit the size of objects retreived via RRDP or RSYNC.
- Limit the number of FileAndHash entries on a manifest.
- Constrain RRDP such that the delta/snapshot files must be hosted
at the same host as the notification file.
rpki-client works on all operating systems with a libcrypto library
based on OpenSSL 1.1 or LibreSSL 3.3, and a libtls library compatible
with LibreSSL 3.3 or later.
rpki-client is known to compile and run on at least the following
operating systems: Alpine, CentOS, Debian, Fedora, FreeBSD, Red Hat,
Rocky, Ubuntu, macOS, and of course OpenBSD!
It is our hope that packagers take interest and help adapt
rpki-client-portable to more distributions.
The mirrors where rpki-client can be found are on
https://www.rpki-client.org/portable.html
Reporting Bugs:
===============
General bugs may be reported to tech@openbsd.org
Portable bugs may be filed at
https://github.com/rpki-client/rpki-client-portable
We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release
possible.
Assistance to coordinate security issues is available via
security@openbsd.org.
rpki-client directory of any OpenBSD mirror soon.
rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties (RP) to
facilitate validation of a BGP announcement. The program queries the
global RPKI repository system and outputs validated ROA payloads in
the configuration format of OpenBGPD, BIRD, and also as CSV or JSON
objects for consumption by other routing stacks.
See RFC 6811 for a description of how BGP Prefix Origin Validation
secures the Internet's global routing system.
rpki-client was primarily developed by Kristaps Dzonsons, Claudio
Jeker, Job Snijders, Theo Buehler, Theo de Raadt and Sebastian Benoit
as part of the OpenBSD Project.
This release includes the following changes to the previous release:
* Added support for validating BGPsec Router Public Keys.
* Fix issues with chunked transfer encoding in the RRDP HTTP client.
* Cleanup and improvement of how IO is handled.
* Improvements in the way X509 certificates are verified.
* Make rpki-client more resilient regarding untrusted input:
- Limit the allowed character set for filename listings on
Manifests.
- Limit the length of SIA URIs.
- Limit the size of certain untrusted inputs.
- Don't exit on failures to parse x509 objects.
- Limit the size of objects retreived via RRDP or RSYNC.
- Limit the number of FileAndHash entries on a manifest.
- Constrain RRDP such that the delta/snapshot files must be hosted
at the same host as the notification file.
rpki-client works on all operating systems with a libcrypto library
based on OpenSSL 1.1 or LibreSSL 3.3, and a libtls library compatible
with LibreSSL 3.3 or later.
rpki-client is known to compile and run on at least the following
operating systems: Alpine, CentOS, Debian, Fedora, FreeBSD, Red Hat,
Rocky, Ubuntu, macOS, and of course OpenBSD!
It is our hope that packagers take interest and help adapt
rpki-client-portable to more distributions.
The mirrors where rpki-client can be found are on
https://www.rpki-client.org/portable.html
Reporting Bugs:
===============
General bugs may be reported to tech@openbsd.org
Portable bugs may be filed at
https://github.com/rpki-client/rpki-client-portable
We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release
possible.
Assistance to coordinate security issues is available via
security@openbsd.org.
OpenBSD Errata: October 31, 2021 (bpf)
An errata patch for the kernel has been released for OpenBSD 6.9 and
OpenBSD 7.0.
Opening /dev/bpf too quickly too often could lead to a kernel crash.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
https://www.openbsd.org/errata70.html
OpenBSD 7.0.
Opening /dev/bpf too quickly too often could lead to a kernel crash.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
https://www.openbsd.org/errata70.html
OpenBSD Errata: October 31, 2021 (nsd)
An errata patch for nsd(8) has been released for OpenBSD 7.0.
In certain configurations, nsd can be crashed remotely.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata70.html
In certain configurations, nsd can be crashed remotely.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata70.html
Thursday, October 28, 2021
[USN-5126-2] Bind vulnerability
==========================================================================
Ubuntu Security Notice USN-5126-2
October 28, 2021
bind9 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
Bind could be made to consume resources if it received specially crafted
network traffic.
Software Description:
- bind9: Internet Domain Name Server
Details:
USN-5126-1 fixed a vulnerability in Bind. This update provides
the corresponding update for Ubuntu 14.04 ESM and Ubuntu 16.04 ESM.
Original advisory details:
Kishore Kumar Kothapalli discovered that Bind incorrectly handled the lame
cache when processing responses. A remote attacker could possibly use this
issue to cause Bind to consume resources, resulting in a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
bind9 1:9.10.3.dfsg.P4-8ubuntu1.19+esm1
Ubuntu 14.04 ESM:
bind9 1:9.9.5.dfsg-3ubuntu0.19+esm5
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5126-2
https://ubuntu.com/security/notices/USN-5126-1
CVE-2021-25219
Ubuntu Security Notice USN-5126-2
October 28, 2021
bind9 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
Bind could be made to consume resources if it received specially crafted
network traffic.
Software Description:
- bind9: Internet Domain Name Server
Details:
USN-5126-1 fixed a vulnerability in Bind. This update provides
the corresponding update for Ubuntu 14.04 ESM and Ubuntu 16.04 ESM.
Original advisory details:
Kishore Kumar Kothapalli discovered that Bind incorrectly handled the lame
cache when processing responses. A remote attacker could possibly use this
issue to cause Bind to consume resources, resulting in a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
bind9 1:9.10.3.dfsg.P4-8ubuntu1.19+esm1
Ubuntu 14.04 ESM:
bind9 1:9.9.5.dfsg-3ubuntu0.19+esm5
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5126-2
https://ubuntu.com/security/notices/USN-5126-1
CVE-2021-25219
Fedora Linux 35 Final is GO
The Fedora 35 Final RC1.2 compose [1] is GO and will be shipped live
on Tuesday, 2 November 2021.
For more information please check the Go/No-Go meeting minutes [2] or logs [3].
Thank you to everyone who has worked on this release. Be sure to join
us November 12–13 for the F35 Release Party[4]
[1] https://dl.fedoraproject.org/pub/alt/stage/35_RC-1.2/
[2] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.html
[3] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.log.html
[4] https://hopin.com/events/fedora-linux-35-release-party/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
on Tuesday, 2 November 2021.
For more information please check the Go/No-Go meeting minutes [2] or logs [3].
Thank you to everyone who has worked on this release. Be sure to join
us November 12–13 for the F35 Release Party[4]
[1] https://dl.fedoraproject.org/pub/alt/stage/35_RC-1.2/
[2] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.html
[3] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.log.html
[4] https://hopin.com/events/fedora-linux-35-release-party/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[USN-5126-1] Bind vulnerability
==========================================================================
Ubuntu Security Notice USN-5126-1
October 28, 2021
bind9 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Bind could be made to consume resources if it received specially crafted
network traffic.
Software Description:
- bind9: Internet Domain Name Server
Details:
Kishore Kumar Kothapalli discovered that Bind incorrectly handled the lame
cache when processing responses. A remote attacker could possibly use this
issue to cause Bind to consume resources, resulting in a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
bind9 1:9.16.15-1ubuntu1.1
Ubuntu 21.04:
bind9 1:9.16.8-1ubuntu3.2
Ubuntu 20.04 LTS:
bind9 1:9.16.1-0ubuntu2.9
Ubuntu 18.04 LTS:
bind9 1:9.11.3+dfsg-1ubuntu1.16
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5126-1
CVE-2021-25219
Package Information:
https://launchpad.net/ubuntu/+source/bind9/1:9.16.15-1ubuntu1.1
https://launchpad.net/ubuntu/+source/bind9/1:9.16.8-1ubuntu3.2
https://launchpad.net/ubuntu/+source/bind9/1:9.16.1-0ubuntu2.9
https://launchpad.net/ubuntu/+source/bind9/1:9.11.3+dfsg-1ubuntu1.16
Ubuntu Security Notice USN-5126-1
October 28, 2021
bind9 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Bind could be made to consume resources if it received specially crafted
network traffic.
Software Description:
- bind9: Internet Domain Name Server
Details:
Kishore Kumar Kothapalli discovered that Bind incorrectly handled the lame
cache when processing responses. A remote attacker could possibly use this
issue to cause Bind to consume resources, resulting in a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
bind9 1:9.16.15-1ubuntu1.1
Ubuntu 21.04:
bind9 1:9.16.8-1ubuntu3.2
Ubuntu 20.04 LTS:
bind9 1:9.16.1-0ubuntu2.9
Ubuntu 18.04 LTS:
bind9 1:9.11.3+dfsg-1ubuntu1.16
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5126-1
CVE-2021-25219
Package Information:
https://launchpad.net/ubuntu/+source/bind9/1:9.16.15-1ubuntu1.1
https://launchpad.net/ubuntu/+source/bind9/1:9.16.8-1ubuntu3.2
https://launchpad.net/ubuntu/+source/bind9/1:9.16.1-0ubuntu2.9
https://launchpad.net/ubuntu/+source/bind9/1:9.11.3+dfsg-1ubuntu1.16
F36 Change: Stratis 3.0.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Stratis_3.0.0
== Summary ==
Stratis 3.0.0 includes many internal improvements, bug fixes, and
user-visible changes.
== Owner ==
* Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
[[User:jbaublitz|John Baublitz]]
* Email: dkeefe@redhat.com, amulhern@redhat.com, jbaublitz@redhat.com
== Detailed Description ==
=== stratisd 3.0.0 ===
stratisd 3.0.0 includes a number of significant internal improvements and a few
bug fixes.
In stratisd 3.0.0 the D-Bus API has undergone a revision and the prior
interfaces are all removed. The `FetchProperties` interfaces that
were supported by all objects have been removed. The values that were
previously obtainable via the `FetchProperties` methods
are now conventional D-Bus properties. The possible values of error codes
returned by the D-Bus methods have been reduced to 0 and 1, with the usual
interpretation.
`stratisd` bug fixes:
* The `--prompt` option was not passed to `stratis-min` in the
`stratis-fstab-setup` script; this prevented the user from entering the
password necessary to unlock an encrypted pool during boot. This is
no longer the case.
* `stratisd` was not immediately updating the devicemapper device stack when
a cache was initialized with the result that the cache was not immediately
put in use. This is no longer the case.
* `stratisd` was not immediately updating the Clevis encryption info associated
with a pool on a command to bind an encrypted pool with Clevis. This problem
has been corrected.
* `stratisd` was sending an incorrect D-Bus signal on a pool name change; this
has been fixed.
* Previously, when stratisd-min, which runs during boot before D-Bus
functionality is available, gave way to stratisd when the D-Bus had
been set up, it was possible for inconsistencies to arise if the
Stratis engine was performing an operation which required invoking a
distinct executable. The executable might be terminated during its
execution, and stratisd-min would take the action appropriate to the
command failure before exiting. Now, systemd is instructed to send a
kill signal only to stratisd-min and not to any of stratisd-min's
child processes when shutting down stratisd-min.
* Previously, if the same device was specified using two different
paths when creating or extending a pool the different paths would be
interpreted as two different devices and an error would be returned
when stratisd attempted to initialize the device a second time. Now,
the different paths are canonicalized eagerly, and converted into a
single canonical representation of the device, stratisd initializes
the device only once, and no error is returned.
* Previously, stratisd did not report all existing object paths in the
result of a D-Bus Introspect() call. This was due to a bug in version
0.9.1 and previous of stratisd's dbus-tree dependency. stratisd now
requires dbus-tree 0.9.2, so all nodes are reported.
Other `stratisd` improvements:
* Previously, stratisd relied entirely on udev information when
deciding whether a storage device was not in use by another
application and could safely be overwritten with Stratis metadata. Now
it performs a supplementary check using libblkid and exits with an
error if libblkid reports that the device is in use.
* Handling of errors returned by internal methods is improved; a chaining
mechanism has been introduced and the error chains can be scrutinized
programatically to identify expected scenarios like rollback failures.
* A set of states indicating that a pool has reduced capability have been
added internally and are published on the D-Bus. A pool's capability is
reduced on an error being returned internally which contains, somewhere in
its chain, the appropriate identifying error variant.
* The code used to roll back failed encryption operations on a list of
pool devices has been refactored and generalized. It is now capable of
returning an error that can be used to identify a restricted pool capability
due to a rollback failure.
* `stratisd` uses sha-256 instead of sha-1 for Clevis-related encryption
operations to conform with Clevis's own usage.
* `stratisd` exits more elegantly and less frequently if it encounters an
error during execution of the distinct tasks that are assigned to the
individual threads that it manages internally.
* In preparation for edition 2021 of the Rust language, `stratisd` source code
has been updated to conform entirely to edition 2018 recommendations.
== Detailed Description ==
=== stratis-cli 3.0.0 ===
Users of the Stratis CLI may observe the following changes:
* It is now possible to set the filesystem logical size when creating a
filesystem.
* It is possible to rebind a pool using a Clevis tang server or with a key
in the kernel keyring.
* Filesystem and pool list output have been extended and improved. The pool
listing includes an `Alerts` column. Currently this column is used to indicate
whether the pool is in a restricted operation mode. A new subcommand,
`stratis pool explain`, which provides a fuller explanation of the codes
displayed in the `Alerts` column has been added. The filesystem listing
now displays a filesystem's logical size.
* With encrypted pools it was previously possible for the display of block
device paths to change format if `stratisd` was restarted after an encrypted
pool had been created. Now the display of the block device paths is consistent
across `stratisd` restarts.
== Feedback ==
== Benefits to Fedora ==
Users of Fedora will now benefit from Stratis 2.3.0 by:
* Having the ability to set the filesystem size at create time
* Changing the passphrase or NBDE server using the rebind option
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
* Users of the CLI will not be impacted
* Developers that consume stratisd's D-Bus API will need to review the
most recent changes make appropriate adjustments
== How To Test ==
* To test setting filesystem size:
* Create a Stratis pool, either encrypted or not.
* Create a Stratis filesystem on the pool, specifying a filesystem size:
> stratis fs create <poolname> new-filesystem --size 256GiB
* Verify that the size was set correctly:
> stratis fs list <poolname>
Verify the size of new-filesystem is 256 GiB by checking the first
item in the size triple in the "Size" column.
* To test rebinding with a key in the kernel keyring:
* Create an encrypted pool, specifying a key in the kernel keyring:
> stratis key set old-key
> stratis pool create <poolname> --key-desc old-key <blockdevs>
* Add an additional key to the kernel keyring, entering the value at
the command-line:
> stratis key set new-key --capture-key
* Rebind the pool using the new key:
> stratis pool rebind keyring <poolname> new-key
* Verify that the pool has been rebound to the new keyring by
rebooting your machine:
* Reboot, make sure that stratisd is running.
* Remove the old key from the kernel keyring, using stratis:
> stratis key unset old-key
* Verify that the old key is gone, by listing all the keys:
> stratis key list
* Unlock all the pools using the keyring:
> stratis pool unlock keyring
* Verify that the rebound pool is unlocked by listing the pools
and verifying that it appears in the pool listing:
> stratis pool list
== User Experience ==
Other than the changes mentioned above the user experience will be the same.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
* Developers blog draft is here:
** https://github.com/stratis-storage/stratis-docs/pull/246
* Changelog for stratisd
** https://github.com/stratis-storage/stratisd/pull/2821/files
* Changelog for stratis-cli
** https://github.com/stratis-storage/stratis-cli/pull/775/files
== Release Notes ==
Includes recent version of Stratis
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
== Summary ==
Stratis 3.0.0 includes many internal improvements, bug fixes, and
user-visible changes.
== Owner ==
* Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
[[User:jbaublitz|John Baublitz]]
* Email: dkeefe@redhat.com, amulhern@redhat.com, jbaublitz@redhat.com
== Detailed Description ==
=== stratisd 3.0.0 ===
stratisd 3.0.0 includes a number of significant internal improvements and a few
bug fixes.
In stratisd 3.0.0 the D-Bus API has undergone a revision and the prior
interfaces are all removed. The `FetchProperties` interfaces that
were supported by all objects have been removed. The values that were
previously obtainable via the `FetchProperties` methods
are now conventional D-Bus properties. The possible values of error codes
returned by the D-Bus methods have been reduced to 0 and 1, with the usual
interpretation.
`stratisd` bug fixes:
* The `--prompt` option was not passed to `stratis-min` in the
`stratis-fstab-setup` script; this prevented the user from entering the
password necessary to unlock an encrypted pool during boot. This is
no longer the case.
* `stratisd` was not immediately updating the devicemapper device stack when
a cache was initialized with the result that the cache was not immediately
put in use. This is no longer the case.
* `stratisd` was not immediately updating the Clevis encryption info associated
with a pool on a command to bind an encrypted pool with Clevis. This problem
has been corrected.
* `stratisd` was sending an incorrect D-Bus signal on a pool name change; this
has been fixed.
* Previously, when stratisd-min, which runs during boot before D-Bus
functionality is available, gave way to stratisd when the D-Bus had
been set up, it was possible for inconsistencies to arise if the
Stratis engine was performing an operation which required invoking a
distinct executable. The executable might be terminated during its
execution, and stratisd-min would take the action appropriate to the
command failure before exiting. Now, systemd is instructed to send a
kill signal only to stratisd-min and not to any of stratisd-min's
child processes when shutting down stratisd-min.
* Previously, if the same device was specified using two different
paths when creating or extending a pool the different paths would be
interpreted as two different devices and an error would be returned
when stratisd attempted to initialize the device a second time. Now,
the different paths are canonicalized eagerly, and converted into a
single canonical representation of the device, stratisd initializes
the device only once, and no error is returned.
* Previously, stratisd did not report all existing object paths in the
result of a D-Bus Introspect() call. This was due to a bug in version
0.9.1 and previous of stratisd's dbus-tree dependency. stratisd now
requires dbus-tree 0.9.2, so all nodes are reported.
Other `stratisd` improvements:
* Previously, stratisd relied entirely on udev information when
deciding whether a storage device was not in use by another
application and could safely be overwritten with Stratis metadata. Now
it performs a supplementary check using libblkid and exits with an
error if libblkid reports that the device is in use.
* Handling of errors returned by internal methods is improved; a chaining
mechanism has been introduced and the error chains can be scrutinized
programatically to identify expected scenarios like rollback failures.
* A set of states indicating that a pool has reduced capability have been
added internally and are published on the D-Bus. A pool's capability is
reduced on an error being returned internally which contains, somewhere in
its chain, the appropriate identifying error variant.
* The code used to roll back failed encryption operations on a list of
pool devices has been refactored and generalized. It is now capable of
returning an error that can be used to identify a restricted pool capability
due to a rollback failure.
* `stratisd` uses sha-256 instead of sha-1 for Clevis-related encryption
operations to conform with Clevis's own usage.
* `stratisd` exits more elegantly and less frequently if it encounters an
error during execution of the distinct tasks that are assigned to the
individual threads that it manages internally.
* In preparation for edition 2021 of the Rust language, `stratisd` source code
has been updated to conform entirely to edition 2018 recommendations.
== Detailed Description ==
=== stratis-cli 3.0.0 ===
Users of the Stratis CLI may observe the following changes:
* It is now possible to set the filesystem logical size when creating a
filesystem.
* It is possible to rebind a pool using a Clevis tang server or with a key
in the kernel keyring.
* Filesystem and pool list output have been extended and improved. The pool
listing includes an `Alerts` column. Currently this column is used to indicate
whether the pool is in a restricted operation mode. A new subcommand,
`stratis pool explain`, which provides a fuller explanation of the codes
displayed in the `Alerts` column has been added. The filesystem listing
now displays a filesystem's logical size.
* With encrypted pools it was previously possible for the display of block
device paths to change format if `stratisd` was restarted after an encrypted
pool had been created. Now the display of the block device paths is consistent
across `stratisd` restarts.
== Feedback ==
== Benefits to Fedora ==
Users of Fedora will now benefit from Stratis 2.3.0 by:
* Having the ability to set the filesystem size at create time
* Changing the passphrase or NBDE server using the rebind option
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
* Users of the CLI will not be impacted
* Developers that consume stratisd's D-Bus API will need to review the
most recent changes make appropriate adjustments
== How To Test ==
* To test setting filesystem size:
* Create a Stratis pool, either encrypted or not.
* Create a Stratis filesystem on the pool, specifying a filesystem size:
> stratis fs create <poolname> new-filesystem --size 256GiB
* Verify that the size was set correctly:
> stratis fs list <poolname>
Verify the size of new-filesystem is 256 GiB by checking the first
item in the size triple in the "Size" column.
* To test rebinding with a key in the kernel keyring:
* Create an encrypted pool, specifying a key in the kernel keyring:
> stratis key set old-key
> stratis pool create <poolname> --key-desc old-key <blockdevs>
* Add an additional key to the kernel keyring, entering the value at
the command-line:
> stratis key set new-key --capture-key
* Rebind the pool using the new key:
> stratis pool rebind keyring <poolname> new-key
* Verify that the pool has been rebound to the new keyring by
rebooting your machine:
* Reboot, make sure that stratisd is running.
* Remove the old key from the kernel keyring, using stratis:
> stratis key unset old-key
* Verify that the old key is gone, by listing all the keys:
> stratis key list
* Unlock all the pools using the keyring:
> stratis pool unlock keyring
* Verify that the rebound pool is unlocked by listing the pools
and verifying that it appears in the pool listing:
> stratis pool list
== User Experience ==
Other than the changes mentioned above the user experience will be the same.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
* Developers blog draft is here:
** https://github.com/stratis-storage/stratis-docs/pull/246
* Changelog for stratisd
** https://github.com/stratis-storage/stratisd/pull/2821/files
* Changelog for stratis-cli
** https://github.com/stratis-storage/stratis-cli/pull/775/files
== Release Notes ==
Includes recent version of Stratis
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Wednesday, October 27, 2021
[USN-5125-1] PHP vulnerability
==========================================================================
Ubuntu Security Notice USN-5125-1
October 27, 2021
php5, php7.0, php7.2, php7.4, php8.0 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
PHP-PFM in PHP could be made to run program as an administrator
if it received specially crafted input.
Software Description:
- php8.0: HTML-embedded scripting language interpreter
- php7.4: HTML-embedded scripting language interpreter
- php7.2: HTML-embedded scripting language interpreter
- php7.0: HTML-embedded scripting language interpreter
- php5: HTML-embedded scripting language interpreter
Details:
It was discovered that PHP-FPM in PHP incorrectly handled certain inputs.
An attacker could possibly use this issue to cause a crash or execute
arbitrary code.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
php8.0-fpm 8.0.8-1ubuntu0.1
Ubuntu 21.04:
php7.4-fpm 7.4.16-1ubuntu2.2
Ubuntu 20.04 LTS:
php7.4-fpm 7.4.3-4ubuntu2.7
Ubuntu 18.04 LTS:
php7.2-fpm 7.2.24-0ubuntu0.18.04.10
Ubuntu 16.04 ESM:
php7.0-fpm 7.0.33-0ubuntu0.16.04.16+esm2
Ubuntu 14.04 ESM:
php5-fpm 5.5.9+dfsg-1ubuntu4.29+esm15
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5125-1
CVE-2021-21703
Package Information:
https://launchpad.net/ubuntu/+source/php8.0/8.0.8-1ubuntu0.1
https://launchpad.net/ubuntu/+source/php7.4/7.4.16-1ubuntu2.2
https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4ubuntu2.7
https://launchpad.net/ubuntu/+source/php7.2/7.2.24-0ubuntu0.18.04.10
Ubuntu Security Notice USN-5125-1
October 27, 2021
php5, php7.0, php7.2, php7.4, php8.0 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
PHP-PFM in PHP could be made to run program as an administrator
if it received specially crafted input.
Software Description:
- php8.0: HTML-embedded scripting language interpreter
- php7.4: HTML-embedded scripting language interpreter
- php7.2: HTML-embedded scripting language interpreter
- php7.0: HTML-embedded scripting language interpreter
- php5: HTML-embedded scripting language interpreter
Details:
It was discovered that PHP-FPM in PHP incorrectly handled certain inputs.
An attacker could possibly use this issue to cause a crash or execute
arbitrary code.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
php8.0-fpm 8.0.8-1ubuntu0.1
Ubuntu 21.04:
php7.4-fpm 7.4.16-1ubuntu2.2
Ubuntu 20.04 LTS:
php7.4-fpm 7.4.3-4ubuntu2.7
Ubuntu 18.04 LTS:
php7.2-fpm 7.2.24-0ubuntu0.18.04.10
Ubuntu 16.04 ESM:
php7.0-fpm 7.0.33-0ubuntu0.16.04.16+esm2
Ubuntu 14.04 ESM:
php5-fpm 5.5.9+dfsg-1ubuntu4.29+esm15
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5125-1
CVE-2021-21703
Package Information:
https://launchpad.net/ubuntu/+source/php8.0/8.0.8-1ubuntu0.1
https://launchpad.net/ubuntu/+source/php7.4/7.4.16-1ubuntu2.2
https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4ubuntu2.7
https://launchpad.net/ubuntu/+source/php7.2/7.2.24-0ubuntu0.18.04.10
REMINDER: Fedora Linux 35 Go/No-Go meeting tomorrow
As foretold in the ancient prophecies, we will hold the F35 Go/No-Go
meeting[1] on Thursday 28 October at 1700 UTC in #fedora-meeting.
At this time, we will determine the status of the F35 Final for the 2
November target date #2 milestone[2]. For more information about the
Go/No-Go meeting, see the wiki[3].
There are accepted blockers not fixed in RC2, so the meeting will
include decisions on waiving those outstanding bugs. Please see the
Blockerbugs page[4] for status and discussion.
[1] https://calendar.fedoraproject.org/meeting/10102/
[2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
[4] https://qa.fedoraproject.org/blockerbugs/milestone/35/final/buglist
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
meeting[1] on Thursday 28 October at 1700 UTC in #fedora-meeting.
At this time, we will determine the status of the F35 Final for the 2
November target date #2 milestone[2]. For more information about the
Go/No-Go meeting, see the wiki[3].
There are accepted blockers not fixed in RC2, so the meeting will
include decisions on waiving those outstanding bugs. Please see the
Blockerbugs page[4] for status and discussion.
[1] https://calendar.fedoraproject.org/meeting/10102/
[2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
[4] https://qa.fedoraproject.org/blockerbugs/milestone/35/final/buglist
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Tuesday, October 26, 2021
F36 Change: Rubygem Cucumber 7.1.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/rubygem-cucumber_7.1.0
== Summary ==
Rubygem-cucumber 7.1.0 is the latest version of the popular
integration BDD testing framework for Ruby.
== Owner ==
* Name: [[User:Jackorp1 | Jaroslav Prokop]], [[User:pvalena| Pavel Valena]]
* Email: jprokop@redhat.com, pvalena@redhat.com
== Detailed Description ==
Fedora is currently lagging behind on the Ruby Cucumber library which
underwent internal restructuration. Therefore the rubygem-cucumber
library stack will be updated to version 7.1.0, ensuring that Fedora
has the newest Ruby Cucumber available.
== Benefit to Fedora ==
This update will bring Rule and Rule tags, new hooks, and better
plugin support into Fedora as well as bug fixes and other
improvements.
== Scope ==
* Proposal owners:
* rubygem-cucumber and its dependencies will be updated.
* Build rubygem-cucumber update and dependencies in side tag.
* Rebuild packages that depend on rubygem-cucumber and fix any that
begin to fail as a result.
* Other developers: N/A
* Release engineering:N/A
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Upon upgrade it should still work for all users.
The only exception is the HTML output formatter which is currently not
planned on being packaged due to minified JS present in the
distributed gem.
== How To Test ==
Tests that are running under rubygem-cucumber 3 are expected to run
under rubygem-cucumber 7 as well.
1. Prepare:
To test using DNF, enable the copr repository containing the newest
cucumber build and install it:
$ sudo dnf copr enable pvalena/rubygems
$ sudo dnf install rubygem-cucumber
2. Running the tests
Find a project that uses rubygem-cucumber for testing, and in that project run:
$ cucumber
3. Checking the results
All tests should proceed as they do upstream without crashing.
== User Experience ==
* New rubygem-cucumber version 7.1.0 available
== Dependencies ==
* There are several packages, which depend on the rubygem-cucumber
test suite as their build requirement.
* Packages that need to be updated: rubygem-aruba, rubygem-cucumber-rails
* Following packages don't support rubygem-cucumber 7.1.0 right now
and would be broken by the update: rubygem-aruba
== Contingency Plan ==
* Contingency Plan
* Contingency mechanism: None needed. rubygem-cucumber with its
dependencies will be built in a side-tag and merged after successful
updates.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://cucumber.io/docs/cucumber/
== Release Notes ==
See the upstream changelog for a more detailed overview of what
changed: https://github.com/cucumber/cucumber-ruby/blob/v7.1.0/CHANGELOG.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
== Summary ==
Rubygem-cucumber 7.1.0 is the latest version of the popular
integration BDD testing framework for Ruby.
== Owner ==
* Name: [[User:Jackorp1 | Jaroslav Prokop]], [[User:pvalena| Pavel Valena]]
* Email: jprokop@redhat.com, pvalena@redhat.com
== Detailed Description ==
Fedora is currently lagging behind on the Ruby Cucumber library which
underwent internal restructuration. Therefore the rubygem-cucumber
library stack will be updated to version 7.1.0, ensuring that Fedora
has the newest Ruby Cucumber available.
== Benefit to Fedora ==
This update will bring Rule and Rule tags, new hooks, and better
plugin support into Fedora as well as bug fixes and other
improvements.
== Scope ==
* Proposal owners:
* rubygem-cucumber and its dependencies will be updated.
* Build rubygem-cucumber update and dependencies in side tag.
* Rebuild packages that depend on rubygem-cucumber and fix any that
begin to fail as a result.
* Other developers: N/A
* Release engineering:N/A
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Upon upgrade it should still work for all users.
The only exception is the HTML output formatter which is currently not
planned on being packaged due to minified JS present in the
distributed gem.
== How To Test ==
Tests that are running under rubygem-cucumber 3 are expected to run
under rubygem-cucumber 7 as well.
1. Prepare:
To test using DNF, enable the copr repository containing the newest
cucumber build and install it:
$ sudo dnf copr enable pvalena/rubygems
$ sudo dnf install rubygem-cucumber
2. Running the tests
Find a project that uses rubygem-cucumber for testing, and in that project run:
$ cucumber
3. Checking the results
All tests should proceed as they do upstream without crashing.
== User Experience ==
* New rubygem-cucumber version 7.1.0 available
== Dependencies ==
* There are several packages, which depend on the rubygem-cucumber
test suite as their build requirement.
* Packages that need to be updated: rubygem-aruba, rubygem-cucumber-rails
* Following packages don't support rubygem-cucumber 7.1.0 right now
and would be broken by the update: rubygem-aruba
== Contingency Plan ==
* Contingency Plan
* Contingency mechanism: None needed. rubygem-cucumber with its
dependencies will be built in a side-tag and merged after successful
updates.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://cucumber.io/docs/cucumber/
== Release Notes ==
See the upstream changelog for a more detailed overview of what
changed: https://github.com/cucumber/cucumber-ruby/blob/v7.1.0/CHANGELOG.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change proposal: Replace the fbdev drivers with simpledrm and the DRM fbdev emulation layer (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
== Summary ==
This change replaces the legacy Linux frame buffer device (fbdev)
drivers that are still used in Fedora, with the latest simpledrm
driver and the DRM fbdev emulation layer.
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm@redhat.com
* Name: [[User:Pbrobinson|Peter Robinson]]
* Email: pbrobinson@fedoraproject.org
== Detailed Description ==
The fbdev subsystem has been deprecated for over a decade and no new
platform should use it but instead write DRM drivers for their video
output.
Yet, the Fedora kernel still enables support for some of the fbdev
drivers. Mainly for fbdev drivers that make use of the video frame
buffer that was initialized by the firmware. These are generic drivers
that could be used in different platforms since only grab an existing
frame buffer without trying to do any hardware initialization and
setup.
Examples of these drivers are simplefb (used in aarch64 machines with
Device Trees) and efifb (used in EFI machines) and vesafb (used in
machines with a VESA VGA graphics). But since the Linux v5.14, a new
simpledrm driver was introduced that is able to do the same that these
fbdev drivers. And just like any other DRM driver, it can rely on the
DRM subsystem fbdev emulation layer to provide a fbdev interface.
For this reason, there is no need for the fbdev drivers anymore and
instead the simpledrm driver could just be used.
== Benefit to Fedora ==
This change will allow to reduce the maintenance burden in the Linux
kernel since users won't use legacy fbdev drivers anymore but instead
a driver in the well maintained DRM subsystem. This will also move
Fedora one step close to being able to completely disable the fbdev
subsystem.
The latter is still not possible due the framebuffer console (fbcon)
needing to run on top of a frame buffer device. But at least this
change will remove the dependency with fbdev drivers and make fbcon
just use the DRM fbdev emulation layer in the meantime.
== Scope ==
* Proposal owners:
** Modify the following Linux kernel config options:
*** Disable fbdev drivers (e.g: `CONFIG_FB_EFI`, `CONFIG_FB_SIMPLE`) options.
*** Make `CONFIG_DRM` option built-in so the display can be enabled
without an initrd.
*** Enable the `CONFIG_SYSFB_SIMPLEFB` that registers a
simple-framebuffer platform device that is used to match the simpledrm
driver.
* Other developers:
** It should not affect other packages but may be that plymouth or
display managers could need some work.
** Test and watch for regressions.
* Release engineering: []
* Policies and guidelines: No changes needed.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
There should not be any impact on upgrade, this is a internal change
in the kernel and should be transparent for users.
== How To Test ==
* Install Fedora 36 and check that there is output in the video
console when removing the `rhgb quiet` parameters.
== User Experience ==
No visible changes are expected, as mentioned it is fully backward
compatible and transparent for users.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the Linux kernel configuration changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
* N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
== Summary ==
This change replaces the legacy Linux frame buffer device (fbdev)
drivers that are still used in Fedora, with the latest simpledrm
driver and the DRM fbdev emulation layer.
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm@redhat.com
* Name: [[User:Pbrobinson|Peter Robinson]]
* Email: pbrobinson@fedoraproject.org
== Detailed Description ==
The fbdev subsystem has been deprecated for over a decade and no new
platform should use it but instead write DRM drivers for their video
output.
Yet, the Fedora kernel still enables support for some of the fbdev
drivers. Mainly for fbdev drivers that make use of the video frame
buffer that was initialized by the firmware. These are generic drivers
that could be used in different platforms since only grab an existing
frame buffer without trying to do any hardware initialization and
setup.
Examples of these drivers are simplefb (used in aarch64 machines with
Device Trees) and efifb (used in EFI machines) and vesafb (used in
machines with a VESA VGA graphics). But since the Linux v5.14, a new
simpledrm driver was introduced that is able to do the same that these
fbdev drivers. And just like any other DRM driver, it can rely on the
DRM subsystem fbdev emulation layer to provide a fbdev interface.
For this reason, there is no need for the fbdev drivers anymore and
instead the simpledrm driver could just be used.
== Benefit to Fedora ==
This change will allow to reduce the maintenance burden in the Linux
kernel since users won't use legacy fbdev drivers anymore but instead
a driver in the well maintained DRM subsystem. This will also move
Fedora one step close to being able to completely disable the fbdev
subsystem.
The latter is still not possible due the framebuffer console (fbcon)
needing to run on top of a frame buffer device. But at least this
change will remove the dependency with fbdev drivers and make fbcon
just use the DRM fbdev emulation layer in the meantime.
== Scope ==
* Proposal owners:
** Modify the following Linux kernel config options:
*** Disable fbdev drivers (e.g: `CONFIG_FB_EFI`, `CONFIG_FB_SIMPLE`) options.
*** Make `CONFIG_DRM` option built-in so the display can be enabled
without an initrd.
*** Enable the `CONFIG_SYSFB_SIMPLEFB` that registers a
simple-framebuffer platform device that is used to match the simpledrm
driver.
* Other developers:
** It should not affect other packages but may be that plymouth or
display managers could need some work.
** Test and watch for regressions.
* Release engineering: []
* Policies and guidelines: No changes needed.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
There should not be any impact on upgrade, this is a internal change
in the kernel and should be transparent for users.
== How To Test ==
* Install Fedora 36 and check that there is output in the video
console when removing the `rhgb quiet` parameters.
== User Experience ==
No visible changes are expected, as mentioned it is fully backward
compatible and transparent for users.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the Linux kernel configuration changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
* N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[USN-5009-2] libslirp vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5009-2
October 26, 2021
libslirp vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
Summary:
Several security issues were fixed in libslirp.
Software Description:
- libslirp: General purpose TCP-IP emulator library
Details:
USN-5009-1 fixed vulnerabilities in libslirp. This update provides the
corresponding updates for Ubuntu 21.10.
Original advisory details:
Qiuhao Li discovered that libslirp incorrectly handled certain header data
lengths. An attacker inside a guest could possibly use this issue to leak
sensitive information from the host. This issue only affected Ubuntu 20.04
LTS and Ubuntu 20.10. (CVE-2020-29129, CVE-2020-29130)
It was discovered that libslirp incorrectly handled certain udp packets. An
attacker inside a guest could possibly use this issue to leak sensitive
information from the host. (CVE-2021-3592, CVE-2021-3593, CVE-2021-3594,
CVE-2021-3595)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
libslirp0 4.4.0-1ubuntu0.21.10.1
After a standard system update you need to reboot your computer to make
all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5009-2
https://ubuntu.com/security/notices/USN-5009-1
CVE-2021-3592, CVE-2021-3593, CVE-2021-3594, CVE-2021-3595
Package Information:
https://launchpad.net/ubuntu/+source/libslirp/4.4.0-1ubuntu0.21.10.1
Ubuntu Security Notice USN-5009-2
October 26, 2021
libslirp vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
Summary:
Several security issues were fixed in libslirp.
Software Description:
- libslirp: General purpose TCP-IP emulator library
Details:
USN-5009-1 fixed vulnerabilities in libslirp. This update provides the
corresponding updates for Ubuntu 21.10.
Original advisory details:
Qiuhao Li discovered that libslirp incorrectly handled certain header data
lengths. An attacker inside a guest could possibly use this issue to leak
sensitive information from the host. This issue only affected Ubuntu 20.04
LTS and Ubuntu 20.10. (CVE-2020-29129, CVE-2020-29130)
It was discovered that libslirp incorrectly handled certain udp packets. An
attacker inside a guest could possibly use this issue to leak sensitive
information from the host. (CVE-2021-3592, CVE-2021-3593, CVE-2021-3594,
CVE-2021-3595)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
libslirp0 4.4.0-1ubuntu0.21.10.1
After a standard system update you need to reboot your computer to make
all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5009-2
https://ubuntu.com/security/notices/USN-5009-1
CVE-2021-3592, CVE-2021-3593, CVE-2021-3594, CVE-2021-3595
Package Information:
https://launchpad.net/ubuntu/+source/libslirp/4.4.0-1ubuntu0.21.10.1
[USN-5122-2] Apport vulnerability
==========================================================================
Ubuntu Security Notice USN-5122-2
October 26, 2021
apport vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
Apport could be made to create files as the administrator.
Software Description:
- apport: automatically generate crash reports for debugging
Details:
USN-5122-1 fixed a vulnerability in Apport. This update provides
the corresponding update for Ubuntu 14.04 ESM and Ubuntu 16.04 ESM.
Original advisory details:
It was discovered that Apport could be tricked into writing core files as
root into arbitrary directories in certain scenarios. A local attacker
could possibly use this issue to escalate privileges. On Ubuntu 16.04 ESM
This update will cause Apport to generate all core files in the /var/lib/apport/coredump
directory. On Ubuntu 14.04 ESM, core file generation has been disabled by default.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
apport 2.20.1-0ubuntu2.30+esm3
python3-apport 2.20.1-0ubuntu2.30+esm3
Ubuntu 14.04 ESM:
apport 2.14.1-0ubuntu3.29+esm9
python3-apport 2.14.1-0ubuntu3.29+esm9
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5122-2
https://ubuntu.com/security/notices/USN-5122-1
https://launchpad.net/bugs/1948657
Ubuntu Security Notice USN-5122-2
October 26, 2021
apport vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM
Summary:
Apport could be made to create files as the administrator.
Software Description:
- apport: automatically generate crash reports for debugging
Details:
USN-5122-1 fixed a vulnerability in Apport. This update provides
the corresponding update for Ubuntu 14.04 ESM and Ubuntu 16.04 ESM.
Original advisory details:
It was discovered that Apport could be tricked into writing core files as
root into arbitrary directories in certain scenarios. A local attacker
could possibly use this issue to escalate privileges. On Ubuntu 16.04 ESM
This update will cause Apport to generate all core files in the /var/lib/apport/coredump
directory. On Ubuntu 14.04 ESM, core file generation has been disabled by default.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
apport 2.20.1-0ubuntu2.30+esm3
python3-apport 2.20.1-0ubuntu2.30+esm3
Ubuntu 14.04 ESM:
apport 2.14.1-0ubuntu3.29+esm9
python3-apport 2.14.1-0ubuntu3.29+esm9
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5122-2
https://ubuntu.com/security/notices/USN-5122-1
https://launchpad.net/bugs/1948657
Monday, October 25, 2021
F36 Change: Package information on ELF objects (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrqben@0pointer.net
== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.
The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms. A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.
A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.
A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.
We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.
For the case where we mix binaries from different distros (the third
motivating use case above), this approach is the most useful when this
system is used by all distros and even non-distro builds. The more
widely it is used, the more useful it becomes. The specification was
developed in collaboration with Debian developers, and we hope that
Fedora and Debian will lead the way for this to become as widely used
as build-ids. But even if the information is only available from some
distros, it is still useful, except that fallback mechanisms need to
be implemented.
=== Existing system: `.note.gnu.build-id` ===
We already have build-ids: every ELF object has a `.note.gnu.build-id`
note, and given a core file, we can read the build-id and look it up
in the rpm database (`dnf repoquery --whatprovides debuginfo(build-id)
= …`) to map it to a package name.
Build-ids are unique and compact and very generic and work as expected
in general. But they have some downsides:
* build-ids are not very informative for users. Before the build-id is
converted back to the appropriate package, it's completely opaque.
* build-ids require a working rpm database or an internet connection
to map to the package name.
Three important cases:
* minimal containers: the rpm database is not installed in the
containers. The information about build-ids needs to be stored
externally, so package name information is not available immediately,
but only after offline processing. The new note doesn't depend on the
rpm db in any way.
* handling of a core from a container, where the container and host
have different distros
* self-built and external packages: unless a lot of care is taken to
keep access to the debuginfo packages, this information may be lost.
The new note is available even if the repository metadata gets lost.
Users can easily provide equivalent information in a format that makes
sense in their own environment. It should work even when rpms and debs
and other formats are mixed, e.g. during container image creation.
=== New system: `.note.package` ===
The new note is created and propagated similarly to
`.note.gnu.build-id`. The difference is that we inject the information
about package ''nevra'' from the build system.
The implementation is very simple: `%{build_ldflags}` are extended
with a command to insert a custom note as a separate section in an ELF
object. See [https://github.com/systemd/package-notes/blob/main/hello.spec
hello.spec] for an example. This is done in the default macros, so all
packages that use the prescribed link flags will be affected.
The note is a compact json string. This allows the format to be
trivially extensible (new fields can be added at will), easy to
process (json is extremely popular and parsers are widely available).
Using a single field rather than a set of separated notes is more
space-efficient. With multiple fields the padding and alignment
requirements cause unnecessary overhead.
The system was designed with cross-distro collaboration and is
flexible enough to identify binaries from different packaging formats
and build systems (rpms, debs, custom binaries).
See https://systemd.io/COREDUMP_PACKAGE_METADATA/ for detailed
description of the format.
One of the advantages of using an ELF note, as opposed to say a series
of extended attributes on the binary itself, is that the ELF note gets
automatically captured and copied into a core file by the kernel.
Extended attributes would have to be copied manually, which might not
even be possible because the binary on disk may have been removed by
the time the crash is analyzed.
The overhead is about 200 bytes for each ELF object.
We have about overall 33200 files in `/usr/s?bin/` and about 36600
`.so` files (F35, single architecture,
results from `dnf repoquery -l 2>/dev/null | rg '^/usr/s?bin/' | sort
-u | wc -l`,
`dnf repoquery -l 2>/dev/null | rg '^/usr/lib64/.*\.so$' |sort -u|wc -l`).
If we do this for the whole distro, we get 69800 × 200 = 13 MB.
For a typical installation, we can expect about 300–400 kB.
Thus the overhead of additionally used space is neglible (also see the
Feedback section for more discussion).
Precise measurements TBD once this is turned on and we have real
measurements for a larger number of builds.
=== Examples ===
<pre>
$ objdump -s -j .note.package build/libhello.so
build/libhello.so: file format elf64-x86-64
Contents of section .note.package:
02ec 04000000 63000000 7e1afeca 46444f00 ....c...~...FDO.
02fc 7b227479 7065223a 2272706d 222c226e {"type":"rpm","n
030c 616d6522 3a226865 6c6c6f22 2c227665 ame":"hello","ve
031c 7273696f 6e223a22 302d312e 66633335 rsion":"0-1.fc35
032c 2e783836 5f363422 2c226f73 43706522 .x86_64","osCpe"
033c 3a226370 653a2f6f 3a666564 6f726170 :"cpe:/o:fedorap
034c 726f6a65 63743a66 65646f72 613a3333 roject:fedora:33
035c 227d0000 "}..
</pre>
<pre>
$ readelf --notes build/hello | grep "description data" | sed -e
"s/\s*description data: //g" -e "s/ //g" | xxd -p -r | jq
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x10de
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x10af
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x119f
{
"type": "rpm",
"name": "hello",
"version": "0-1.fc35.x86_64",
"osCpe": "cpe:/o:fedoraproject:fedora:33"
}
</pre>
<pre>
$ coredumpctl info
PID: 44522 (fsverity)
...
Package: fsverity-utils/1.3-1
build-id: ac89bf7175b04d7eec7f6544a923f45be111f0be
Message: Process 44522 (fsverity) of user 1000 dumped core.
Found module
/home/bluca/git/fsverity-utils/libfsverity.so.0 with build-id:
fa40fdfb79aea84167c98ca8a89add9ac4f51069
Metadata for module
/home/bluca/git/fsverity-utils/libfsverity.so.0 owned by FDO found: {
"packageType" : "deb",
"package" : "fsverity-utils",
"packageVersion" : "1.3-1"
}
Found module linux-vdso.so.1 with build-id:
aba08e06103f725e26f1d7c178fb6b76a564a35d
Found module libpthread.so.0 with build-id:
e91114987a0147bd050addbd591eb8994b29f4b3
Found module libdl.so.2 with build-id:
d3583c742dd47aaa860c5ae0c0c5bdbcd2d54f61
Found module ld-linux-x86-64.so.2 with build-id:
f25dfd7b95be4ba386fd71080accae8c0732b711
Found module libcrypto.so.1.1 with build-id:
749142d5ee728a76e7cdc61fd79d2311a77405a2
Found module libc.so.6 with build-id:
18b9a9a8c523e5cfe5b5d946d605d09242f09798
Found module fsverity with build-id:
ac89bf7175b04d7eec7f6544a923f45be111f0be
Metadata for module fsverity owned by FDO found: {
"packageType" : "deb",
"package" : "fsverity-utils",
"packageVersion" : "1.3-1"
}
Stack trace of thread 44522:
#0 0x00007fe7c8af26f4 __GI___nanosleep (libc.so.6 + 0xc66f4)
#1 0x00007fe7c8af262a __sleep (libc.so.6 + 0xc662a)
#2 0x00005608481407dd main (fsverity + 0x27dd)
#3 0x00007fe7c8a5009b __libc_start_main (libc.so.6 + 0x2409b)
#4 0x000056084814094a _start (fsverity + 0x294a)
</pre>
== Feedback ==
See [https://github.com/systemd/systemd/issues/18433 systemd issue
#18433] for upstream discussion and implementation proposals.
=== Concerns about additional changes to files ===
<pre>
17:32:30 <Eighth_Doctor> I think zbyszek underestimates how much of a
problem it is to stamp every ELF binary with ''nevra'' data
17:32:44 <mhroncok> zbyszek: so, assuming python has ~100 ELF .so
files and I change one text file
17:33:22 <mhroncok> (ignore for the time being that the .so files
often changed because of toolchain updates and assume they are stable)
</pre>
I tested this with python3.10. So far there are 13 builds of that
package in F35:
`python3.10-3.10.0-1.fc35`,
`python3.10-3.10.0~a6-1.fc35`,
`python3.10-3.10.0~a6-2.fc35`,
`python3.10-3.10.0~a7-1.fc35`,
`python3.10-3.10.0~b1-1.fc35`,
`python3.10-3.10.0~b2-2.fc35`,
`python3.10-3.10.0~b2-3.fc35`,
`python3.10-3.10.0~b3-1.fc35`,
`python3.10-3.10.0~b4-1.fc35`,
`python3.10-3.10.0~b4-2.fc35`,
`python3.10-3.10.0~b4-3.fc35`,
`python3.10-3.10.0~rc1-1.fc35`,
`python3.10-3.10.0~rc2-1.fc35`.
I extracted the builds (for `.x86_64`) and made a list of all `.so`
files (1368 files), and calculated sha256 hashes for them. No two
files repeat, there are 1368 distinct hashes. So the files are
'''already''' different between builds and the additional proposed
metadata does will not make a significant difference.
Note that this range of Python versions encompasses periods when the
package is under development and undergoes significant changes (alpha
versions), and when it's only undergoing small changes (rc versions).
The fact that we get different files in each build is not surprising,
because files embed build-ids which differ between builds. But even if
we ignore those, binaries generally differ between builds. Even sizes
tend to vary between builds: there are 636 distinct `.so` file sizes,
i.e. on average any given size only repeats twice (presumably most
often for the same file). Running `diffoscope` on `.so` files from
different builds shows minor changes in the assembly which I did not
analyze futher.
If people have specific questions, for example about overhead in some
scenario, I'd be happy to answer them. Until now, the issues that were
raised were very vague, so it's impossible to answer them.
=== Why not just use the rpm database? ===
<pre>
17:34:33 <dcantrell> The main reason for this appears to be that we
need the RPM db locally to resolve build-ids to package names. But
since containers wipe /var/lib/rpm, we can't do that. So the solution
is to put the ''nevra'' in ELF metadata?
17:34:39 <dcantrell> That feels like the wrong approach.
</pre>
First, there are legitimate reasons to strip packaging metadata from
images. For example, for an initrd image from rpms, I get 117 MB of
files (without compression), and out of this `/var/lib/rpm` is 5.9 MB,
and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not
much'', but still too much to keep in the image unless necessary.
Similar ratios will happen for containers of similar size. Reducing
image size by one tenth is important. There is no `rpm` or `dnf` in
the image, to the package database is not even usable without external
tools.
As discussed on IRC
(https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-05-11-17.01.log.html),
the containers ''we'' build don't wipe this metadata, but custom
Dockerfiles do that.
Second, as described in Description section above, not everybody and
everything uses rpm. The Fedora motto is "we make an operating system
and we make it easy for you to do useful stuff with it" (and yes, this
is an actual quote from the official docs), and this stuff involves
reusing our binaries in containers and custom installations and
whatnot, not just straightforward installations with `dnf`. And in the
other direction, people will build their own binaries that are not
packaged as rpms. But it is still important to be able to figure out
the exact version of a binary, especially after it crashes.
=== Why do this in Fedora? ===
<pre>
17:36:49 <mhroncok> I don't understand how non-rpm distros and custom
built binaries are affected by our rpm-build environment :/
</pre>
The idea is that we inject this into our build system, and Debian
injects this into their build system, and so on… As mentioned, this is
a cross-distro effort. Also, people can use it in their custom build
systems if they build and distribute binaries internally. The scheme
would obviously be most useful if used comprehensively, but it's still
useful when available partially. We hope that Fedora can lead the way.
(This is similar to build-ids: when initially adopted, they were used
only by some distros, but were useful even then. Nowadays, with
comprehensive adoption, they are even more useful.)
https://hpc.guix.info/blog/2021/09/whats-in-a-package/ contains a nice
description of a pathological case of packaging hacks and binary
redistribution. When trying to unravel something like this,
information embedded directly in the binaries would be quite useful.
== Benefit to Fedora ==
A simple and reliable way to gather information about package versions
of programs is added.
It enhances, instead of replacing, the existing mechanisms.
It is particularly useful when reporting crash dumps, but can also be
used for image introspection and forensincs, license checks and
version scans on containers, etc.
If we adopt this in Fedora, Fedora leads the way on implementing the
standard. Fedora binaries used in any context can be easily
recognized. Fedora binaries provide a better basis to build things.
If other distros adopt this, we can introspect and report on those
binaries easily within the Fedora context. For example, when somebody
is using a container with some programs that originate in the Debian
ecosystem, we would be able to identify those programs without tools
like `apt` or `dpkg-query`. Core dump analaysis executed in the Fedora
host can easily provide useful information about programs from foreign
builds.
== Implementation in Other Distributions ==
=== Microsoft CBL-Mariner ===
[https://en.wikipedia.org/wiki/CBL-Mariner CBL-Mariner] is an
[https://github.com/microsoft/CBL-Mariner open source] Linux
distribution created by Microsoft, targeted at first-party and
container workloads on Azure. It is used both as a container runner
host and a base container image.
Mariner adopted the ELF stamping packaging metadata spec in
[https://github.com/microsoft/CBL-Mariner/blob/1.0/SPECS/mariner-rpm-macros/gen-ld-script.sh
version 1.0], initially to add OS metadata, and package-level metadata
will be added in a following release.
=== Debian ===
A package-level proof-of-concept is included in the
[https://github.com/systemd/package-notes/blob/main/dh_package_notes
package-notes] repository.
A [https://salsa.debian.org/bluca/debhelper/-/tree/notes_metadata
system-level proof-of-concept] that enables ELF stamping by default in
all builds implicitly will be proposed for adoption in the future.
== Scope ==
* Proposal owners:
** create a specification (First version DONE:
[https://systemd.io/COREDUMP_PACKAGE_METADATA
COREDUMP_PACKAGE_METADATA]. We might need to make some adjustments
based on the deployment in Fedora, but no big changes are expected.)
** write a script to generate the package note (First version DONE:
[https://github.com/systemd/package-notes/blob/main/generate-package-notes.py
generate-package-notes.py])
** provide a patch for `redhat-rpm-config` to insert appropriate
compilation options
** extend systemd's coredumpctl to extract and display this
information (DONE: [https://github.com/systemd/systemd/pull/19135 PR
#19135], available in systemd-249)
** submit pull request to Packaging Guidelines
* Other developers:
** possibly add support in abrt?
* Release engineering: There should be no impact.
* Policies and guidelines:
The new flags should be mentioned in Packaging Guidelines.
* Trademark approval: N/A (not needed for this Change)
N/A
* Alignment with Objectives:
It might be relevant for Minimization. Even though it increases the
image size a tiny bit, it makes minimized images work a bit better.
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
<pre>
$ bash -c 'kill -SEGV $$'
$ coredumpctl
TIME PID UID GID SIG COREFILE EXE
SIZE PACKAGE
Mon 2021-03-01 14:37:22 CET 855151 1000 1000 SIGSEGV present
/usr/bin/bash 51.7K bash-5.1.0-2.fc34.x86_64
</pre>
== User Experience ==
`coredumpctl` should display information about package versions.
`readelf --notes` or similar tools can be used on `.so` files and
compiled programs
to extract the JSON blurb that describes the originating package.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Remove the new compilation flags. Rebuild any
packages that were build with the new flags.
* Contingency deadline: Beta freeze.
* Blocks release? No.
== Documentation ==
* https://systemd.io/COREDUMP_PACKAGE_METADATA/
* https://github.com/systemd/package-notes
See also [[Changes/DebuginfodByDefault]].
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrqben@0pointer.net
== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.
The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms. A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.
A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.
A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.
We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.
For the case where we mix binaries from different distros (the third
motivating use case above), this approach is the most useful when this
system is used by all distros and even non-distro builds. The more
widely it is used, the more useful it becomes. The specification was
developed in collaboration with Debian developers, and we hope that
Fedora and Debian will lead the way for this to become as widely used
as build-ids. But even if the information is only available from some
distros, it is still useful, except that fallback mechanisms need to
be implemented.
=== Existing system: `.note.gnu.build-id` ===
We already have build-ids: every ELF object has a `.note.gnu.build-id`
note, and given a core file, we can read the build-id and look it up
in the rpm database (`dnf repoquery --whatprovides debuginfo(build-id)
= …`) to map it to a package name.
Build-ids are unique and compact and very generic and work as expected
in general. But they have some downsides:
* build-ids are not very informative for users. Before the build-id is
converted back to the appropriate package, it's completely opaque.
* build-ids require a working rpm database or an internet connection
to map to the package name.
Three important cases:
* minimal containers: the rpm database is not installed in the
containers. The information about build-ids needs to be stored
externally, so package name information is not available immediately,
but only after offline processing. The new note doesn't depend on the
rpm db in any way.
* handling of a core from a container, where the container and host
have different distros
* self-built and external packages: unless a lot of care is taken to
keep access to the debuginfo packages, this information may be lost.
The new note is available even if the repository metadata gets lost.
Users can easily provide equivalent information in a format that makes
sense in their own environment. It should work even when rpms and debs
and other formats are mixed, e.g. during container image creation.
=== New system: `.note.package` ===
The new note is created and propagated similarly to
`.note.gnu.build-id`. The difference is that we inject the information
about package ''nevra'' from the build system.
The implementation is very simple: `%{build_ldflags}` are extended
with a command to insert a custom note as a separate section in an ELF
object. See [https://github.com/systemd/package-notes/blob/main/hello.spec
hello.spec] for an example. This is done in the default macros, so all
packages that use the prescribed link flags will be affected.
The note is a compact json string. This allows the format to be
trivially extensible (new fields can be added at will), easy to
process (json is extremely popular and parsers are widely available).
Using a single field rather than a set of separated notes is more
space-efficient. With multiple fields the padding and alignment
requirements cause unnecessary overhead.
The system was designed with cross-distro collaboration and is
flexible enough to identify binaries from different packaging formats
and build systems (rpms, debs, custom binaries).
See https://systemd.io/COREDUMP_PACKAGE_METADATA/ for detailed
description of the format.
One of the advantages of using an ELF note, as opposed to say a series
of extended attributes on the binary itself, is that the ELF note gets
automatically captured and copied into a core file by the kernel.
Extended attributes would have to be copied manually, which might not
even be possible because the binary on disk may have been removed by
the time the crash is analyzed.
The overhead is about 200 bytes for each ELF object.
We have about overall 33200 files in `/usr/s?bin/` and about 36600
`.so` files (F35, single architecture,
results from `dnf repoquery -l 2>/dev/null | rg '^/usr/s?bin/' | sort
-u | wc -l`,
`dnf repoquery -l 2>/dev/null | rg '^/usr/lib64/.*\.so$' |sort -u|wc -l`).
If we do this for the whole distro, we get 69800 × 200 = 13 MB.
For a typical installation, we can expect about 300–400 kB.
Thus the overhead of additionally used space is neglible (also see the
Feedback section for more discussion).
Precise measurements TBD once this is turned on and we have real
measurements for a larger number of builds.
=== Examples ===
<pre>
$ objdump -s -j .note.package build/libhello.so
build/libhello.so: file format elf64-x86-64
Contents of section .note.package:
02ec 04000000 63000000 7e1afeca 46444f00 ....c...~...FDO.
02fc 7b227479 7065223a 2272706d 222c226e {"type":"rpm","n
030c 616d6522 3a226865 6c6c6f22 2c227665 ame":"hello","ve
031c 7273696f 6e223a22 302d312e 66633335 rsion":"0-1.fc35
032c 2e783836 5f363422 2c226f73 43706522 .x86_64","osCpe"
033c 3a226370 653a2f6f 3a666564 6f726170 :"cpe:/o:fedorap
034c 726f6a65 63743a66 65646f72 613a3333 roject:fedora:33
035c 227d0000 "}..
</pre>
<pre>
$ readelf --notes build/hello | grep "description data" | sed -e
"s/\s*description data: //g" -e "s/ //g" | xxd -p -r | jq
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x10de
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x10af
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to 0x119f
{
"type": "rpm",
"name": "hello",
"version": "0-1.fc35.x86_64",
"osCpe": "cpe:/o:fedoraproject:fedora:33"
}
</pre>
<pre>
$ coredumpctl info
PID: 44522 (fsverity)
...
Package: fsverity-utils/1.3-1
build-id: ac89bf7175b04d7eec7f6544a923f45be111f0be
Message: Process 44522 (fsverity) of user 1000 dumped core.
Found module
/home/bluca/git/fsverity-utils/libfsverity.so.0 with build-id:
fa40fdfb79aea84167c98ca8a89add9ac4f51069
Metadata for module
/home/bluca/git/fsverity-utils/libfsverity.so.0 owned by FDO found: {
"packageType" : "deb",
"package" : "fsverity-utils",
"packageVersion" : "1.3-1"
}
Found module linux-vdso.so.1 with build-id:
aba08e06103f725e26f1d7c178fb6b76a564a35d
Found module libpthread.so.0 with build-id:
e91114987a0147bd050addbd591eb8994b29f4b3
Found module libdl.so.2 with build-id:
d3583c742dd47aaa860c5ae0c0c5bdbcd2d54f61
Found module ld-linux-x86-64.so.2 with build-id:
f25dfd7b95be4ba386fd71080accae8c0732b711
Found module libcrypto.so.1.1 with build-id:
749142d5ee728a76e7cdc61fd79d2311a77405a2
Found module libc.so.6 with build-id:
18b9a9a8c523e5cfe5b5d946d605d09242f09798
Found module fsverity with build-id:
ac89bf7175b04d7eec7f6544a923f45be111f0be
Metadata for module fsverity owned by FDO found: {
"packageType" : "deb",
"package" : "fsverity-utils",
"packageVersion" : "1.3-1"
}
Stack trace of thread 44522:
#0 0x00007fe7c8af26f4 __GI___nanosleep (libc.so.6 + 0xc66f4)
#1 0x00007fe7c8af262a __sleep (libc.so.6 + 0xc662a)
#2 0x00005608481407dd main (fsverity + 0x27dd)
#3 0x00007fe7c8a5009b __libc_start_main (libc.so.6 + 0x2409b)
#4 0x000056084814094a _start (fsverity + 0x294a)
</pre>
== Feedback ==
See [https://github.com/systemd/systemd/issues/18433 systemd issue
#18433] for upstream discussion and implementation proposals.
=== Concerns about additional changes to files ===
<pre>
17:32:30 <Eighth_Doctor> I think zbyszek underestimates how much of a
problem it is to stamp every ELF binary with ''nevra'' data
17:32:44 <mhroncok> zbyszek: so, assuming python has ~100 ELF .so
files and I change one text file
17:33:22 <mhroncok> (ignore for the time being that the .so files
often changed because of toolchain updates and assume they are stable)
</pre>
I tested this with python3.10. So far there are 13 builds of that
package in F35:
`python3.10-3.10.0-1.fc35`,
`python3.10-3.10.0~a6-1.fc35`,
`python3.10-3.10.0~a6-2.fc35`,
`python3.10-3.10.0~a7-1.fc35`,
`python3.10-3.10.0~b1-1.fc35`,
`python3.10-3.10.0~b2-2.fc35`,
`python3.10-3.10.0~b2-3.fc35`,
`python3.10-3.10.0~b3-1.fc35`,
`python3.10-3.10.0~b4-1.fc35`,
`python3.10-3.10.0~b4-2.fc35`,
`python3.10-3.10.0~b4-3.fc35`,
`python3.10-3.10.0~rc1-1.fc35`,
`python3.10-3.10.0~rc2-1.fc35`.
I extracted the builds (for `.x86_64`) and made a list of all `.so`
files (1368 files), and calculated sha256 hashes for them. No two
files repeat, there are 1368 distinct hashes. So the files are
'''already''' different between builds and the additional proposed
metadata does will not make a significant difference.
Note that this range of Python versions encompasses periods when the
package is under development and undergoes significant changes (alpha
versions), and when it's only undergoing small changes (rc versions).
The fact that we get different files in each build is not surprising,
because files embed build-ids which differ between builds. But even if
we ignore those, binaries generally differ between builds. Even sizes
tend to vary between builds: there are 636 distinct `.so` file sizes,
i.e. on average any given size only repeats twice (presumably most
often for the same file). Running `diffoscope` on `.so` files from
different builds shows minor changes in the assembly which I did not
analyze futher.
If people have specific questions, for example about overhead in some
scenario, I'd be happy to answer them. Until now, the issues that were
raised were very vague, so it's impossible to answer them.
=== Why not just use the rpm database? ===
<pre>
17:34:33 <dcantrell> The main reason for this appears to be that we
need the RPM db locally to resolve build-ids to package names. But
since containers wipe /var/lib/rpm, we can't do that. So the solution
is to put the ''nevra'' in ELF metadata?
17:34:39 <dcantrell> That feels like the wrong approach.
</pre>
First, there are legitimate reasons to strip packaging metadata from
images. For example, for an initrd image from rpms, I get 117 MB of
files (without compression), and out of this `/var/lib/rpm` is 5.9 MB,
and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not
much'', but still too much to keep in the image unless necessary.
Similar ratios will happen for containers of similar size. Reducing
image size by one tenth is important. There is no `rpm` or `dnf` in
the image, to the package database is not even usable without external
tools.
As discussed on IRC
(https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-05-11-17.01.log.html),
the containers ''we'' build don't wipe this metadata, but custom
Dockerfiles do that.
Second, as described in Description section above, not everybody and
everything uses rpm. The Fedora motto is "we make an operating system
and we make it easy for you to do useful stuff with it" (and yes, this
is an actual quote from the official docs), and this stuff involves
reusing our binaries in containers and custom installations and
whatnot, not just straightforward installations with `dnf`. And in the
other direction, people will build their own binaries that are not
packaged as rpms. But it is still important to be able to figure out
the exact version of a binary, especially after it crashes.
=== Why do this in Fedora? ===
<pre>
17:36:49 <mhroncok> I don't understand how non-rpm distros and custom
built binaries are affected by our rpm-build environment :/
</pre>
The idea is that we inject this into our build system, and Debian
injects this into their build system, and so on… As mentioned, this is
a cross-distro effort. Also, people can use it in their custom build
systems if they build and distribute binaries internally. The scheme
would obviously be most useful if used comprehensively, but it's still
useful when available partially. We hope that Fedora can lead the way.
(This is similar to build-ids: when initially adopted, they were used
only by some distros, but were useful even then. Nowadays, with
comprehensive adoption, they are even more useful.)
https://hpc.guix.info/blog/2021/09/whats-in-a-package/ contains a nice
description of a pathological case of packaging hacks and binary
redistribution. When trying to unravel something like this,
information embedded directly in the binaries would be quite useful.
== Benefit to Fedora ==
A simple and reliable way to gather information about package versions
of programs is added.
It enhances, instead of replacing, the existing mechanisms.
It is particularly useful when reporting crash dumps, but can also be
used for image introspection and forensincs, license checks and
version scans on containers, etc.
If we adopt this in Fedora, Fedora leads the way on implementing the
standard. Fedora binaries used in any context can be easily
recognized. Fedora binaries provide a better basis to build things.
If other distros adopt this, we can introspect and report on those
binaries easily within the Fedora context. For example, when somebody
is using a container with some programs that originate in the Debian
ecosystem, we would be able to identify those programs without tools
like `apt` or `dpkg-query`. Core dump analaysis executed in the Fedora
host can easily provide useful information about programs from foreign
builds.
== Implementation in Other Distributions ==
=== Microsoft CBL-Mariner ===
[https://en.wikipedia.org/wiki/CBL-Mariner CBL-Mariner] is an
[https://github.com/microsoft/CBL-Mariner open source] Linux
distribution created by Microsoft, targeted at first-party and
container workloads on Azure. It is used both as a container runner
host and a base container image.
Mariner adopted the ELF stamping packaging metadata spec in
[https://github.com/microsoft/CBL-Mariner/blob/1.0/SPECS/mariner-rpm-macros/gen-ld-script.sh
version 1.0], initially to add OS metadata, and package-level metadata
will be added in a following release.
=== Debian ===
A package-level proof-of-concept is included in the
[https://github.com/systemd/package-notes/blob/main/dh_package_notes
package-notes] repository.
A [https://salsa.debian.org/bluca/debhelper/-/tree/notes_metadata
system-level proof-of-concept] that enables ELF stamping by default in
all builds implicitly will be proposed for adoption in the future.
== Scope ==
* Proposal owners:
** create a specification (First version DONE:
[https://systemd.io/COREDUMP_PACKAGE_METADATA
COREDUMP_PACKAGE_METADATA]. We might need to make some adjustments
based on the deployment in Fedora, but no big changes are expected.)
** write a script to generate the package note (First version DONE:
[https://github.com/systemd/package-notes/blob/main/generate-package-notes.py
generate-package-notes.py])
** provide a patch for `redhat-rpm-config` to insert appropriate
compilation options
** extend systemd's coredumpctl to extract and display this
information (DONE: [https://github.com/systemd/systemd/pull/19135 PR
#19135], available in systemd-249)
** submit pull request to Packaging Guidelines
* Other developers:
** possibly add support in abrt?
* Release engineering: There should be no impact.
* Policies and guidelines:
The new flags should be mentioned in Packaging Guidelines.
* Trademark approval: N/A (not needed for this Change)
N/A
* Alignment with Objectives:
It might be relevant for Minimization. Even though it increases the
image size a tiny bit, it makes minimized images work a bit better.
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
<pre>
$ bash -c 'kill -SEGV $$'
$ coredumpctl
TIME PID UID GID SIG COREFILE EXE
SIZE PACKAGE
Mon 2021-03-01 14:37:22 CET 855151 1000 1000 SIGSEGV present
/usr/bin/bash 51.7K bash-5.1.0-2.fc34.x86_64
</pre>
== User Experience ==
`coredumpctl` should display information about package versions.
`readelf --notes` or similar tools can be used on `.so` files and
compiled programs
to extract the JSON blurb that describes the originating package.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Remove the new compilation flags. Rebuild any
packages that were build with the new flags.
* Contingency deadline: Beta freeze.
* Blocks release? No.
== Documentation ==
* https://systemd.io/COREDUMP_PACKAGE_METADATA/
* https://github.com/systemd/package-notes
See also [[Changes/DebuginfodByDefault]].
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[USN-5124-1] GNU binutils vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5124-1
October 25, 2021
binutils vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in GNU binutils.
Software Description:
- binutils: GNU assembler, linker and binary utilities
Details:
It was discovered that GNU binutils incorrectly handled certain hash
lookups. An attacker could use this issue to cause GNU binutils to crash,
resulting in a denial of service, or possibly execute arbitrary code.
(CVE-2020-16592)
It was discovered that GNU binutils incorrectly handled certain corrupt
DWARF debug sections. An attacker could possibly use this issue to cause
GNU binutils to consume memory, resulting in a denial of service.
(CVE-2021-3487)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 20.04 LTS:
binutils 2.34-6ubuntu1.3
binutils-multiarch 2.34-6ubuntu1.3
Ubuntu 18.04 LTS:
binutils 2.30-21ubuntu1~18.04.7
binutils-multiarch 2.30-21ubuntu1~18.04.7
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5124-1
CVE-2020-16592, CVE-2021-3487
Package Information:
https://launchpad.net/ubuntu/+source/binutils/2.34-6ubuntu1.3
https://launchpad.net/ubuntu/+source/binutils/2.30-21ubuntu1~18.04.7
Ubuntu Security Notice USN-5124-1
October 25, 2021
binutils vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in GNU binutils.
Software Description:
- binutils: GNU assembler, linker and binary utilities
Details:
It was discovered that GNU binutils incorrectly handled certain hash
lookups. An attacker could use this issue to cause GNU binutils to crash,
resulting in a denial of service, or possibly execute arbitrary code.
(CVE-2020-16592)
It was discovered that GNU binutils incorrectly handled certain corrupt
DWARF debug sections. An attacker could possibly use this issue to cause
GNU binutils to consume memory, resulting in a denial of service.
(CVE-2021-3487)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 20.04 LTS:
binutils 2.34-6ubuntu1.3
binutils-multiarch 2.34-6ubuntu1.3
Ubuntu 18.04 LTS:
binutils 2.30-21ubuntu1~18.04.7
binutils-multiarch 2.30-21ubuntu1~18.04.7
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5124-1
CVE-2020-16592, CVE-2021-3487
Package Information:
https://launchpad.net/ubuntu/+source/binutils/2.34-6ubuntu1.3
https://launchpad.net/ubuntu/+source/binutils/2.30-21ubuntu1~18.04.7
[USN-5123-2] MySQL vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5123-2
October 25, 2021
mysql-5.7 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
Summary:
Several security issues were fixed in MySQL.
Software Description:
- mysql-5.7: MySQL database
Details:
USN-5123-1 fixed several vulnerabilities in MySQL. This update provides
the corresponding update for Ubuntu 16.04 ESM.
Original advisory details:
Multiple security issues were discovered in MySQL and this update includes
new upstream MySQL versions to fix these issues.
MySQL has been updated to 8.0.27 in Ubuntu 20.04 LTS, Ubuntu 21.04, and
Ubuntu 21.10. Ubuntu 18.04 LTS has been updated to MySQL 5.7.36.
In addition to security fixes, the updated packages contain bug fixes, new
features, and possibly incompatible changes.
Please see the following for more information:
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-36.html
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html
https://www.oracle.com/security-alerts/cpuoct2021.html
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
mysql-server-5.7 5.7.36-0ubuntu0.16.04.1+esm1
This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.
References:
https://ubuntu.com/security/notices/USN-5123-2
https://ubuntu.com/security/notices/USN-5123-1
CVE-2021-35604, CVE-2021-35624
Ubuntu Security Notice USN-5123-2
October 25, 2021
mysql-5.7 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 ESM
Summary:
Several security issues were fixed in MySQL.
Software Description:
- mysql-5.7: MySQL database
Details:
USN-5123-1 fixed several vulnerabilities in MySQL. This update provides
the corresponding update for Ubuntu 16.04 ESM.
Original advisory details:
Multiple security issues were discovered in MySQL and this update includes
new upstream MySQL versions to fix these issues.
MySQL has been updated to 8.0.27 in Ubuntu 20.04 LTS, Ubuntu 21.04, and
Ubuntu 21.10. Ubuntu 18.04 LTS has been updated to MySQL 5.7.36.
In addition to security fixes, the updated packages contain bug fixes, new
features, and possibly incompatible changes.
Please see the following for more information:
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-36.html
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html
https://www.oracle.com/security-alerts/cpuoct2021.html
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 ESM:
mysql-server-5.7 5.7.36-0ubuntu0.16.04.1+esm1
This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.
References:
https://ubuntu.com/security/notices/USN-5123-2
https://ubuntu.com/security/notices/USN-5123-1
CVE-2021-35604, CVE-2021-35624
[USN-5123-1] MySQL vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5123-1
October 25, 2021
mysql-5.7, mysql-8.0 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in MySQL.
Software Description:
- mysql-8.0: MySQL database
- mysql-5.7: MySQL database
Details:
Multiple security issues were discovered in MySQL and this update includes
new upstream MySQL versions to fix these issues.
MySQL has been updated to 8.0.27 in Ubuntu 20.04 LTS, Ubuntu 21.04, and
Ubuntu 21.10. Ubuntu 18.04 LTS has been updated to MySQL 5.7.36.
In addition to security fixes, the updated packages contain bug fixes, new
features, and possibly incompatible changes.
Please see the following for more information:
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-36.html
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html
https://www.oracle.com/security-alerts/cpuoct2021.html
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
mysql-server-8.0 8.0.27-0ubuntu0.21.10.1
Ubuntu 21.04:
mysql-server-8.0 8.0.27-0ubuntu0.21.04.1
Ubuntu 20.04 LTS:
mysql-server-8.0 8.0.27-0ubuntu0.20.04.1
Ubuntu 18.04 LTS:
mysql-server-5.7 5.7.36-0ubuntu0.18.04.1
This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.
References:
https://ubuntu.com/security/notices/USN-5123-1
CVE-2021-2478, CVE-2021-2479, CVE-2021-2481, CVE-2021-35546,
CVE-2021-35575, CVE-2021-35577, CVE-2021-35584, CVE-2021-35591,
CVE-2021-35596, CVE-2021-35597, CVE-2021-35602, CVE-2021-35604,
CVE-2021-35607, CVE-2021-35608, CVE-2021-35610, CVE-2021-35612,
CVE-2021-35613, CVE-2021-35622, CVE-2021-35623, CVE-2021-35624,
CVE-2021-35625, CVE-2021-35626, CVE-2021-35627, CVE-2021-35628,
CVE-2021-35630, CVE-2021-35631, CVE-2021-35632, CVE-2021-35633,
CVE-2021-35634, CVE-2021-35635, CVE-2021-35636, CVE-2021-35637,
CVE-2021-35638, CVE-2021-35639, CVE-2021-35640, CVE-2021-35641,
CVE-2021-35642, CVE-2021-35643, CVE-2021-35644, CVE-2021-35645,
CVE-2021-35646, CVE-2021-35647, CVE-2021-35648
Package Information:
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.21.10.1
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.21.04.1
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.20.04.1
https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.36-0ubuntu0.18.04.1
Ubuntu Security Notice USN-5123-1
October 25, 2021
mysql-5.7, mysql-8.0 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in MySQL.
Software Description:
- mysql-8.0: MySQL database
- mysql-5.7: MySQL database
Details:
Multiple security issues were discovered in MySQL and this update includes
new upstream MySQL versions to fix these issues.
MySQL has been updated to 8.0.27 in Ubuntu 20.04 LTS, Ubuntu 21.04, and
Ubuntu 21.10. Ubuntu 18.04 LTS has been updated to MySQL 5.7.36.
In addition to security fixes, the updated packages contain bug fixes, new
features, and possibly incompatible changes.
Please see the following for more information:
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-36.html
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html
https://www.oracle.com/security-alerts/cpuoct2021.html
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
mysql-server-8.0 8.0.27-0ubuntu0.21.10.1
Ubuntu 21.04:
mysql-server-8.0 8.0.27-0ubuntu0.21.04.1
Ubuntu 20.04 LTS:
mysql-server-8.0 8.0.27-0ubuntu0.20.04.1
Ubuntu 18.04 LTS:
mysql-server-5.7 5.7.36-0ubuntu0.18.04.1
This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.
References:
https://ubuntu.com/security/notices/USN-5123-1
CVE-2021-2478, CVE-2021-2479, CVE-2021-2481, CVE-2021-35546,
CVE-2021-35575, CVE-2021-35577, CVE-2021-35584, CVE-2021-35591,
CVE-2021-35596, CVE-2021-35597, CVE-2021-35602, CVE-2021-35604,
CVE-2021-35607, CVE-2021-35608, CVE-2021-35610, CVE-2021-35612,
CVE-2021-35613, CVE-2021-35622, CVE-2021-35623, CVE-2021-35624,
CVE-2021-35625, CVE-2021-35626, CVE-2021-35627, CVE-2021-35628,
CVE-2021-35630, CVE-2021-35631, CVE-2021-35632, CVE-2021-35633,
CVE-2021-35634, CVE-2021-35635, CVE-2021-35636, CVE-2021-35637,
CVE-2021-35638, CVE-2021-35639, CVE-2021-35640, CVE-2021-35641,
CVE-2021-35642, CVE-2021-35643, CVE-2021-35644, CVE-2021-35645,
CVE-2021-35646, CVE-2021-35647, CVE-2021-35648
Package Information:
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.21.10.1
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.21.04.1
https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.27-0ubuntu0.20.04.1
https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.36-0ubuntu0.18.04.1
[USN-5122-1] Apport vulnerability
==========================================================================
Ubuntu Security Notice USN-5122-1
October 25, 2021
apport vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Apport could be made to create files as the administrator.
Software Description:
- apport: automatically generate crash reports for debugging
Details:
It was discovered that Apport could be tricked into writing core files as
root into arbitrary directories in certain scenarios. A local attacker
could possibly use this issue to escalate privileges. This update will
cause Apport to generate all core files in the /var/lib/apport/coredump
directory.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
apport 2.20.11-0ubuntu71
python3-apport 2.20.11-0ubuntu71
Ubuntu 21.04:
apport 2.20.11-0ubuntu65.4
python3-apport 2.20.11-0ubuntu65.4
Ubuntu 20.04 LTS:
apport 2.20.11-0ubuntu27.21
python3-apport 2.20.11-0ubuntu27.21
Ubuntu 18.04 LTS:
apport 2.20.9-0ubuntu7.27
python3-apport 2.20.9-0ubuntu7.27
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5122-1
https://launchpad.net/bugs/1948657
Package Information:
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu71
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu65.4
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu27.21
https://launchpad.net/ubuntu/+source/apport/2.20.9-0ubuntu7.27
Ubuntu Security Notice USN-5122-1
October 25, 2021
apport vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 21.10
- Ubuntu 21.04
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Apport could be made to create files as the administrator.
Software Description:
- apport: automatically generate crash reports for debugging
Details:
It was discovered that Apport could be tricked into writing core files as
root into arbitrary directories in certain scenarios. A local attacker
could possibly use this issue to escalate privileges. This update will
cause Apport to generate all core files in the /var/lib/apport/coredump
directory.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 21.10:
apport 2.20.11-0ubuntu71
python3-apport 2.20.11-0ubuntu71
Ubuntu 21.04:
apport 2.20.11-0ubuntu65.4
python3-apport 2.20.11-0ubuntu65.4
Ubuntu 20.04 LTS:
apport 2.20.11-0ubuntu27.21
python3-apport 2.20.11-0ubuntu27.21
Ubuntu 18.04 LTS:
apport 2.20.9-0ubuntu7.27
python3-apport 2.20.9-0ubuntu7.27
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5122-1
https://launchpad.net/bugs/1948657
Package Information:
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu71
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu65.4
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu27.21
https://launchpad.net/ubuntu/+source/apport/2.20.9-0ubuntu7.27
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-10-25.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
bitlbee-discord orphan 2 weeks ago
cAudio orphan 2 weeks ago
crcimg orphan 2 weeks ago
elog orphan 2 weeks ago
erlang-certifi erlang-maint-sig, orphan 0 weeks ago
erlang-cf erlang-maint-sig, orphan 0 weeks ago
erlang-cth_readable erlang-maint-sig, orphan 0 weeks ago
erlang-erlware_commons erlang-maint-sig, orphan 0 weeks ago
erlang-eunit_formatters erlang-maint-sig, orphan 0 weeks ago
erlang-hex_core erlang-maint-sig, orphan 0 weeks ago
erlang-providers erlang-maint-sig, orphan 0 weeks ago
erlang-relx erlang-maint-sig, orphan 0 weeks ago
erlang-ssl_verify_fun erlang-maint-sig, orphan 0 weeks ago
fedmod nphilipp, orphan 4 weeks ago
gauche-gl orphan 2 weeks ago
gfm orphan 2 weeks ago
ghc-HStringTemplate orphan 2 weeks ago
ghc-filestore orphan 2 weeks ago
ghc-hoauth2 orphan 2 weeks ago
ghc-recaptcha orphan 2 weeks ago
ghc-uri orphan 2 weeks ago
ghc-uri-bytestring-aeson orphan 2 weeks ago
ghc-url orphan 2 weeks ago
gitit orphan 2 weeks ago
golang-github-dgraph-io-badger orphan 2 weeks ago
golang-github-dgraph-io- orphan 2 weeks ago
ristretto
golang-github-geziyor orphan 2 weeks ago
golang-github-jacobsa-crypto orphan 3 weeks ago
golang-github-jacobsa-oglemock orphan 3 weeks ago
golang-github-jacobsa-ogletest orphan 3 weeks ago
golang-github-jacobsa-reqtrace orphan 3 weeks ago
golang-github-milochristiansen- go-sig, orphan 2 weeks ago
axis2
golang-github-milochristiansen- go-sig, orphan 2 weeks ago
lua
golang-github-rfjakob-gocryptfs orphan 3 weeks ago
golang-github-sabhiram- orphan 3 weeks ago
gitignore
hddfancontrol orphan 2 weeks ago
hyperrogue orphan 2 weeks ago
kdevelop-python dvratil, jgrulich, kde-sig, 4 weeks ago
orphan
kdocker kde-sig, orphan, rdieter 4 weeks ago
libcxl orphan 1 weeks ago
libocxl orphan 1 weeks ago
libsoc orphan 2 weeks ago
libticables2 orphan 2 weeks ago
libticalcs2 orphan 2 weeks ago
libticonv orphan 2 weeks ago
libtifiles2 orphan 2 weeks ago
mantis orphan 2 weeks ago
maven-indexer galileo, mizdebsk, orphan 2 weeks ago
minetestmapper orphan 2 weeks ago
mygui orphan 2 weeks ago
ocaml-charinfo-width orphan 2 weeks ago
ocaml-cmdliner orphan 2 weeks ago
ocaml-cudf orphan 2 weeks ago
ocaml-lambda-term avsej, orphan 2 weeks ago
ocaml-lwt-log orphan 2 weeks ago
ocaml-mmap orphan 2 weeks ago
ocaml-ocplib-endian orphan 2 weeks ago
ocaml-result andyli, orphan, rjones 2 weeks ago
ocaml-zed orphan 2 weeks ago
perl-Nagios-Plugin jpo, orphan, ppisar 2 weeks ago
perl-WebService-Dropbox mathstuf, orphan 4 weeks ago
php-voms-admin orphan 2 weeks ago
platform orphan, sergiomb 2 weeks ago
ptpd jondkent, orphan 2 weeks ago
purple-mattermost orphan 2 weeks ago
python-email_reply_parser orphan, python-sig 4 weeks ago
python-first orphan, python-sig 4 weeks ago
python-graphene-sqlalchemy orphan 4 weeks ago
python-graphql-server orphan 4 weeks ago
python-parallel-ssh orphan 4 weeks ago
python-pipreqs orphan, python-sig 4 weeks ago
python-plette orphan, pkopkan, python-sig 4 weeks ago
python-power orphan, python-sig 4 weeks ago
python-sockjs-tornado orphan, python-sig 2 weeks ago
python-ssh2-python orphan 4 weeks ago
python-yarg orphan, python-sig 4 weeks ago
qotd orphan 2 weeks ago
quasselgrep orphan 2 weeks ago
rubygem-ancestry jaruga, orphan 4 weeks ago
rubygem-cliver orphan 6 weeks ago
rubygem-gem-patch orphan 6 weeks ago
rubygem-scoped_search orphan 6 weeks ago
spasm-ng orphan 2 weeks ago
speech-dispatcher orphan 2 weeks ago
tfdocgen orphan 2 weeks ago
tilp2 orphan 2 weeks ago
treefrog-framework orphan 2 weeks ago
uglify-js1 nodejs-sig, orphan, patches 2 weeks ago
unshield orphan 2 weeks ago
waiverdb lholecek, lucarval, orphan, 4 weeks ago
ralph, vmaljulin
xoreos-tools orphan 2 weeks ago
yarock kde-sig, martinkg, orphan 4 weeks ago
zgrab2 orphan 2 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-10-25.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
alexl: speech-dispatcher
amdunn: ocaml-mmap, ocaml-ocplib-endian, ocaml-cmdliner
anaconda-maint: speech-dispatcher
andyli: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cudf, ocaml-cmdliner
avsej: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-ocplib-endian, ocaml-lwt-log
berrange: speech-dispatcher
besser82: speech-dispatcher
bonzini: speech-dispatcher
bruno: ocaml-result, ocaml-cmdliner
caillon: speech-dispatcher
caolanm: speech-dispatcher
carlwgeorge: speech-dispatcher
cheeselee: ocaml-mmap, ocaml-ocplib-endian, ocaml-cudf, ocaml-cmdliner
chkr: speech-dispatcher
crobinso: speech-dispatcher
dchen: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
decathorpe: speech-dispatcher
defolos: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-ocplib-endian, ocaml-lwt-log, ocaml-cmdliner
dvratil: speech-dispatcher, kdevelop-python
dwmw2: speech-dispatcher
ehabkost: speech-dispatcher
erlang-maint-sig: erlang-erlware_commons, erlang-cth_readable, erlang-certifi,
erlang-hex_core, erlang-providers, erlang-ssl_verify_fun, erlang-cf,
erlang-relx, erlang-eunit_formatters
eseyman: perl-Nagios-Plugin
fab: platform
galileo: maven-indexer
gnome-sig: speech-dispatcher
go-sig: golang-github-milochristiansen-axis2, golang-github-milochristiansen-lua
heliocastro: speech-dispatcher
hobbes1069: speech-dispatcher
jaruga: rubygem-ancestry
jforbes: speech-dispatcher
jgrulich: speech-dispatcher, kdevelop-python
jjames: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-cudf, ocaml-lwt-log, ocaml-ocplib-endian, ocaml-cmdliner
jkonecny: speech-dispatcher
jondkent: ptpd
jpo: perl-Nagios-Plugin
jreznik: speech-dispatcher
jskarvad: speech-dispatcher
jwrdegoede: speech-dispatcher
kalev: speech-dispatcher
kde-sig: kdocker, speech-dispatcher, yarock, kdevelop-python
kevin: speech-dispatcher
lbazan: python-ssh2-python
lholecek: waiverdb
limb: speech-dispatcher, ocaml-cmdliner
lkundrak: speech-dispatcher
lucarval: waiverdb
lucilanga: speech-dispatcher
lupinix: speech-dispatcher
m4rtink: speech-dispatcher
martinkg: yarock, perl-WebService-Dropbox
mathstuf: perl-WebService-Dropbox
mbarnes: speech-dispatcher
mdbooth: ocaml-mmap, ocaml-ocplib-endian
melmorabity: platform
mizdebsk: maven-indexer
ngompa: speech-dispatcher
nodejs-sig: uglify-js1
nphilipp: fedmod
nushio: speech-dispatcher
olysonek: speech-dispatcher
patches: uglify-js1
peter: erlang-erlware_commons, erlang-cth_readable, erlang-certifi,
erlang-hex_core, erlang-providers, erlang-ssl_verify_fun, erlang-cf,
erlang-relx, erlang-eunit_formatters
pkopkan: python-plette
ppisar: perl-Nagios-Plugin
python-sig: python-sockjs-tornado, python-yarg, python-first, python-pipreqs,
python-power, python-email_reply_parser, python-plette
quintela: speech-dispatcher
ralph: waiverdb
rdieter: kdocker, speech-dispatcher
rhughes: speech-dispatcher
rjones: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cudf,
speech-dispatcher, ocaml-cmdliner
rstrode: speech-dispatcher
rvykydal: speech-dispatcher
salimma: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
sbueno: speech-dispatcher
scottt: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
sergiomb: platform
spot: speech-dispatcher
ssp: speech-dispatcher
than: speech-dispatcher
tpopela: speech-dispatcher
tuxbrewr: speech-dispatcher
virtmaint-sig: speech-dispatcher
vmaljulin: waiverdb
vpodzime: speech-dispatcher
vponcova: speech-dispatcher
zbyszek: speech-dispatcher
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-10-25.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
bitlbee-discord orphan 2 weeks ago
cAudio orphan 2 weeks ago
crcimg orphan 2 weeks ago
elog orphan 2 weeks ago
erlang-certifi erlang-maint-sig, orphan 0 weeks ago
erlang-cf erlang-maint-sig, orphan 0 weeks ago
erlang-cth_readable erlang-maint-sig, orphan 0 weeks ago
erlang-erlware_commons erlang-maint-sig, orphan 0 weeks ago
erlang-eunit_formatters erlang-maint-sig, orphan 0 weeks ago
erlang-hex_core erlang-maint-sig, orphan 0 weeks ago
erlang-providers erlang-maint-sig, orphan 0 weeks ago
erlang-relx erlang-maint-sig, orphan 0 weeks ago
erlang-ssl_verify_fun erlang-maint-sig, orphan 0 weeks ago
fedmod nphilipp, orphan 4 weeks ago
gauche-gl orphan 2 weeks ago
gfm orphan 2 weeks ago
ghc-HStringTemplate orphan 2 weeks ago
ghc-filestore orphan 2 weeks ago
ghc-hoauth2 orphan 2 weeks ago
ghc-recaptcha orphan 2 weeks ago
ghc-uri orphan 2 weeks ago
ghc-uri-bytestring-aeson orphan 2 weeks ago
ghc-url orphan 2 weeks ago
gitit orphan 2 weeks ago
golang-github-dgraph-io-badger orphan 2 weeks ago
golang-github-dgraph-io- orphan 2 weeks ago
ristretto
golang-github-geziyor orphan 2 weeks ago
golang-github-jacobsa-crypto orphan 3 weeks ago
golang-github-jacobsa-oglemock orphan 3 weeks ago
golang-github-jacobsa-ogletest orphan 3 weeks ago
golang-github-jacobsa-reqtrace orphan 3 weeks ago
golang-github-milochristiansen- go-sig, orphan 2 weeks ago
axis2
golang-github-milochristiansen- go-sig, orphan 2 weeks ago
lua
golang-github-rfjakob-gocryptfs orphan 3 weeks ago
golang-github-sabhiram- orphan 3 weeks ago
gitignore
hddfancontrol orphan 2 weeks ago
hyperrogue orphan 2 weeks ago
kdevelop-python dvratil, jgrulich, kde-sig, 4 weeks ago
orphan
kdocker kde-sig, orphan, rdieter 4 weeks ago
libcxl orphan 1 weeks ago
libocxl orphan 1 weeks ago
libsoc orphan 2 weeks ago
libticables2 orphan 2 weeks ago
libticalcs2 orphan 2 weeks ago
libticonv orphan 2 weeks ago
libtifiles2 orphan 2 weeks ago
mantis orphan 2 weeks ago
maven-indexer galileo, mizdebsk, orphan 2 weeks ago
minetestmapper orphan 2 weeks ago
mygui orphan 2 weeks ago
ocaml-charinfo-width orphan 2 weeks ago
ocaml-cmdliner orphan 2 weeks ago
ocaml-cudf orphan 2 weeks ago
ocaml-lambda-term avsej, orphan 2 weeks ago
ocaml-lwt-log orphan 2 weeks ago
ocaml-mmap orphan 2 weeks ago
ocaml-ocplib-endian orphan 2 weeks ago
ocaml-result andyli, orphan, rjones 2 weeks ago
ocaml-zed orphan 2 weeks ago
perl-Nagios-Plugin jpo, orphan, ppisar 2 weeks ago
perl-WebService-Dropbox mathstuf, orphan 4 weeks ago
php-voms-admin orphan 2 weeks ago
platform orphan, sergiomb 2 weeks ago
ptpd jondkent, orphan 2 weeks ago
purple-mattermost orphan 2 weeks ago
python-email_reply_parser orphan, python-sig 4 weeks ago
python-first orphan, python-sig 4 weeks ago
python-graphene-sqlalchemy orphan 4 weeks ago
python-graphql-server orphan 4 weeks ago
python-parallel-ssh orphan 4 weeks ago
python-pipreqs orphan, python-sig 4 weeks ago
python-plette orphan, pkopkan, python-sig 4 weeks ago
python-power orphan, python-sig 4 weeks ago
python-sockjs-tornado orphan, python-sig 2 weeks ago
python-ssh2-python orphan 4 weeks ago
python-yarg orphan, python-sig 4 weeks ago
qotd orphan 2 weeks ago
quasselgrep orphan 2 weeks ago
rubygem-ancestry jaruga, orphan 4 weeks ago
rubygem-cliver orphan 6 weeks ago
rubygem-gem-patch orphan 6 weeks ago
rubygem-scoped_search orphan 6 weeks ago
spasm-ng orphan 2 weeks ago
speech-dispatcher orphan 2 weeks ago
tfdocgen orphan 2 weeks ago
tilp2 orphan 2 weeks ago
treefrog-framework orphan 2 weeks ago
uglify-js1 nodejs-sig, orphan, patches 2 weeks ago
unshield orphan 2 weeks ago
waiverdb lholecek, lucarval, orphan, 4 weeks ago
ralph, vmaljulin
xoreos-tools orphan 2 weeks ago
yarock kde-sig, martinkg, orphan 4 weeks ago
zgrab2 orphan 2 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-10-25.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
alexl: speech-dispatcher
amdunn: ocaml-mmap, ocaml-ocplib-endian, ocaml-cmdliner
anaconda-maint: speech-dispatcher
andyli: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cudf, ocaml-cmdliner
avsej: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-ocplib-endian, ocaml-lwt-log
berrange: speech-dispatcher
besser82: speech-dispatcher
bonzini: speech-dispatcher
bruno: ocaml-result, ocaml-cmdliner
caillon: speech-dispatcher
caolanm: speech-dispatcher
carlwgeorge: speech-dispatcher
cheeselee: ocaml-mmap, ocaml-ocplib-endian, ocaml-cudf, ocaml-cmdliner
chkr: speech-dispatcher
crobinso: speech-dispatcher
dchen: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
decathorpe: speech-dispatcher
defolos: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-ocplib-endian, ocaml-lwt-log, ocaml-cmdliner
dvratil: speech-dispatcher, kdevelop-python
dwmw2: speech-dispatcher
ehabkost: speech-dispatcher
erlang-maint-sig: erlang-erlware_commons, erlang-cth_readable, erlang-certifi,
erlang-hex_core, erlang-providers, erlang-ssl_verify_fun, erlang-cf,
erlang-relx, erlang-eunit_formatters
eseyman: perl-Nagios-Plugin
fab: platform
galileo: maven-indexer
gnome-sig: speech-dispatcher
go-sig: golang-github-milochristiansen-axis2, golang-github-milochristiansen-lua
heliocastro: speech-dispatcher
hobbes1069: speech-dispatcher
jaruga: rubygem-ancestry
jforbes: speech-dispatcher
jgrulich: speech-dispatcher, kdevelop-python
jjames: ocaml-lambda-term, ocaml-mmap, ocaml-result, ocaml-charinfo-width,
ocaml-zed, ocaml-cudf, ocaml-lwt-log, ocaml-ocplib-endian, ocaml-cmdliner
jkonecny: speech-dispatcher
jondkent: ptpd
jpo: perl-Nagios-Plugin
jreznik: speech-dispatcher
jskarvad: speech-dispatcher
jwrdegoede: speech-dispatcher
kalev: speech-dispatcher
kde-sig: kdocker, speech-dispatcher, yarock, kdevelop-python
kevin: speech-dispatcher
lbazan: python-ssh2-python
lholecek: waiverdb
limb: speech-dispatcher, ocaml-cmdliner
lkundrak: speech-dispatcher
lucarval: waiverdb
lucilanga: speech-dispatcher
lupinix: speech-dispatcher
m4rtink: speech-dispatcher
martinkg: yarock, perl-WebService-Dropbox
mathstuf: perl-WebService-Dropbox
mbarnes: speech-dispatcher
mdbooth: ocaml-mmap, ocaml-ocplib-endian
melmorabity: platform
mizdebsk: maven-indexer
ngompa: speech-dispatcher
nodejs-sig: uglify-js1
nphilipp: fedmod
nushio: speech-dispatcher
olysonek: speech-dispatcher
patches: uglify-js1
peter: erlang-erlware_commons, erlang-cth_readable, erlang-certifi,
erlang-hex_core, erlang-providers, erlang-ssl_verify_fun, erlang-cf,
erlang-relx, erlang-eunit_formatters
pkopkan: python-plette
ppisar: perl-Nagios-Plugin
python-sig: python-sockjs-tornado, python-yarg, python-first, python-pipreqs,
python-power, python-email_reply_parser, python-plette
quintela: speech-dispatcher
ralph: waiverdb
rdieter: kdocker, speech-dispatcher
rhughes: speech-dispatcher
rjones: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cudf,
speech-dispatcher, ocaml-cmdliner
rstrode: speech-dispatcher
rvykydal: speech-dispatcher
salimma: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
sbueno: speech-dispatcher
scottt: ocaml-mmap, ocaml-result, ocaml-ocplib-endian, ocaml-cmdliner
sergiomb: platform
spot: speech-dispatcher
ssp: speech-dispatcher
than: speech-dispatcher
tpopela: speech-dispatcher
tuxbrewr: speech-dispatcher
virtmaint-sig: speech-dispatcher
vmaljulin: waiverdb
vpodzime: speech-dispatcher
vponcova: speech-dispatcher
zbyszek: speech-dispatcher
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Friday, October 22, 2021
[USN-5121-1] Mailman vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5121-1
October 22, 2021
mailman vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
Summary:
Several security issues were fixed in Mailman.
Software Description:
- mailman: Web-based mailing list manager
Details:
Andre Protas, Richard Cloke, and Andy Nuttall discovered that Mailman
did not properly associate cross-site request forgery (CSRF) tokens
to specific accounts. A remote attacker could use this to perform a
CSRF attack to gain access to another account. (CVE-2021-42097)
Andre Protas, Richard Cloke, and Andy Nuttall discovered that Mailman's
cross-site request forgery (CSRF) tokens for the options page are
derived from the admin password. A remote attacker could possibly use
this to assist in performing a brute force attack against the admin
password. (CVE-2021-42096)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
mailman 1:2.1.26-1ubuntu0.4
Ubuntu 16.04 ESM:
mailman 1:2.1.20-1ubuntu0.6+esm1
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5121-1
CVE-2021-42096, CVE-2021-42097
Package Information:
https://launchpad.net/ubuntu/+source/mailman/1:2.1.26-1ubuntu0.4
Ubuntu Security Notice USN-5121-1
October 22, 2021
mailman vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
Summary:
Several security issues were fixed in Mailman.
Software Description:
- mailman: Web-based mailing list manager
Details:
Andre Protas, Richard Cloke, and Andy Nuttall discovered that Mailman
did not properly associate cross-site request forgery (CSRF) tokens
to specific accounts. A remote attacker could use this to perform a
CSRF attack to gain access to another account. (CVE-2021-42097)
Andre Protas, Richard Cloke, and Andy Nuttall discovered that Mailman's
cross-site request forgery (CSRF) tokens for the options page are
derived from the admin password. A remote attacker could possibly use
this to assist in performing a brute force attack against the admin
password. (CVE-2021-42096)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
mailman 1:2.1.26-1ubuntu0.4
Ubuntu 16.04 ESM:
mailman 1:2.1.20-1ubuntu0.6+esm1
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-5121-1
CVE-2021-42096, CVE-2021-42097
Package Information:
https://launchpad.net/ubuntu/+source/mailman/1:2.1.26-1ubuntu0.4
Thursday, October 21, 2021
[USN-5116-2] Linux kernel vulnerabilities
==========================================================================
Ubuntu Security Notice USN-5116-2
October 22, 2021
linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-gke,
linux-gke-5.4, linux-gkeop, linux-gkeop-5.4, linux-oracle,
linux-oracle-5.4, linux-raspi, linux-raspi-5.4 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in the Linux kernel.
Software Description:
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-azure: Linux kernel for Microsoft Azure Cloud systems
- linux-gke: Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop: Linux kernel for Google Container Engine (GKE) systems
- linux-oracle: Linux kernel for Oracle Cloud systems
- linux-raspi: Linux kernel for Raspberry Pi systems
- linux-aws-5.4: Linux kernel for Amazon Web Services (AWS) systems
- linux-azure-5.4: Linux kernel version specific cloud tools for version 5.4.0-1062
- linux-gke-5.4: Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop-5.4: Linux kernel for Google Container Engine (GKE) systems
- linux-oracle-5.4: Linux kernel for Oracle Cloud systems
- linux-raspi-5.4: Linux kernel for Raspberry Pi systems
Details:
It was discovered that a race condition existed in the Atheros Ath9k WiFi
driver in the Linux kernel. An attacker could possibly use this to expose
sensitive information (WiFi network traffic). (CVE-2020-3702)
Alois Wohlschlager discovered that the overlay file system in the Linux
kernel did not restrict private clones in some situations. An attacker
could use this to expose sensitive information. (CVE-2021-3732)
It was discovered that the KVM hypervisor implementation in the Linux
kernel did not properly compute the access permissions for shadow pages in
some situations. A local attacker could use this to cause a denial of
service. (CVE-2021-38198)
It was discovered that the Xilinx 10/100 Ethernet Lite device driver in the
Linux kernel could report pointer addresses in some situations. An attacker
could use this information to ease the exploitation of another
vulnerability. (CVE-2021-38205)
It was discovered that the ext4 file system in the Linux kernel contained a
race condition when writing xattrs to an inode. A local attacker could use
this to cause a denial of service or possibly gain administrative
privileges. (CVE-2021-40490)
It was discovered that the 6pack network protocol driver in the Linux
kernel did not properly perform validation checks. A privileged attacker
could use this to cause a denial of service (system crash) or execute
arbitrary code. (CVE-2021-42008)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 20.04 LTS:
linux-image-5.4.0-1025-gkeop 5.4.0-1025.26
linux-image-5.4.0-1045-raspi 5.4.0-1045.49
linux-image-5.4.0-1054-gke 5.4.0-1054.57
linux-image-5.4.0-1056-oracle 5.4.0-1056.60
linux-image-5.4.0-1058-aws 5.4.0-1058.61
linux-image-5.4.0-1062-azure 5.4.0-1062.65
linux-image-aws-lts-20.04 5.4.0.1058.61
linux-image-azure-lts-20.04 5.4.0.1062.60
linux-image-gke 5.4.0.1054.64
linux-image-gke-5.4 5.4.0.1054.64
linux-image-gkeop 5.4.0.1025.28
linux-image-gkeop-5.4 5.4.0.1025.28
linux-image-oracle-lts-20.04 5.4.0.1056.56
linux-image-raspi 5.4.0.1045.80
linux-image-raspi2 5.4.0.1045.80
Ubuntu 18.04 LTS:
linux-image-5.4.0-1025-gkeop 5.4.0-1025.26~18.04.1
linux-image-5.4.0-1045-raspi 5.4.0-1045.49~18.04.1
linux-image-5.4.0-1054-gke 5.4.0-1054.57~18.04.1
linux-image-5.4.0-1056-oracle 5.4.0-1056.60~18.04.1
linux-image-5.4.0-1058-aws 5.4.0-1058.61~18.04.3
linux-image-5.4.0-1062-azure 5.4.0-1062.65~18.04.1
linux-image-aws 5.4.0.1058.41
linux-image-azure 5.4.0.1062.42
linux-image-gke-5.4 5.4.0.1054.57~18.04.19
linux-image-gkeop-5.4 5.4.0.1025.26~18.04.26
linux-image-oracle 5.4.0.1056.60~18.04.36
linux-image-raspi-hwe-18.04 5.4.0.1045.48
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://ubuntu.com/security/notices/USN-5116-2
https://ubuntu.com/security/notices/USN-5116-1
CVE-2020-3702, CVE-2021-3732, CVE-2021-38198, CVE-2021-38205,
CVE-2021-40490, CVE-2021-42008
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/5.4.0-1058.61
https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1062.65
https://launchpad.net/ubuntu/+source/linux-gke/5.4.0-1054.57
https://launchpad.net/ubuntu/+source/linux-gkeop/5.4.0-1025.26
https://launchpad.net/ubuntu/+source/linux-oracle/5.4.0-1056.60
https://launchpad.net/ubuntu/+source/linux-raspi/5.4.0-1045.49
https://launchpad.net/ubuntu/+source/linux-aws-5.4/5.4.0-1058.61~18.04.3
https://launchpad.net/ubuntu/+source/linux-azure-5.4/5.4.0-1062.65~18.04.1
https://launchpad.net/ubuntu/+source/linux-gke-5.4/5.4.0-1054.57~18.04.1
https://launchpad.net/ubuntu/+source/linux-gkeop-5.4/5.4.0-1025.26~18.04.1
https://launchpad.net/ubuntu/+source/linux-oracle-5.4/5.4.0-1056.60~18.04.1
https://launchpad.net/ubuntu/+source/linux-raspi-5.4/5.4.0-1045.49~18.04.1
Ubuntu Security Notice USN-5116-2
October 22, 2021
linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-gke,
linux-gke-5.4, linux-gkeop, linux-gkeop-5.4, linux-oracle,
linux-oracle-5.4, linux-raspi, linux-raspi-5.4 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in the Linux kernel.
Software Description:
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-azure: Linux kernel for Microsoft Azure Cloud systems
- linux-gke: Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop: Linux kernel for Google Container Engine (GKE) systems
- linux-oracle: Linux kernel for Oracle Cloud systems
- linux-raspi: Linux kernel for Raspberry Pi systems
- linux-aws-5.4: Linux kernel for Amazon Web Services (AWS) systems
- linux-azure-5.4: Linux kernel version specific cloud tools for version 5.4.0-1062
- linux-gke-5.4: Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop-5.4: Linux kernel for Google Container Engine (GKE) systems
- linux-oracle-5.4: Linux kernel for Oracle Cloud systems
- linux-raspi-5.4: Linux kernel for Raspberry Pi systems
Details:
It was discovered that a race condition existed in the Atheros Ath9k WiFi
driver in the Linux kernel. An attacker could possibly use this to expose
sensitive information (WiFi network traffic). (CVE-2020-3702)
Alois Wohlschlager discovered that the overlay file system in the Linux
kernel did not restrict private clones in some situations. An attacker
could use this to expose sensitive information. (CVE-2021-3732)
It was discovered that the KVM hypervisor implementation in the Linux
kernel did not properly compute the access permissions for shadow pages in
some situations. A local attacker could use this to cause a denial of
service. (CVE-2021-38198)
It was discovered that the Xilinx 10/100 Ethernet Lite device driver in the
Linux kernel could report pointer addresses in some situations. An attacker
could use this information to ease the exploitation of another
vulnerability. (CVE-2021-38205)
It was discovered that the ext4 file system in the Linux kernel contained a
race condition when writing xattrs to an inode. A local attacker could use
this to cause a denial of service or possibly gain administrative
privileges. (CVE-2021-40490)
It was discovered that the 6pack network protocol driver in the Linux
kernel did not properly perform validation checks. A privileged attacker
could use this to cause a denial of service (system crash) or execute
arbitrary code. (CVE-2021-42008)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 20.04 LTS:
linux-image-5.4.0-1025-gkeop 5.4.0-1025.26
linux-image-5.4.0-1045-raspi 5.4.0-1045.49
linux-image-5.4.0-1054-gke 5.4.0-1054.57
linux-image-5.4.0-1056-oracle 5.4.0-1056.60
linux-image-5.4.0-1058-aws 5.4.0-1058.61
linux-image-5.4.0-1062-azure 5.4.0-1062.65
linux-image-aws-lts-20.04 5.4.0.1058.61
linux-image-azure-lts-20.04 5.4.0.1062.60
linux-image-gke 5.4.0.1054.64
linux-image-gke-5.4 5.4.0.1054.64
linux-image-gkeop 5.4.0.1025.28
linux-image-gkeop-5.4 5.4.0.1025.28
linux-image-oracle-lts-20.04 5.4.0.1056.56
linux-image-raspi 5.4.0.1045.80
linux-image-raspi2 5.4.0.1045.80
Ubuntu 18.04 LTS:
linux-image-5.4.0-1025-gkeop 5.4.0-1025.26~18.04.1
linux-image-5.4.0-1045-raspi 5.4.0-1045.49~18.04.1
linux-image-5.4.0-1054-gke 5.4.0-1054.57~18.04.1
linux-image-5.4.0-1056-oracle 5.4.0-1056.60~18.04.1
linux-image-5.4.0-1058-aws 5.4.0-1058.61~18.04.3
linux-image-5.4.0-1062-azure 5.4.0-1062.65~18.04.1
linux-image-aws 5.4.0.1058.41
linux-image-azure 5.4.0.1062.42
linux-image-gke-5.4 5.4.0.1054.57~18.04.19
linux-image-gkeop-5.4 5.4.0.1025.26~18.04.26
linux-image-oracle 5.4.0.1056.60~18.04.36
linux-image-raspi-hwe-18.04 5.4.0.1045.48
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://ubuntu.com/security/notices/USN-5116-2
https://ubuntu.com/security/notices/USN-5116-1
CVE-2020-3702, CVE-2021-3732, CVE-2021-38198, CVE-2021-38205,
CVE-2021-40490, CVE-2021-42008
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/5.4.0-1058.61
https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1062.65
https://launchpad.net/ubuntu/+source/linux-gke/5.4.0-1054.57
https://launchpad.net/ubuntu/+source/linux-gkeop/5.4.0-1025.26
https://launchpad.net/ubuntu/+source/linux-oracle/5.4.0-1056.60
https://launchpad.net/ubuntu/+source/linux-raspi/5.4.0-1045.49
https://launchpad.net/ubuntu/+source/linux-aws-5.4/5.4.0-1058.61~18.04.3
https://launchpad.net/ubuntu/+source/linux-azure-5.4/5.4.0-1062.65~18.04.1
https://launchpad.net/ubuntu/+source/linux-gke-5.4/5.4.0-1054.57~18.04.1
https://launchpad.net/ubuntu/+source/linux-gkeop-5.4/5.4.0-1025.26~18.04.1
https://launchpad.net/ubuntu/+source/linux-oracle-5.4/5.4.0-1056.60~18.04.1
https://launchpad.net/ubuntu/+source/linux-raspi-5.4/5.4.0-1045.49~18.04.1
Subscribe to:
Posts (Atom)