{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1067-kvm", "linux-image-5.15.0-1067-kvm", "linux-kvm-headers-5.15.0-1067", "linux-modules-5.15.0-1067-kvm" ], "removed": [ "linux-headers-5.15.0-1066-kvm", "linux-image-5.15.0-1066-kvm", "linux-kvm-headers-5.15.0-1066", "linux-modules-5.15.0-1066-kvm" ], "diff": [ "curl", "libcurl4", "libpython3.10-minimal", "libpython3.10-stdlib", "linux-headers-kvm", "linux-image-kvm", "linux-kvm", "python3.10", "python3.10-minimal" ] } }, "diff": { "deb": [ { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "7.81.0-1ubuntu1.17", "version": "7.81.0-1ubuntu1.17" }, "to_version": { "source_package_name": "curl", "source_package_version": "7.81.0-1ubuntu1.18", "version": "7.81.0-1ubuntu1.18" }, "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": "7.81.0-1ubuntu1.18", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 06 Sep 2024 07:38:40 -0400" } ], "notes": null }, { "name": "libcurl4", "from_version": { "source_package_name": "curl", "source_package_version": "7.81.0-1ubuntu1.17", "version": "7.81.0-1ubuntu1.17" }, "to_version": { "source_package_name": "curl", "source_package_version": "7.81.0-1ubuntu1.18", "version": "7.81.0-1ubuntu1.18" }, "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": "7.81.0-1ubuntu1.18", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 06 Sep 2024 07:38:40 -0400" } ], "notes": null }, { "name": "libpython3.10-minimal", "from_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.5", "version": "3.10.12-1~22.04.5" }, "to_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.6", "version": "3.10.12-1~22.04.6" }, "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.10", "version": "3.10.12-1~22.04.6", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 11:47:36 -0400" } ], "notes": null }, { "name": "libpython3.10-stdlib", "from_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.5", "version": "3.10.12-1~22.04.5" }, "to_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.6", "version": "3.10.12-1~22.04.6" }, "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.10", "version": "3.10.12-1~22.04.6", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 11:47:36 -0400" } ], "notes": null }, { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1066.62", "version": "5.15.0.1066.62" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1067.63", "version": "5.15.0.1067.63" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1067", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1067.63", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:44:11 +0200" } ], "notes": null }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1066.62", "version": "5.15.0.1066.62" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1067.63", "version": "5.15.0.1067.63" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1067", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1067.63", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:44:11 +0200" } ], "notes": null }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1066.62", "version": "5.15.0.1066.62" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1067.63", "version": "5.15.0.1067.63" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1067", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1067.63", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:44:11 +0200" } ], "notes": null }, { "name": "python3.10", "from_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.5", "version": "3.10.12-1~22.04.5" }, "to_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.6", "version": "3.10.12-1~22.04.6" }, "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.10", "version": "3.10.12-1~22.04.6", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 11:47:36 -0400" } ], "notes": null }, { "name": "python3.10-minimal", "from_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.5", "version": "3.10.12-1~22.04.5" }, "to_version": { "source_package_name": "python3.10", "source_package_version": "3.10.12-1~22.04.6", "version": "3.10.12-1~22.04.6" }, "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.10", "version": "3.10.12-1~22.04.6", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Sep 2024 11:47:36 -0400" } ], "notes": null } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1067-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1067.72", "version": "5.15.0-1067.72" }, "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1067.72 -proposed tracker (LP: #2078140)", "", " [ Ubuntu: 5.15.0-122.132 ]", "", " * jammy/linux: 5.15.0-122.132 -proposed tracker (LP: #2078154)", " * isolcpus are ignored when using cgroups V2, causing processes to have wrong", " affinity (LP: #2076957)", " - cgroup/cpuset: Optimize cpuset_attach() on v2", " * Jammy update: v5.15.164 upstream stable release (LP: #2076100) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", " * CVE-2024-39494", " - ima: Fix use-after-free on a dentry's dname.name", " * CVE-2024-39496", " - btrfs: zoned: fix use-after-free due to race with dev replace", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", " * CVE-2024-38570", " - gfs2: Rename sd_{ glock => kill }_wait", " - gfs2: Fix potential glock use-after-free on unmount", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", " * CVE-2024-27012", " - netfilter: nf_tables: restore set elements when delete set fails", " * CVE-2024-26677", " - rxrpc: Fix delayed ACKs to not set the reference serial number", "" ], "package": "linux-kvm", "version": "5.15.0-1067.72", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:43:18 +0200" } ], "notes": "linux-headers-5.15.0-1067-kvm version '5.15.0-1067.72' (source package linux-kvm version '5.15.0-1067.72') was added. linux-headers-5.15.0-1067-kvm version '5.15.0-1067.72' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1066-kvm. As such we can use the source package version of the removed package, '5.15.0-1066.71', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-image-5.15.0-1067-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1066.71", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1067.72", "version": "5.15.0-1067.72" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1067.72", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1067.72", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:43:43 +0200" } ], "notes": "linux-image-5.15.0-1067-kvm version '5.15.0-1067.72' (source package linux-signed-kvm version '5.15.0-1067.72') was added. linux-image-5.15.0-1067-kvm version '5.15.0-1067.72' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1066-kvm. As such we can use the source package version of the removed package, '5.15.0-1066.71', 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-kvm-headers-5.15.0-1067", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1067.72", "version": "5.15.0-1067.72" }, "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1067.72 -proposed tracker (LP: #2078140)", "", " [ Ubuntu: 5.15.0-122.132 ]", "", " * jammy/linux: 5.15.0-122.132 -proposed tracker (LP: #2078154)", " * isolcpus are ignored when using cgroups V2, causing processes to have wrong", " affinity (LP: #2076957)", " - cgroup/cpuset: Optimize cpuset_attach() on v2", " * Jammy update: v5.15.164 upstream stable release (LP: #2076100) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", " * CVE-2024-39494", " - ima: Fix use-after-free on a dentry's dname.name", " * CVE-2024-39496", " - btrfs: zoned: fix use-after-free due to race with dev replace", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", " * CVE-2024-38570", " - gfs2: Rename sd_{ glock => kill }_wait", " - gfs2: Fix potential glock use-after-free on unmount", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", " * CVE-2024-27012", " - netfilter: nf_tables: restore set elements when delete set fails", " * CVE-2024-26677", " - rxrpc: Fix delayed ACKs to not set the reference serial number", "" ], "package": "linux-kvm", "version": "5.15.0-1067.72", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:43:18 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1067 version '5.15.0-1067.72' (source package linux-kvm version '5.15.0-1067.72') was added. linux-kvm-headers-5.15.0-1067 version '5.15.0-1067.72' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1066-kvm. As such we can use the source package version of the removed package, '5.15.0-1066.71', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-modules-5.15.0-1067-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1067.72", "version": "5.15.0-1067.72" }, "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "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-39494", "url": "https://ubuntu.com/security/CVE-2024-39494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-39496", "url": "https://ubuntu.com/security/CVE-2024-39496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13: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-38570", "url": "https://ubuntu.com/security/CVE-2024-38570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14: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-27012", "url": "https://ubuntu.com/security/CVE-2024-27012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2024-26677", "url": "https://ubuntu.com/security/CVE-2024-26677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.", "cve_priority": "medium", "cve_public_date": "2024-04-02 07:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1067.72 -proposed tracker (LP: #2078140)", "", " [ Ubuntu: 5.15.0-122.132 ]", "", " * jammy/linux: 5.15.0-122.132 -proposed tracker (LP: #2078154)", " * isolcpus are ignored when using cgroups V2, causing processes to have wrong", " affinity (LP: #2076957)", " - cgroup/cpuset: Optimize cpuset_attach() on v2", " * Jammy update: v5.15.164 upstream stable release (LP: #2076100) //", " CVE-2024-41009", " - bpf: Fix overrunning reservations in ringbuf", " * CVE-2024-39494", " - ima: Fix use-after-free on a dentry's dname.name", " * CVE-2024-39496", " - btrfs: zoned: fix use-after-free due to race with dev replace", " * CVE-2024-42160", " - f2fs: check validation of fault attrs in f2fs_build_fault_attr()", " - f2fs: Add inline to f2fs_build_fault_attr() stub", " * CVE-2024-38570", " - gfs2: Rename sd_{ glock => kill }_wait", " - gfs2: Fix potential glock use-after-free on unmount", " * CVE-2024-42228", " - drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc", " * CVE-2024-27012", " - netfilter: nf_tables: restore set elements when delete set fails", " * CVE-2024-26677", " - rxrpc: Fix delayed ACKs to not set the reference serial number", "" ], "package": "linux-kvm", "version": "5.15.0-1067.72", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2078140, 2078154, 2076957, 2076100 ], "author": "Stefan Bader ", "date": "Fri, 30 Aug 2024 15:43:18 +0200" } ], "notes": "linux-modules-5.15.0-1067-kvm version '5.15.0-1067.72' (source package linux-kvm version '5.15.0-1067.72') was added. linux-modules-5.15.0-1067-kvm version '5.15.0-1067.72' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1066-kvm. As such we can use the source package version of the removed package, '5.15.0-1066.71', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1066-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": "5.15.0-1066.71" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-5.15.0-1066-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1066.71", "version": "5.15.0-1066.71" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-kvm-headers-5.15.0-1066", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": "5.15.0-1066.71" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-5.15.0-1066-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1066.71", "version": "5.15.0-1066.71" }, "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 22.04 jammy image from release image serial 20240912 to 20240916.1", "from_series": "jammy", "to_series": "jammy", "from_serial": "20240912", "to_serial": "20240916.1", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }