{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-6.8.0-45", "linux-headers-6.8.0-45-generic", "linux-image-6.8.0-45-generic", "linux-modules-6.8.0-45-generic", "linux-tools-6.8.0-45", "linux-tools-6.8.0-45-generic" ], "removed": [ "linux-headers-6.8.0-44", "linux-headers-6.8.0-44-generic", "linux-image-6.8.0-44-generic", "linux-modules-6.8.0-44-generic", "linux-tools-6.8.0-44", "linux-tools-6.8.0-44-generic" ], "diff": [ "apparmor", "cloud-init", "curl", "flash-kernel", "libapparmor1:armhf", "libcurl3t64-gnutls:armhf", "libcurl4t64:armhf", "libproc2-0:armhf", "libpython3.12-minimal:armhf", "libpython3.12-stdlib:armhf", "libpython3.12t64:armhf", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:armhf", "linux-tools-common", "linux-virtual", "lxd-agent-loader", "mdadm", "procps", "python3-pkg-resources", "python3-setuptools", "python3-update-manager", "python3.12", "python3.12-minimal", "systemd-hwe-hwdb", "u-boot-tools", "ubuntu-pro-client", "ubuntu-pro-client-l10n", "update-manager-core", "vim", "vim-common", "vim-runtime", "vim-tiny", "xxd" ] } }, "diff": { "deb": [ { "name": "apparmor", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.0-beta3-0ubuntu0.1", "version": "4.0.1really4.0.0-beta3-0ubuntu0.1" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.3", "version": "4.0.1really4.0.1-0ubuntu0.24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2072811, 2064672, 2046844, 2060100, 2056297, 2046844 ], "changes": [ { "cves": [], "log": [ "", " * Revert to version 4.0.1-0ubuntu0.24.04.2 except for the patch", " that enables the bwrap-userns-restrict profile (LP: #2072811).", " * New upstream release.", " (LP: #2064672, LP: #2046844, LP: #2060100, LP: #2056297)", " * Drop patches which have now been applied upstream", " - d/p/u/parser-fix-issues-appointed-by-coverity.patch", " - d/p/u/profiles-add-unconfined-profile-for-tuxedo-control-c.patch", " - d/p/u/parser-support-uin128_t-key-as-a-pair-of-uint64_t-nu.patch", " - d/p/u/Minor-improvements-for-MountRule.patch", " * Add patch to add balena-etcher profile (LP: #2046844)", " - d/p/u/profiles-add-unconfined-balena-etcher-profile.patch", " * Add upstream patch to relax mount rules to fix use of virtiofs and", " other file-system types", " - d/p/u/mountrule-relaxing-constraints-on-fstype.patch", " * Refresh", " - d/p/u/samba-systemd-interaction.patch", " - d/p/u/parser-add-support-for-prompting.patch", " - Add condition in policydb serialization to only encode xtable if", " kernel_supports_permstable32", " * Fix d/p/u/userns-runtime-disable.patch to work when", " kernel.apparmor_restrict_unprivileged_userns does not exist by adding", " -e to sysctl.", " * d/apparmor-profiles.install", " - install new profile", " - unshare-userns-restrict", " - bwrap-userns-restrict", " * d/apparmor.install", " - install new profiles", " - wike - changed installation from apparmor to apparmor.d", " - foliate", " - balena-etcher", " - transmission", " * d/control: Remove obsolete lsb-base Depends and swap pkg-config to", " pkgconf for Build-Depends", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2072811, 2064672, 2046844, 2060100, 2056297, 2046844 ], "author": "Georgia Garcia ", "date": "Thu, 18 Jul 2024 15:28:46 -0300" } ], "notes": null }, { "name": "cloud-init", "from_version": { "source_package_name": "cloud-init", "source_package_version": "24.2-0ubuntu1~24.04.2", "version": "24.2-0ubuntu1~24.04.2" }, "to_version": { "source_package_name": "cloud-init", "source_package_version": "24.3.1-0ubuntu0~24.04.2", "version": "24.3.1-0ubuntu0~24.04.2" }, "cves": [], "launchpad_bugs_fixed": [ 2081124, 2079224 ], "changes": [ { "cves": [], "log": [ "", " * Bug fix release (LP: #2081124):", " d/p/cpick-hotplugd-systemd-ordering-fix.patch: fix systemd ordering cycle", " issues with network cloud-init-hotplugd.socket, NetworkManager and", " dbus.socket by adding DefaultDependencies=no to cloud-init-hotplugd.socket.", "" ], "package": "cloud-init", "version": "24.3.1-0ubuntu0~24.04.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2081124 ], "author": "Chad Smith ", "date": "Fri, 20 Sep 2024 16:07:14 -0600" }, { "cves": [], "log": [ "", " * d/p/no-single-process.patch: Remove single process optimization", " * d/p/no-nocloud-network.patch: Remove nocloud network feature", " * Upstream snapshot based on upstream/main at acf04d61.", " * Upstream snapshot based on 24.3.1. (LP: #2079224).", " List of changes from upstream can be found at", " https://raw.githubusercontent.com/canonical/cloud-init/24.3.1/ChangeLog", "" ], "package": "cloud-init", "version": "24.3.1-0ubuntu0~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2079224 ], "author": "Chad Smith ", "date": "Thu, 05 Sep 2024 12:30:45 -0600" } ], "notes": null }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.3", "version": "8.5.0-2ubuntu10.3" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.4", "version": "8.5.0-2ubuntu10.4" }, "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OCSP stapling bypass with GnuTLS", " - debian/patches/CVE-2024-8096.patch: fix OCSP stapling management in", " lib/vtls/gtls.c.", " - CVE-2024-8096", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 06 Sep 2024 07:27:11 -0400" } ], "notes": null }, { "name": "flash-kernel", "from_version": { "source_package_name": "flash-kernel", "source_package_version": "3.107ubuntu9~24.04.1", "version": "3.107ubuntu9~24.04.1" }, "to_version": { "source_package_name": "flash-kernel", "source_package_version": "3.107ubuntu9~24.04.3", "version": "3.107ubuntu9~24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2078525, 2065380 ], "changes": [ { "cves": [], "log": [ "", " * Add dtb-probe script to handle missing bcm2710-rpi-zero-2-w.dtb in some of", " the 5.15 series kernels (LP: #2078525)", "" ], "package": "flash-kernel", "version": "3.107ubuntu9~24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078525 ], "author": "Dave Jones ", "date": "Tue, 10 Sep 2024 16:32:47 +0100" }, { "cves": [], "log": [ "", " * db/all.db: Support for Qualcomm x1e80100 CRD board (LP: #2065380)", "" ], "package": "flash-kernel", "version": "3.107ubuntu9~24.04.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2065380 ], "author": "Ike Panhc ", "date": "Mon, 22 Jul 2024 16:46:49 +0800" } ], "notes": null }, { "name": "libapparmor1:armhf", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.0-beta3-0ubuntu0.1", "version": "4.0.1really4.0.0-beta3-0ubuntu0.1" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.3", "version": "4.0.1really4.0.1-0ubuntu0.24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2072811, 2064672, 2046844, 2060100, 2056297, 2046844 ], "changes": [ { "cves": [], "log": [ "", " * Revert to version 4.0.1-0ubuntu0.24.04.2 except for the patch", " that enables the bwrap-userns-restrict profile (LP: #2072811).", " * New upstream release.", " (LP: #2064672, LP: #2046844, LP: #2060100, LP: #2056297)", " * Drop patches which have now been applied upstream", " - d/p/u/parser-fix-issues-appointed-by-coverity.patch", " - d/p/u/profiles-add-unconfined-profile-for-tuxedo-control-c.patch", " - d/p/u/parser-support-uin128_t-key-as-a-pair-of-uint64_t-nu.patch", " - d/p/u/Minor-improvements-for-MountRule.patch", " * Add patch to add balena-etcher profile (LP: #2046844)", " - d/p/u/profiles-add-unconfined-balena-etcher-profile.patch", " * Add upstream patch to relax mount rules to fix use of virtiofs and", " other file-system types", " - d/p/u/mountrule-relaxing-constraints-on-fstype.patch", " * Refresh", " - d/p/u/samba-systemd-interaction.patch", " - d/p/u/parser-add-support-for-prompting.patch", " - Add condition in policydb serialization to only encode xtable if", " kernel_supports_permstable32", " * Fix d/p/u/userns-runtime-disable.patch to work when", " kernel.apparmor_restrict_unprivileged_userns does not exist by adding", " -e to sysctl.", " * d/apparmor-profiles.install", " - install new profile", " - unshare-userns-restrict", " - bwrap-userns-restrict", " * d/apparmor.install", " - install new profiles", " - wike - changed installation from apparmor to apparmor.d", " - foliate", " - balena-etcher", " - transmission", " * d/control: Remove obsolete lsb-base Depends and swap pkg-config to", " pkgconf for Build-Depends", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2072811, 2064672, 2046844, 2060100, 2056297, 2046844 ], "author": "Georgia Garcia ", "date": "Thu, 18 Jul 2024 15:28:46 -0300" } ], "notes": null }, { "name": "libcurl3t64-gnutls:armhf", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.3", "version": "8.5.0-2ubuntu10.3" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.4", "version": "8.5.0-2ubuntu10.4" }, "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OCSP stapling bypass with GnuTLS", " - debian/patches/CVE-2024-8096.patch: fix OCSP stapling management in", " lib/vtls/gtls.c.", " - CVE-2024-8096", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 06 Sep 2024 07:27:11 -0400" } ], "notes": null }, { "name": "libcurl4t64:armhf", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.3", "version": "8.5.0-2ubuntu10.3" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.4", "version": "8.5.0-2ubuntu10.4" }, "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-8096", "url": "https://ubuntu.com/security/CVE-2024-8096", "cve_description": "When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.", "cve_priority": "medium", "cve_public_date": "2024-09-11 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OCSP stapling bypass with GnuTLS", " - debian/patches/CVE-2024-8096.patch: fix OCSP stapling management in", " lib/vtls/gtls.c.", " - CVE-2024-8096", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 06 Sep 2024 07:27:11 -0400" } ], "notes": null }, { "name": "libproc2-0:armhf", "from_version": { "source_package_name": "procps", "source_package_version": "2:4.0.4-4ubuntu3", "version": "2:4.0.4-4ubuntu3" }, "to_version": { "source_package_name": "procps", "source_package_version": "2:4.0.4-4ubuntu3.1", "version": "2:4.0.4-4ubuntu3.1" }, "cves": [], "launchpad_bugs_fixed": [ 2003027 ], "changes": [ { "cves": [], "log": [ "", " * d/sysctl.d/10-bufferbloat.conf: set default qdisc to fq_codel (LP: #2003027)", "" ], "package": "procps", "version": "2:4.0.4-4ubuntu3.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2003027 ], "author": "Heitor Alves de Siqueira ", "date": "Wed, 17 Jul 2024 14:59:18 +0000" } ], "notes": null }, { "name": "libpython3.12-minimal:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.1", "version": "3.12.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.2", "version": "3.12.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: incorrect special character parsing in email module", " - debian/patches/CVE-2023-27043.patch: reject malformed addresses in", " Doc/library/email.utils.rst, Lib/email/utils.py,", " Lib/test/test_email/test_email.py.", " - CVE-2023-27043", " * SECURITY UPDATE: ReDoS via specifically-crafted tar archives", " - debian/patches/CVE-2024-6232.patch: remove backtracking when parsing", " tarfile headers in Lib/tarfile.py, Lib/test/test_tarfile.py.", " - CVE-2024-6232", " * SECURITY UPDATE: header injection via newlines in email module", " - debian/patches/CVE-2024-6923.patch: encode newlines in headers, and", " verify headers are sound in Doc/library/email.errors.rst,", " Doc/library/email.policy.rst, Lib/email/_header_value_parser.py,", " Lib/email/_policybase.py, Lib/email/errors.py,", " Lib/email/generator.py, Lib/test/test_email/test_generator.py,", " Lib/test/test_email/test_policy.py.", " - CVE-2024-6923", " * SECURITY UPDATE: resource consumption via cookie parsing", " - debian/patches/CVE-2024-7592.patch: fix quadratic complexity in", " parsing quoted cookie values with backslashes in Lib/http/cookies.py,", " Lib/test/test_http_cookies.py.", " - CVE-2024-7592", " * SECURITY UPDATE: infinite loop via crafted zip archive", " - debian/patches/CVE-2024-8088-1.patch: sanitize names in zipfile.Path", " in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - debian/patches/CVE-2024-8088-2.patch: replaced SanitizedNames with a", " more surgical fix in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - CVE-2024-8088", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 10:17:37 -0400" } ], "notes": null }, { "name": "libpython3.12-stdlib:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.1", "version": "3.12.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.2", "version": "3.12.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: incorrect special character parsing in email module", " - debian/patches/CVE-2023-27043.patch: reject malformed addresses in", " Doc/library/email.utils.rst, Lib/email/utils.py,", " Lib/test/test_email/test_email.py.", " - CVE-2023-27043", " * SECURITY UPDATE: ReDoS via specifically-crafted tar archives", " - debian/patches/CVE-2024-6232.patch: remove backtracking when parsing", " tarfile headers in Lib/tarfile.py, Lib/test/test_tarfile.py.", " - CVE-2024-6232", " * SECURITY UPDATE: header injection via newlines in email module", " - debian/patches/CVE-2024-6923.patch: encode newlines in headers, and", " verify headers are sound in Doc/library/email.errors.rst,", " Doc/library/email.policy.rst, Lib/email/_header_value_parser.py,", " Lib/email/_policybase.py, Lib/email/errors.py,", " Lib/email/generator.py, Lib/test/test_email/test_generator.py,", " Lib/test/test_email/test_policy.py.", " - CVE-2024-6923", " * SECURITY UPDATE: resource consumption via cookie parsing", " - debian/patches/CVE-2024-7592.patch: fix quadratic complexity in", " parsing quoted cookie values with backslashes in Lib/http/cookies.py,", " Lib/test/test_http_cookies.py.", " - CVE-2024-7592", " * SECURITY UPDATE: infinite loop via crafted zip archive", " - debian/patches/CVE-2024-8088-1.patch: sanitize names in zipfile.Path", " in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - debian/patches/CVE-2024-8088-2.patch: replaced SanitizedNames with a", " more surgical fix in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - CVE-2024-8088", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 10:17:37 -0400" } ], "notes": null }, { "name": "libpython3.12t64:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.1", "version": "3.12.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.2", "version": "3.12.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: incorrect special character parsing in email module", " - debian/patches/CVE-2023-27043.patch: reject malformed addresses in", " Doc/library/email.utils.rst, Lib/email/utils.py,", " Lib/test/test_email/test_email.py.", " - CVE-2023-27043", " * SECURITY UPDATE: ReDoS via specifically-crafted tar archives", " - debian/patches/CVE-2024-6232.patch: remove backtracking when parsing", " tarfile headers in Lib/tarfile.py, Lib/test/test_tarfile.py.", " - CVE-2024-6232", " * SECURITY UPDATE: header injection via newlines in email module", " - debian/patches/CVE-2024-6923.patch: encode newlines in headers, and", " verify headers are sound in Doc/library/email.errors.rst,", " Doc/library/email.policy.rst, Lib/email/_header_value_parser.py,", " Lib/email/_policybase.py, Lib/email/errors.py,", " Lib/email/generator.py, Lib/test/test_email/test_generator.py,", " Lib/test/test_email/test_policy.py.", " - CVE-2024-6923", " * SECURITY UPDATE: resource consumption via cookie parsing", " - debian/patches/CVE-2024-7592.patch: fix quadratic complexity in", " parsing quoted cookie values with backslashes in Lib/http/cookies.py,", " Lib/test/test_http_cookies.py.", " - CVE-2024-7592", " * SECURITY UPDATE: infinite loop via crafted zip archive", " - debian/patches/CVE-2024-8088-1.patch: sanitize names in zipfile.Path", " in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - debian/patches/CVE-2024-8088-2.patch: replaced SanitizedNames with a", " more surgical fix in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - CVE-2024-8088", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 10:17:37 -0400" } ], "notes": null }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-45.45", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 11:02:01 +0200" } ], "notes": null }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-45.45", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 11:02:01 +0200" } ], "notes": null }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-45.45", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 11:02:01 +0200" } ], "notes": null }, { "name": "linux-libc-dev:armhf", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": null }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": null }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-45.45", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 11:02:01 +0200" } ], "notes": null }, { "name": "lxd-agent-loader", "from_version": { "source_package_name": "lxd-agent-loader", "source_package_version": "0.7", "version": "0.7" }, "to_version": { "source_package_name": "lxd-agent-loader", "source_package_version": "0.7ubuntu0.1", "version": "0.7ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 2078936 ], "changes": [ { "cves": [], "log": [ "", " * d/rules: don't stop lxd-agent on upgrade (LP: #2078936)", "" ], "package": "lxd-agent-loader", "version": "0.7ubuntu0.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078936 ], "author": "Simon Deziel ", "date": "Mon, 09 Sep 2024 17:21:52 -0400" } ], "notes": null }, { "name": "mdadm", "from_version": { "source_package_name": "mdadm", "source_package_version": "4.3-1ubuntu2", "version": "4.3-1ubuntu2" }, "to_version": { "source_package_name": "mdadm", "source_package_version": "4.3-1ubuntu2.1", "version": "4.3-1ubuntu2.1" }, "cves": [], "launchpad_bugs_fixed": [ 2070371, 2069821 ], "changes": [ { "cves": [], "log": [ "", " * mdadm: wait for mdmon when it is started via systemd (LP: #2070371)", " - d/p/lp2070371-0001-util.c-change-devnm-to-const-in-mdmon-functions.patch", " - d/p/lp2070371-0002-Wait-for-mdmon-when-it-is-stared-via-systemd.patch", " * mdadm: buffer overflow detected (LP: #2069821)", " - d/p/lp2069821-0001-mdadm-platform-intel-buffer-overflow-detected.patch", "" ], "package": "mdadm", "version": "4.3-1ubuntu2.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2070371, 2069821 ], "author": "Hector Cao ", "date": "Mon, 29 Jul 2024 10:06:31 +0200" } ], "notes": null }, { "name": "procps", "from_version": { "source_package_name": "procps", "source_package_version": "2:4.0.4-4ubuntu3", "version": "2:4.0.4-4ubuntu3" }, "to_version": { "source_package_name": "procps", "source_package_version": "2:4.0.4-4ubuntu3.1", "version": "2:4.0.4-4ubuntu3.1" }, "cves": [], "launchpad_bugs_fixed": [ 2003027 ], "changes": [ { "cves": [], "log": [ "", " * d/sysctl.d/10-bufferbloat.conf: set default qdisc to fq_codel (LP: #2003027)", "" ], "package": "procps", "version": "2:4.0.4-4ubuntu3.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2003027 ], "author": "Heitor Alves de Siqueira ", "date": "Wed, 17 Jul 2024 14:59:18 +0000" } ], "notes": null }, { "name": "python3-pkg-resources", "from_version": { "source_package_name": "setuptools", "source_package_version": "68.1.2-2ubuntu1", "version": "68.1.2-2ubuntu1" }, "to_version": { "source_package_name": "setuptools", "source_package_version": "68.1.2-2ubuntu1.1", "version": "68.1.2-2ubuntu1.1" }, "cves": [ { "cve": "CVE-2024-6345", "url": "https://ubuntu.com/security/CVE-2024-6345", "cve_description": "A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.", "cve_priority": "medium", "cve_public_date": "2024-07-15 01:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-6345", "url": "https://ubuntu.com/security/CVE-2024-6345", "cve_description": "A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.", "cve_priority": "medium", "cve_public_date": "2024-07-15 01:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: remote code execution via package download functions", " - debian/patches/CVE-2024-6345.patch: modernize and fix VCS handling", " to prevent code injection in setuptools/package_index.py and", " setuptools/tests/test_packageindex.py. Also update setup.cfg to", " include new test dependencies.", " - CVE-2024-6345", "" ], "package": "setuptools", "version": "68.1.2-2ubuntu1.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 27 Aug 2024 21:44:12 +0530" } ], "notes": null }, { "name": "python3-setuptools", "from_version": { "source_package_name": "setuptools", "source_package_version": "68.1.2-2ubuntu1", "version": "68.1.2-2ubuntu1" }, "to_version": { "source_package_name": "setuptools", "source_package_version": "68.1.2-2ubuntu1.1", "version": "68.1.2-2ubuntu1.1" }, "cves": [ { "cve": "CVE-2024-6345", "url": "https://ubuntu.com/security/CVE-2024-6345", "cve_description": "A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.", "cve_priority": "medium", "cve_public_date": "2024-07-15 01:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-6345", "url": "https://ubuntu.com/security/CVE-2024-6345", "cve_description": "A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.", "cve_priority": "medium", "cve_public_date": "2024-07-15 01:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: remote code execution via package download functions", " - debian/patches/CVE-2024-6345.patch: modernize and fix VCS handling", " to prevent code injection in setuptools/package_index.py and", " setuptools/tests/test_packageindex.py. Also update setup.cfg to", " include new test dependencies.", " - CVE-2024-6345", "" ], "package": "setuptools", "version": "68.1.2-2ubuntu1.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 27 Aug 2024 21:44:12 +0530" } ], "notes": null }, { "name": "python3-update-manager", "from_version": { "source_package_name": "update-manager", "source_package_version": "1:24.04.6", "version": "1:24.04.6" }, "to_version": { "source_package_name": "update-manager", "source_package_version": "1:24.04.8", "version": "1:24.04.8" }, "cves": [], "launchpad_bugs_fixed": [ 2068809, 2064211 ], "changes": [ { "cves": [], "log": [ "", " * Display changelogs also for PPA packages on ppa.launchpadcontent.net", " (lp: #2068809)", "", " [ Nathan Pratta Teodosio ]", " * Don't crash if the end-points of the Pro API fail (LP: #2064211).", "" ], "package": "update-manager", "version": "1:24.04.8", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2068809, 2064211 ], "author": "Sebastien Bacher ", "date": "Mon, 08 Jul 2024 14:00:19 +0200" } ], "notes": null }, { "name": "python3.12", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.1", "version": "3.12.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.2", "version": "3.12.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: incorrect special character parsing in email module", " - debian/patches/CVE-2023-27043.patch: reject malformed addresses in", " Doc/library/email.utils.rst, Lib/email/utils.py,", " Lib/test/test_email/test_email.py.", " - CVE-2023-27043", " * SECURITY UPDATE: ReDoS via specifically-crafted tar archives", " - debian/patches/CVE-2024-6232.patch: remove backtracking when parsing", " tarfile headers in Lib/tarfile.py, Lib/test/test_tarfile.py.", " - CVE-2024-6232", " * SECURITY UPDATE: header injection via newlines in email module", " - debian/patches/CVE-2024-6923.patch: encode newlines in headers, and", " verify headers are sound in Doc/library/email.errors.rst,", " Doc/library/email.policy.rst, Lib/email/_header_value_parser.py,", " Lib/email/_policybase.py, Lib/email/errors.py,", " Lib/email/generator.py, Lib/test/test_email/test_generator.py,", " Lib/test/test_email/test_policy.py.", " - CVE-2024-6923", " * SECURITY UPDATE: resource consumption via cookie parsing", " - debian/patches/CVE-2024-7592.patch: fix quadratic complexity in", " parsing quoted cookie values with backslashes in Lib/http/cookies.py,", " Lib/test/test_http_cookies.py.", " - CVE-2024-7592", " * SECURITY UPDATE: infinite loop via crafted zip archive", " - debian/patches/CVE-2024-8088-1.patch: sanitize names in zipfile.Path", " in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - debian/patches/CVE-2024-8088-2.patch: replaced SanitizedNames with a", " more surgical fix in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - CVE-2024-8088", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 10:17:37 -0400" } ], "notes": null }, { "name": "python3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.1", "version": "3.12.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.2", "version": "3.12.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2023-27043", "url": "https://ubuntu.com/security/CVE-2023-27043", "cve_description": "The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.", "cve_priority": "medium", "cve_public_date": "2023-04-19 00:15:00 UTC" }, { "cve": "CVE-2024-6232", "url": "https://ubuntu.com/security/CVE-2024-6232", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.", "cve_priority": "medium", "cve_public_date": "2024-09-03 13:15:00 UTC" }, { "cve": "CVE-2024-6923", "url": "https://ubuntu.com/security/CVE-2024-6923", "cve_description": "There is a MEDIUM severity vulnerability affecting CPython. The email module didn’t properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.", "cve_priority": "medium", "cve_public_date": "2024-08-01 14:15:00 UTC" }, { "cve": "CVE-2024-7592", "url": "https://ubuntu.com/security/CVE-2024-7592", "cve_description": "There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value.", "cve_priority": "low", "cve_public_date": "2024-08-19 19:15:00 UTC" }, { "cve": "CVE-2024-8088", "url": "https://ubuntu.com/security/CVE-2024-8088", "cve_description": "There is a HIGH severity vulnerability affecting the CPython \"zipfile\" module affecting \"zipfile.Path\". Note that the more common API \"zipfile.ZipFile\" class is unaffected. When iterating over names of entries in a zip archive (for example, methods of \"zipfile.Path\" like \"namelist()\", \"iterdir()\", etc) the process can be put into an infinite loop with a maliciously crafted zip archive. This defect applies when reading only metadata or extracting the contents of the zip archive. Programs that are not handling user-controlled zip archives are not affected.", "cve_priority": "medium", "cve_public_date": "2024-08-22 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: incorrect special character parsing in email module", " - debian/patches/CVE-2023-27043.patch: reject malformed addresses in", " Doc/library/email.utils.rst, Lib/email/utils.py,", " Lib/test/test_email/test_email.py.", " - CVE-2023-27043", " * SECURITY UPDATE: ReDoS via specifically-crafted tar archives", " - debian/patches/CVE-2024-6232.patch: remove backtracking when parsing", " tarfile headers in Lib/tarfile.py, Lib/test/test_tarfile.py.", " - CVE-2024-6232", " * SECURITY UPDATE: header injection via newlines in email module", " - debian/patches/CVE-2024-6923.patch: encode newlines in headers, and", " verify headers are sound in Doc/library/email.errors.rst,", " Doc/library/email.policy.rst, Lib/email/_header_value_parser.py,", " Lib/email/_policybase.py, Lib/email/errors.py,", " Lib/email/generator.py, Lib/test/test_email/test_generator.py,", " Lib/test/test_email/test_policy.py.", " - CVE-2024-6923", " * SECURITY UPDATE: resource consumption via cookie parsing", " - debian/patches/CVE-2024-7592.patch: fix quadratic complexity in", " parsing quoted cookie values with backslashes in Lib/http/cookies.py,", " Lib/test/test_http_cookies.py.", " - CVE-2024-7592", " * SECURITY UPDATE: infinite loop via crafted zip archive", " - debian/patches/CVE-2024-8088-1.patch: sanitize names in zipfile.Path", " in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - debian/patches/CVE-2024-8088-2.patch: replaced SanitizedNames with a", " more surgical fix in Lib/test/test_zipfile/_path/test_path.py,", " Lib/zipfile/_path/__init__.py.", " - CVE-2024-8088", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 10:17:37 -0400" } ], "notes": null }, { "name": "systemd-hwe-hwdb", "from_version": { "source_package_name": "systemd-hwe", "source_package_version": "255.1.3", "version": "255.1.3" }, "to_version": { "source_package_name": "systemd-hwe", "source_package_version": "255.1.4", "version": "255.1.4" }, "cves": [], "launchpad_bugs_fixed": [ 2073717, 2069383 ], "changes": [ { "cves": [], "log": [ "", " [ Kai-Chuan Hsieh ]", " * Add micmute key mapping for Dell Pro Rugged series (LP: #2073717)", "", " [ Nick Rosbrook ]", " * hwdb.d/90-sensor-ubuntu.hwdb: drop duplicate rules (LP: #2069383)", "" ], "package": "systemd-hwe", "version": "255.1.4", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2073717, 2069383 ], "author": "Nick Rosbrook ", "date": "Wed, 28 Aug 2024 11:21:32 -0400" } ], "notes": null }, { "name": "u-boot-tools", "from_version": { "source_package_name": "u-boot", "source_package_version": "2024.01+dfsg-1ubuntu5", "version": "2024.01+dfsg-1ubuntu5" }, "to_version": { "source_package_name": "u-boot", "source_package_version": "2024.01+dfsg-1ubuntu5.1", "version": "2024.01+dfsg-1ubuntu5.1" }, "cves": [], "launchpad_bugs_fixed": [ 2054092 ], "changes": [ { "cves": [], "log": [ "", " * Enable FIT images (LP: #2054092)", "" ], "package": "u-boot", "version": "2024.01+dfsg-1ubuntu5.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2054092 ], "author": "Dave Jones ", "date": "Tue, 06 Aug 2024 09:41:28 +0100" } ], "notes": null }, { "name": "ubuntu-pro-client", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "33.2~24.04.1", "version": "33.2~24.04.1" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "34~24.04", "version": "34~24.04" }, "cves": [], "launchpad_bugs_fixed": [ 2075543, 2075543, 2074211, 2055239, 2078737 ], "changes": [ { "cves": [], "log": [ "", " * Backport 34 to noble (LP: #2075543)", "" ], "package": "ubuntu-advantage-tools", "version": "34~24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2075543 ], "author": "Grant Orndorff ", "date": "Fri, 06 Sep 2024 19:58:23 -0400" }, { "cves": [], "log": [ "", " * d/rules: check that version.py is consistent with changelog (GH: #3154)", " * New upstream release 34: (LP: #2075543)", " - apt-hook: redirect errors away from users (LP: #2074211, LP: #2055239)", " - detach: ensure apt bearer tokens are always cleaned up", " - fips-preview: add warnings and prompts similar to fips and fips-updates", " - fips and realtime-kernel: add warning when the new kernel may have", " different hardware support than the current kernel based on the flavor", " (GH: #3115)", " - fix: use more reliable api query param when looking up CVE fixes", " - help:", " + change help output for base pro command", " + remove service descriptions from output (GH: #3126)", " + show help content when run without a subcommand", " - timer: recover from corrupted job status file (LP: #2078737)", " - update manpage", "" ], "package": "ubuntu-advantage-tools", "version": "34", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2075543, 2074211, 2055239, 2078737 ], "author": "Grant Orndorff ", "date": "Mon, 29 Jul 2024 15:48:22 -0500" } ], "notes": null }, { "name": "ubuntu-pro-client-l10n", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "33.2~24.04.1", "version": "33.2~24.04.1" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "34~24.04", "version": "34~24.04" }, "cves": [], "launchpad_bugs_fixed": [ 2075543, 2075543, 2074211, 2055239, 2078737 ], "changes": [ { "cves": [], "log": [ "", " * Backport 34 to noble (LP: #2075543)", "" ], "package": "ubuntu-advantage-tools", "version": "34~24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2075543 ], "author": "Grant Orndorff ", "date": "Fri, 06 Sep 2024 19:58:23 -0400" }, { "cves": [], "log": [ "", " * d/rules: check that version.py is consistent with changelog (GH: #3154)", " * New upstream release 34: (LP: #2075543)", " - apt-hook: redirect errors away from users (LP: #2074211, LP: #2055239)", " - detach: ensure apt bearer tokens are always cleaned up", " - fips-preview: add warnings and prompts similar to fips and fips-updates", " - fips and realtime-kernel: add warning when the new kernel may have", " different hardware support than the current kernel based on the flavor", " (GH: #3115)", " - fix: use more reliable api query param when looking up CVE fixes", " - help:", " + change help output for base pro command", " + remove service descriptions from output (GH: #3126)", " + show help content when run without a subcommand", " - timer: recover from corrupted job status file (LP: #2078737)", " - update manpage", "" ], "package": "ubuntu-advantage-tools", "version": "34", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2075543, 2074211, 2055239, 2078737 ], "author": "Grant Orndorff ", "date": "Mon, 29 Jul 2024 15:48:22 -0500" } ], "notes": null }, { "name": "update-manager-core", "from_version": { "source_package_name": "update-manager", "source_package_version": "1:24.04.6", "version": "1:24.04.6" }, "to_version": { "source_package_name": "update-manager", "source_package_version": "1:24.04.8", "version": "1:24.04.8" }, "cves": [], "launchpad_bugs_fixed": [ 2068809, 2064211 ], "changes": [ { "cves": [], "log": [ "", " * Display changelogs also for PPA packages on ppa.launchpadcontent.net", " (lp: #2068809)", "", " [ Nathan Pratta Teodosio ]", " * Don't crash if the end-points of the Pro API fail (LP: #2064211).", "" ], "package": "update-manager", "version": "1:24.04.8", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2068809, 2064211 ], "author": "Sebastien Bacher ", "date": "Mon, 08 Jul 2024 14:00:19 +0200" } ], "notes": null }, { "name": "vim", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.2", "version": "2:9.1.0016-1ubuntu7.2" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.3", "version": "2:9.1.0016-1ubuntu7.3" }, "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow", " - debian/patches/CVE-2024-43802.patch: check buflen before advancing", " offset. Add src/testdir/crash/heap_overflow3 to include-binaries.", " - CVE-2024-43802", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Wed, 25 Sep 2024 15:43:04 +0530" } ], "notes": null }, { "name": "vim-common", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.2", "version": "2:9.1.0016-1ubuntu7.2" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.3", "version": "2:9.1.0016-1ubuntu7.3" }, "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow", " - debian/patches/CVE-2024-43802.patch: check buflen before advancing", " offset. Add src/testdir/crash/heap_overflow3 to include-binaries.", " - CVE-2024-43802", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Wed, 25 Sep 2024 15:43:04 +0530" } ], "notes": null }, { "name": "vim-runtime", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.2", "version": "2:9.1.0016-1ubuntu7.2" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.3", "version": "2:9.1.0016-1ubuntu7.3" }, "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow", " - debian/patches/CVE-2024-43802.patch: check buflen before advancing", " offset. Add src/testdir/crash/heap_overflow3 to include-binaries.", " - CVE-2024-43802", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Wed, 25 Sep 2024 15:43:04 +0530" } ], "notes": null }, { "name": "vim-tiny", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.2", "version": "2:9.1.0016-1ubuntu7.2" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.3", "version": "2:9.1.0016-1ubuntu7.3" }, "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow", " - debian/patches/CVE-2024-43802.patch: check buflen before advancing", " offset. Add src/testdir/crash/heap_overflow3 to include-binaries.", " - CVE-2024-43802", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Wed, 25 Sep 2024 15:43:04 +0530" } ], "notes": null }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.2", "version": "2:9.1.0016-1ubuntu7.2" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.3", "version": "2:9.1.0016-1ubuntu7.3" }, "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-43802", "url": "https://ubuntu.com/security/CVE-2024-43802", "cve_description": "Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.", "cve_priority": "medium", "cve_public_date": "2024-08-26 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow", " - debian/patches/CVE-2024-43802.patch: check buflen before advancing", " offset. Add src/testdir/crash/heap_overflow3 to include-binaries.", " - CVE-2024-43802", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Wed, 25 Sep 2024 15:43:04 +0530" } ], "notes": null } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-6.8.0-45", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-headers-6.8.0-45 version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-headers-6.8.0-45 version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-6.8.0-45-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-headers-6.8.0-45-generic version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-headers-6.8.0-45-generic version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-6.8.0-45-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-image-6.8.0-45-generic version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-image-6.8.0-45-generic version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-6.8.0-45-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-modules-6.8.0-45-generic version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-modules-6.8.0-45-generic version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-tools-6.8.0-45", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-tools-6.8.0-45 version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-tools-6.8.0-45 version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-tools-6.8.0-45-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-45.45", "version": "6.8.0-45.45" }, "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "changes": [ { "cves": [ { "cve": "CVE-2024-41009", "url": "https://ubuntu.com/security/CVE-2024-41009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that \"owns\" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.", "cve_priority": "medium", "cve_public_date": "2024-07-17 07:15:00 UTC" }, { "cve": "CVE-2024-42160", "url": "https://ubuntu.com/security/CVE-2024-42160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42224", "url": "https://ubuntu.com/security/CVE-2024-42224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO busses\") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42154", "url": "https://ubuntu.com/security/CVE-2024-42154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42228", "url": "https://ubuntu.com/security/CVE-2024-42228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" }, { "cve": "CVE-2024-42159", "url": "https://ubuntu.com/security/CVE-2024-42159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2024-07-30 08:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-45.45 -proposed tracker (LP: #2078100)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2024.08.05)", "", " * Noble update: upstream stable patchset 2024-08-09 (LP: #2076435) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", "", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42224", " - net: dsa: mv88e6xxx: Correct check for empty list", "", " * Noble update: upstream stable patchset 2024-08-22 (LP: #2077600) //", " CVE-2024-42154", " - tcp_metrics: validate source addr length", "", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", "", " * CVE-2024-42159", " - scsi: mpi3mr: Sanitise num_phys", "" ], "package": "linux", "version": "6.8.0-45.45", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078100, 1786013, 2076435, 2077600, 2077600 ], "author": "Manuel Diewald ", "date": "Fri, 30 Aug 2024 10:32:37 +0200" } ], "notes": "linux-tools-6.8.0-45-generic version '6.8.0-45.45' (source package linux version '6.8.0-45.45') was added. linux-tools-6.8.0-45-generic version '6.8.0-45.45' has the same source package name, linux, as removed package linux-headers-6.8.0-44. As such we can use the source package version of the removed package, '6.8.0-44.44', 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-6.8.0-44", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-headers-6.8.0-44-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-6.8.0-44-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-6.8.0-44-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-tools-6.8.0-44", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-tools-6.8.0-44-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-44.44", "version": "6.8.0-44.44" }, "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 24.04 noble image from daily image serial 20240912 to 20241004", "from_series": "noble", "to_series": "noble", "from_serial": "20240912", "to_serial": "20241004", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }