{
"summary": {
"snap": {
"added": [],
"removed": [],
"diff": []
},
"deb": {
"added": [
"linux-headers-5.15.0-113",
"linux-headers-5.15.0-113-generic",
"linux-image-5.15.0-113-generic",
"linux-modules-5.15.0-113-generic"
],
"removed": [
"linux-headers-5.15.0-112",
"linux-headers-5.15.0-112-generic",
"linux-image-5.15.0-112-generic",
"linux-modules-5.15.0-112-generic"
],
"diff": [
"linux-headers-generic",
"linux-headers-virtual",
"linux-image-virtual",
"linux-virtual"
]
}
},
"diff": {
"deb": [
{
"name": "linux-headers-generic",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.112.112",
"version": "5.15.0.112.112"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.113.113",
"version": "5.15.0.113.113"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Bump ABI 5.15.0-113",
""
],
"package": "linux-meta",
"version": "5.15.0.113.113",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 10:00:30 +0200"
}
],
"notes": null
},
{
"name": "linux-headers-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.112.112",
"version": "5.15.0.112.112"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.113.113",
"version": "5.15.0.113.113"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Bump ABI 5.15.0-113",
""
],
"package": "linux-meta",
"version": "5.15.0.113.113",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 10:00:30 +0200"
}
],
"notes": null
},
{
"name": "linux-image-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.112.112",
"version": "5.15.0.112.112"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.113.113",
"version": "5.15.0.113.113"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Bump ABI 5.15.0-113",
""
],
"package": "linux-meta",
"version": "5.15.0.113.113",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 10:00:30 +0200"
}
],
"notes": null
},
{
"name": "linux-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.112.112",
"version": "5.15.0.112.112"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "5.15.0.113.113",
"version": "5.15.0.113.113"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Bump ABI 5.15.0-113",
""
],
"package": "linux-meta",
"version": "5.15.0.113.113",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 10:00:30 +0200"
}
],
"notes": null
}
],
"snap": []
},
"added": {
"deb": [
{
"name": "linux-headers-5.15.0-113",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-113.123",
"version": "5.15.0-113.123"
},
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2068242
],
"changes": [
{
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"log": [
"",
" * jammy/linux: 5.15.0-113.123 -proposed tracker (LP: #2068242)",
"",
" * CVE-2024-26924",
" - netfilter: nft_set_pipapo: do not free live element",
"",
" * CVE-2024-26643",
" - netfilter: nf_tables: mark set as dead when unbinding anonymous set with",
" timeout",
""
],
"package": "linux",
"version": "5.15.0-113.123",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [
2068242
],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 09:55:36 +0200"
}
],
"notes": "linux-headers-5.15.0-113 version '5.15.0-113.123' (source package linux version '5.15.0-113.123') was added. linux-headers-5.15.0-113 version '5.15.0-113.123' has the same source package name, linux, as removed package linux-headers-5.15.0-112. As such we can use the source package version of the removed package, '5.15.0-112.122', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package."
},
{
"name": "linux-headers-5.15.0-113-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-113.123",
"version": "5.15.0-113.123"
},
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2068242
],
"changes": [
{
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"log": [
"",
" * jammy/linux: 5.15.0-113.123 -proposed tracker (LP: #2068242)",
"",
" * CVE-2024-26924",
" - netfilter: nft_set_pipapo: do not free live element",
"",
" * CVE-2024-26643",
" - netfilter: nf_tables: mark set as dead when unbinding anonymous set with",
" timeout",
""
],
"package": "linux",
"version": "5.15.0-113.123",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [
2068242
],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 09:55:36 +0200"
}
],
"notes": "linux-headers-5.15.0-113-generic version '5.15.0-113.123' (source package linux version '5.15.0-113.123') was added. linux-headers-5.15.0-113-generic version '5.15.0-113.123' has the same source package name, linux, as removed package linux-headers-5.15.0-112. As such we can use the source package version of the removed package, '5.15.0-112.122', 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-113-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "5.15.0-112.122",
"version": null
},
"to_version": {
"source_package_name": "linux-signed",
"source_package_version": "5.15.0-113.123",
"version": "5.15.0-113.123"
},
"cves": [],
"launchpad_bugs_fixed": [
1786013
],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 5.15.0-113.123",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "5.15.0-113.123",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [
1786013
],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 10:00:37 +0200"
}
],
"notes": "linux-image-5.15.0-113-generic version '5.15.0-113.123' (source package linux-signed version '5.15.0-113.123') was added. linux-image-5.15.0-113-generic version '5.15.0-113.123' has the same source package name, linux-signed, as removed package linux-image-5.15.0-112-generic. As such we can use the source package version of the removed package, '5.15.0-112.122', 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-113-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-113.123",
"version": "5.15.0-113.123"
},
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2068242
],
"changes": [
{
"cves": [
{
"cve": "CVE-2024-26924",
"url": "https://ubuntu.com/security/CVE-2024-26924",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") <---------------- delete one that was just added ... add_elem(\"00005000\") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)",
"cve_priority": "high",
"cve_public_date": "2024-04-25 06:15:00 UTC"
},
{
"cve": "CVE-2024-26643",
"url": "https://ubuntu.com/security/CVE-2024-26643",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set element timeout\"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on transaction abort\"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.",
"cve_priority": "high",
"cve_public_date": "2024-03-21 11:15:00 UTC"
}
],
"log": [
"",
" * jammy/linux: 5.15.0-113.123 -proposed tracker (LP: #2068242)",
"",
" * CVE-2024-26924",
" - netfilter: nft_set_pipapo: do not free live element",
"",
" * CVE-2024-26643",
" - netfilter: nf_tables: mark set as dead when unbinding anonymous set with",
" timeout",
""
],
"package": "linux",
"version": "5.15.0-113.123",
"urgency": "medium",
"distributions": "jammy",
"launchpad_bugs_fixed": [
2068242
],
"author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
"date": "Mon, 10 Jun 2024 09:55:36 +0200"
}
],
"notes": "linux-modules-5.15.0-113-generic version '5.15.0-113.123' (source package linux version '5.15.0-113.123') was added. linux-modules-5.15.0-113-generic version '5.15.0-113.123' has the same source package name, linux, as removed package linux-headers-5.15.0-112. As such we can use the source package version of the removed package, '5.15.0-112.122', 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-112",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": "5.15.0-112.122"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null
},
{
"name": "linux-headers-5.15.0-112-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": "5.15.0-112.122"
},
"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-112-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "5.15.0-112.122",
"version": "5.15.0-112.122"
},
"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-112-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "5.15.0-112.122",
"version": "5.15.0-112.122"
},
"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 daily image serial 20240614 to 20240626",
"from_series": "jammy",
"to_series": "jammy",
"from_serial": "20240614",
"to_serial": "20240626",
"from_manifest_filename": "daily_manifest.previous",
"to_manifest_filename": "manifest.current"
}