{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.4.0-190", "linux-headers-5.4.0-190-generic", "linux-image-5.4.0-190-generic", "linux-modules-5.4.0-190-generic" ], "removed": [ "linux-headers-5.4.0-189", "linux-headers-5.4.0-189-generic", "linux-image-5.4.0-189-generic", "linux-modules-5.4.0-189-generic" ], "diff": [ "bind9-dnsutils", "bind9-host", "bind9-libs", "landscape-common", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-virtual", "python3-zipp" ] } }, "diff": { "deb": [ { "name": "bind9-dnsutils", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.16.48-0ubuntu0.20.04.1", "version": "1:9.16.48-0ubuntu0.20.04.1" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.28-0ubuntu0.20.04.1", "version": "1:9.18.28-0ubuntu0.20.04.1" }, "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "log": [ "", " * Updated to 9.18.28 to fix multiple security issues.", " - Please see the following for a list of changes, including possibly", " incompatible ones:", " https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918", " - CVE-2024-0760: A flood of DNS messages over TCP may make the server", " unstable", " - CVE-2024-1737: BIND's database will be slow if a very large number of", " RRs exist at the same name", " - CVE-2024-1975: SIG(0) can be used to exhaust CPU resources", " - CVE-2024-4076: Assertion failure when serving both stale cache data", " and authoritative zone content", " * Packaging changes required for 9.18.28:", " - Dropped patches no longer required with 9.18.28:", " + 0001-Add_--install-layout=deb_to_setup.py_call.patch", " + 0002-python-fix-for-dist-packages.patch", " + 0003-Remove-the-reference-to-OPTIONS.md-it-breaks-build-o.patch", " - Synced patch with jammy's 1:9.18.28-0ubuntu0.22.04.1 package:", " + always-use-standard-library-stdatomic.patch", " - debian/NEWS: list changes in 9.18, taken from jammy.", " - debian/*: sync most of the packaging with jammy's package, including", " autopkgtests except for dyndb-ldap as the bind-dyndb-ldap package is", " broken in focal.", " - debian/tests/simpletest: wait a couple of seconds for the service to", " actually start.", "" ], "package": "bind9", "version": "1:9.18.28-0ubuntu0.20.04.1", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 16 Jul 2024 14:48:12 -0400" } ], "notes": null }, { "name": "bind9-host", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.16.48-0ubuntu0.20.04.1", "version": "1:9.16.48-0ubuntu0.20.04.1" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.28-0ubuntu0.20.04.1", "version": "1:9.18.28-0ubuntu0.20.04.1" }, "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "log": [ "", " * Updated to 9.18.28 to fix multiple security issues.", " - Please see the following for a list of changes, including possibly", " incompatible ones:", " https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918", " - CVE-2024-0760: A flood of DNS messages over TCP may make the server", " unstable", " - CVE-2024-1737: BIND's database will be slow if a very large number of", " RRs exist at the same name", " - CVE-2024-1975: SIG(0) can be used to exhaust CPU resources", " - CVE-2024-4076: Assertion failure when serving both stale cache data", " and authoritative zone content", " * Packaging changes required for 9.18.28:", " - Dropped patches no longer required with 9.18.28:", " + 0001-Add_--install-layout=deb_to_setup.py_call.patch", " + 0002-python-fix-for-dist-packages.patch", " + 0003-Remove-the-reference-to-OPTIONS.md-it-breaks-build-o.patch", " - Synced patch with jammy's 1:9.18.28-0ubuntu0.22.04.1 package:", " + always-use-standard-library-stdatomic.patch", " - debian/NEWS: list changes in 9.18, taken from jammy.", " - debian/*: sync most of the packaging with jammy's package, including", " autopkgtests except for dyndb-ldap as the bind-dyndb-ldap package is", " broken in focal.", " - debian/tests/simpletest: wait a couple of seconds for the service to", " actually start.", "" ], "package": "bind9", "version": "1:9.18.28-0ubuntu0.20.04.1", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 16 Jul 2024 14:48:12 -0400" } ], "notes": null }, { "name": "bind9-libs", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.16.48-0ubuntu0.20.04.1", "version": "1:9.16.48-0ubuntu0.20.04.1" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.28-0ubuntu0.20.04.1", "version": "1:9.18.28-0ubuntu0.20.04.1" }, "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-0760", "url": "https://ubuntu.com/security/CVE-2024-0760", "cve_description": "A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1737", "url": "https://ubuntu.com/security/CVE-2024-1737", "cve_description": "Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-1975", "url": "https://ubuntu.com/security/CVE-2024-1975", "cve_description": "If a server hosts a zone containing a \"KEY\" Resource Record, or a resolver DNSSEC-validates a \"KEY\" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" }, { "cve": "CVE-2024-4076", "url": "https://ubuntu.com/security/CVE-2024-4076", "cve_description": "Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.", "cve_priority": "medium", "cve_public_date": "2024-07-23 15:15:00 UTC" } ], "log": [ "", " * Updated to 9.18.28 to fix multiple security issues.", " - Please see the following for a list of changes, including possibly", " incompatible ones:", " https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918", " - CVE-2024-0760: A flood of DNS messages over TCP may make the server", " unstable", " - CVE-2024-1737: BIND's database will be slow if a very large number of", " RRs exist at the same name", " - CVE-2024-1975: SIG(0) can be used to exhaust CPU resources", " - CVE-2024-4076: Assertion failure when serving both stale cache data", " and authoritative zone content", " * Packaging changes required for 9.18.28:", " - Dropped patches no longer required with 9.18.28:", " + 0001-Add_--install-layout=deb_to_setup.py_call.patch", " + 0002-python-fix-for-dist-packages.patch", " + 0003-Remove-the-reference-to-OPTIONS.md-it-breaks-build-o.patch", " - Synced patch with jammy's 1:9.18.28-0ubuntu0.22.04.1 package:", " + always-use-standard-library-stdatomic.patch", " - debian/NEWS: list changes in 9.18, taken from jammy.", " - debian/*: sync most of the packaging with jammy's package, including", " autopkgtests except for dyndb-ldap as the bind-dyndb-ldap package is", " broken in focal.", " - debian/tests/simpletest: wait a couple of seconds for the service to", " actually start.", "" ], "package": "bind9", "version": "1:9.18.28-0ubuntu0.20.04.1", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 16 Jul 2024 14:48:12 -0400" } ], "notes": null }, { "name": "landscape-common", "from_version": { "source_package_name": "landscape-client", "source_package_version": "23.02-0ubuntu1~20.04.2", "version": "23.02-0ubuntu1~20.04.2" }, "to_version": { "source_package_name": "landscape-client", "source_package_version": "23.02-0ubuntu1~20.04.3", "version": "23.02-0ubuntu1~20.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2066983 ], "changes": [ { "cves": [], "log": [ "", " * d/landscape-sysinfo.wrapper: fix 'cores' variable to CORES in message-", " of-the-day load threshold calculation (LP: #2066983)", "" ], "package": "landscape-client", "version": "23.02-0ubuntu1~20.04.3", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2066983 ], "author": "Spencer Runde ", "date": "Tue, 28 May 2024 14:19:00 -0500" } ], "notes": null }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.189.187", "version": "5.4.0.189.187" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.190.188", "version": "5.4.0.190.188" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-190", "" ], "package": "linux-meta", "version": "5.4.0.190.188", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:28:48 +0200" } ], "notes": null }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.189.187", "version": "5.4.0.189.187" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.190.188", "version": "5.4.0.190.188" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-190", "" ], "package": "linux-meta", "version": "5.4.0.190.188", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:28:48 +0200" } ], "notes": null }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.189.187", "version": "5.4.0.189.187" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.190.188", "version": "5.4.0.190.188" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-190", "" ], "package": "linux-meta", "version": "5.4.0.190.188", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:28:48 +0200" } ], "notes": null }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.189.187", "version": "5.4.0.189.187" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.190.188", "version": "5.4.0.190.188" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-190", "" ], "package": "linux-meta", "version": "5.4.0.190.188", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:28:48 +0200" } ], "notes": null }, { "name": "python3-zipp", "from_version": { "source_package_name": "python-zipp", "source_package_version": "1.0.0-1", "version": "1.0.0-1" }, "to_version": { "source_package_name": "python-zipp", "source_package_version": "1.0.0-1ubuntu0.1", "version": "1.0.0-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-5569", "url": "https://ubuntu.com/security/CVE-2024-5569", "cve_description": "A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.", "cve_priority": "medium", "cve_public_date": "2024-07-09 00:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-5569", "url": "https://ubuntu.com/security/CVE-2024-5569", "cve_description": "A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.", "cve_priority": "medium", "cve_public_date": "2024-07-09 00:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: denial of service vulnerability", " - debian/patches/CVE-2024-5569.patch: Sanitize malformed paths", " - CVE-2024-5569", "" ], "package": "python-zipp", "version": "1.0.0-1ubuntu0.1", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Shishir Subedi ", "date": "Sun, 21 Jul 2024 20:13:09 +0545" } ], "notes": null } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.4.0-190", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-190.210", "version": "5.4.0-190.210" }, "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2072108 ], "changes": [ { "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-190.210 -proposed tracker (LP: #2072108)", "", " * CVE-2024-36016", " - tty: n_gsm: fix possible out-of-bounds in gsm0_receive()", "", " * CVE-2022-48655", " - firmware: arm_scmi: Harden accesses to the reset domains", "", " * CVE-2024-26907", " - RDMA/mlx5: Fix fortify source warning while accessing Eth segment", "", " * CVE-2024-26585", " - tls: fix race between tx work scheduling and socket close", "", " * CVE-2024-26584", " - net: tls: handle backlogging of crypto requests", "", " * CVE-2024-26583", " - net/tls: Replace TLS_RX_SYNC_RUNNING with RCU", " - net/tls: Fix use-after-free after the TLS device goes down and up", " - tls: splice_read: fix record type check", " - tls splice: remove inappropriate flags checking for MSG_PEEK", " - tls: splice_read: fix accessing pre-processed records", " - tls: Fix context leak on tls_device_down", " - net/tls: Check for errors in tls_device_init", " - net/tls: Remove the context from the list in tls_device_down", " - net/tls: pass context to tls_device_decrypted()", " - net/tls: Perform immediate device ctx cleanup when possible", " - net/tls: Multi-threaded calls to TX tls_dev_del", " - net: tls: avoid discarding data on record close", " - tls: rx: don't store the record type in socket context", " - tls: rx: don't store the decryption status in socket context", " - tls: rx: don't issue wake ups when data is decrypted", " - tls: rx: refactor decrypt_skb_update()", " - tls: hw: rx: use return value of tls_device_decrypted() to carry status", " - tls: rx: drop unnecessary arguments from tls_setup_from_iter()", " - tls: rx: don't report text length from the bowels of decrypt", " - tls: rx: wrap decryption arguments in a structure", " - tls: rx: factor out writing ContentType to cmsg", " - tls: rx: don't track the async count", " - tls: rx: assume crypto always calls our callback", " - tls: rx: use async as an in-out argument", " - tls: decrement decrypt_pending if no async completion will be called", " - net: tls: fix async vs NIC crypto offload", " - tls: rx: simplify async wait", " - tls: extract context alloc/initialization out of tls_set_sw_offload", " - net: tls: factor out tls_*crypt_async_wait()", " - tls: fix race between async notify and socket close", "" ], "package": "linux", "version": "5.4.0-190.210", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2072108 ], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:04:36 +0200" } ], "notes": "linux-headers-5.4.0-190 version '5.4.0-190.210' (source package linux version '5.4.0-190.210') was added. linux-headers-5.4.0-190 version '5.4.0-190.210' has the same source package name, linux, as removed package linux-headers-5.4.0-189. As such we can use the source package version of the removed package, '5.4.0-189.209', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-headers-5.4.0-190-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-190.210", "version": "5.4.0-190.210" }, "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2072108 ], "changes": [ { "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-190.210 -proposed tracker (LP: #2072108)", "", " * CVE-2024-36016", " - tty: n_gsm: fix possible out-of-bounds in gsm0_receive()", "", " * CVE-2022-48655", " - firmware: arm_scmi: Harden accesses to the reset domains", "", " * CVE-2024-26907", " - RDMA/mlx5: Fix fortify source warning while accessing Eth segment", "", " * CVE-2024-26585", " - tls: fix race between tx work scheduling and socket close", "", " * CVE-2024-26584", " - net: tls: handle backlogging of crypto requests", "", " * CVE-2024-26583", " - net/tls: Replace TLS_RX_SYNC_RUNNING with RCU", " - net/tls: Fix use-after-free after the TLS device goes down and up", " - tls: splice_read: fix record type check", " - tls splice: remove inappropriate flags checking for MSG_PEEK", " - tls: splice_read: fix accessing pre-processed records", " - tls: Fix context leak on tls_device_down", " - net/tls: Check for errors in tls_device_init", " - net/tls: Remove the context from the list in tls_device_down", " - net/tls: pass context to tls_device_decrypted()", " - net/tls: Perform immediate device ctx cleanup when possible", " - net/tls: Multi-threaded calls to TX tls_dev_del", " - net: tls: avoid discarding data on record close", " - tls: rx: don't store the record type in socket context", " - tls: rx: don't store the decryption status in socket context", " - tls: rx: don't issue wake ups when data is decrypted", " - tls: rx: refactor decrypt_skb_update()", " - tls: hw: rx: use return value of tls_device_decrypted() to carry status", " - tls: rx: drop unnecessary arguments from tls_setup_from_iter()", " - tls: rx: don't report text length from the bowels of decrypt", " - tls: rx: wrap decryption arguments in a structure", " - tls: rx: factor out writing ContentType to cmsg", " - tls: rx: don't track the async count", " - tls: rx: assume crypto always calls our callback", " - tls: rx: use async as an in-out argument", " - tls: decrement decrypt_pending if no async completion will be called", " - net: tls: fix async vs NIC crypto offload", " - tls: rx: simplify async wait", " - tls: extract context alloc/initialization out of tls_set_sw_offload", " - net: tls: factor out tls_*crypt_async_wait()", " - tls: fix race between async notify and socket close", "" ], "package": "linux", "version": "5.4.0-190.210", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2072108 ], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:04:36 +0200" } ], "notes": "linux-headers-5.4.0-190-generic version '5.4.0-190.210' (source package linux version '5.4.0-190.210') was added. linux-headers-5.4.0-190-generic version '5.4.0-190.210' has the same source package name, linux, as removed package linux-headers-5.4.0-189. As such we can use the source package version of the removed package, '5.4.0-189.209', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-image-5.4.0-190-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.4.0-189.209", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "5.4.0-190.210", "version": "5.4.0-190.210" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.4.0-190.210", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "5.4.0-190.210", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:29:03 +0200" } ], "notes": "linux-image-5.4.0-190-generic version '5.4.0-190.210' (source package linux-signed version '5.4.0-190.210') was added. linux-image-5.4.0-190-generic version '5.4.0-190.210' has the same source package name, linux-signed, as removed package linux-image-5.4.0-189-generic. As such we can use the source package version of the removed package, '5.4.0-189.209', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-modules-5.4.0-190-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-190.210", "version": "5.4.0-190.210" }, "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2072108 ], "changes": [ { "cves": [ { "cve": "CVE-2024-36016", "url": "https://ubuntu.com/security/CVE-2024-36016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.", "cve_priority": "high", "cve_public_date": "2024-05-29 19:15:00 UTC" }, { "cve": "CVE-2022-48655", "url": "https://ubuntu.com/security/CVE-2022-48655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.", "cve_priority": "medium", "cve_public_date": "2024-04-28 13:15:00 UTC" }, { "cve": "CVE-2024-26907", "url": "https://ubuntu.com/security/CVE-2024-26907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-04-17 11:15:00 UTC" }, { "cve": "CVE-2024-26585", "url": "https://ubuntu.com/security/CVE-2024-26585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26584", "url": "https://ubuntu.com/security/CVE-2024-26584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" }, { "cve": "CVE-2024-26583", "url": "https://ubuntu.com/security/CVE-2024-26583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.", "cve_priority": "high", "cve_public_date": "2024-02-21 15:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-190.210 -proposed tracker (LP: #2072108)", "", " * CVE-2024-36016", " - tty: n_gsm: fix possible out-of-bounds in gsm0_receive()", "", " * CVE-2022-48655", " - firmware: arm_scmi: Harden accesses to the reset domains", "", " * CVE-2024-26907", " - RDMA/mlx5: Fix fortify source warning while accessing Eth segment", "", " * CVE-2024-26585", " - tls: fix race between tx work scheduling and socket close", "", " * CVE-2024-26584", " - net: tls: handle backlogging of crypto requests", "", " * CVE-2024-26583", " - net/tls: Replace TLS_RX_SYNC_RUNNING with RCU", " - net/tls: Fix use-after-free after the TLS device goes down and up", " - tls: splice_read: fix record type check", " - tls splice: remove inappropriate flags checking for MSG_PEEK", " - tls: splice_read: fix accessing pre-processed records", " - tls: Fix context leak on tls_device_down", " - net/tls: Check for errors in tls_device_init", " - net/tls: Remove the context from the list in tls_device_down", " - net/tls: pass context to tls_device_decrypted()", " - net/tls: Perform immediate device ctx cleanup when possible", " - net/tls: Multi-threaded calls to TX tls_dev_del", " - net: tls: avoid discarding data on record close", " - tls: rx: don't store the record type in socket context", " - tls: rx: don't store the decryption status in socket context", " - tls: rx: don't issue wake ups when data is decrypted", " - tls: rx: refactor decrypt_skb_update()", " - tls: hw: rx: use return value of tls_device_decrypted() to carry status", " - tls: rx: drop unnecessary arguments from tls_setup_from_iter()", " - tls: rx: don't report text length from the bowels of decrypt", " - tls: rx: wrap decryption arguments in a structure", " - tls: rx: factor out writing ContentType to cmsg", " - tls: rx: don't track the async count", " - tls: rx: assume crypto always calls our callback", " - tls: rx: use async as an in-out argument", " - tls: decrement decrypt_pending if no async completion will be called", " - net: tls: fix async vs NIC crypto offload", " - tls: rx: simplify async wait", " - tls: extract context alloc/initialization out of tls_set_sw_offload", " - net: tls: factor out tls_*crypt_async_wait()", " - tls: fix race between async notify and socket close", "" ], "package": "linux", "version": "5.4.0-190.210", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2072108 ], "author": "Manuel Diewald ", "date": "Fri, 05 Jul 2024 17:04:36 +0200" } ], "notes": "linux-modules-5.4.0-190-generic version '5.4.0-190.210' (source package linux version '5.4.0-190.210') was added. linux-modules-5.4.0-190-generic version '5.4.0-190.210' has the same source package name, linux, as removed package linux-headers-5.4.0-189. As such we can use the source package version of the removed package, '5.4.0-189.209', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.4.0-189", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": "5.4.0-189.209" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-headers-5.4.0-189-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": "5.4.0-189.209" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-5.4.0-189-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.4.0-189.209", "version": "5.4.0-189.209" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-5.4.0-189-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-189.209", "version": "5.4.0-189.209" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 20.04 focal image from release image serial 20240710 to 20240725", "from_series": "focal", "to_series": "focal", "from_serial": "20240710", "to_serial": "20240725", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }