{
    "summary": {
        "snap": {
            "added": [],
            "removed": [],
            "diff": []
        },
        "deb": {
            "added": [
                "linux-headers-5.15.0-1065-kvm",
                "linux-image-5.15.0-1065-kvm",
                "linux-kvm-headers-5.15.0-1065",
                "linux-modules-5.15.0-1065-kvm"
            ],
            "removed": [
                "linux-headers-5.15.0-1064-kvm",
                "linux-image-5.15.0-1064-kvm",
                "linux-kvm-headers-5.15.0-1064",
                "linux-modules-5.15.0-1064-kvm"
            ],
            "diff": [
                "linux-headers-kvm",
                "linux-image-kvm",
                "linux-kvm"
            ]
        }
    },
    "diff": {
        "deb": [
            {
                "name": "linux-headers-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1064.60",
                    "version": "5.15.0.1064.60"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1065.61",
                    "version": "5.15.0.1065.61"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1065",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1065.61",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:54 +0200"
                    }
                ],
                "notes": null
            },
            {
                "name": "linux-image-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1064.60",
                    "version": "5.15.0.1064.60"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1065.61",
                    "version": "5.15.0.1065.61"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1065",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1065.61",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:54 +0200"
                    }
                ],
                "notes": null
            },
            {
                "name": "linux-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1064.60",
                    "version": "5.15.0.1064.60"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1065.61",
                    "version": "5.15.0.1065.61"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1065",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1065.61",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:54 +0200"
                    }
                ],
                "notes": null
            }
        ],
        "snap": []
    },
    "added": {
        "deb": [
            {
                "name": "linux-headers-5.15.0-1065-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1065.70",
                    "version": "5.15.0-1065.70"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26921",
                        "url": "https://ubuntu.com/security/CVE-2024-26921",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-18 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39484",
                        "url": "https://ubuntu.com/security/CVE-2024-39484",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-07-05 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39292",
                        "url": "https://ubuntu.com/security/CVE-2024-39292",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-06-24 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-36901",
                        "url": "https://ubuntu.com/security/CVE-2024-36901",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-30 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26830",
                        "url": "https://ubuntu.com/security/CVE-2024-26830",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26680",
                        "url": "https://ubuntu.com/security/CVE-2024-26680",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-02 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52760",
                        "url": "https://ubuntu.com/security/CVE-2023-52760",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-21 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52629",
                        "url": "https://ubuntu.com/security/CVE-2023-52629",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-03-29 10:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2075651,
                    2075665,
                    2073267,
                    2073765,
                    2073765
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26921",
                                "url": "https://ubuntu.com/security/CVE-2024-26921",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-18 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39484",
                                "url": "https://ubuntu.com/security/CVE-2024-39484",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-07-05 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39292",
                                "url": "https://ubuntu.com/security/CVE-2024-39292",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-06-24 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-36901",
                                "url": "https://ubuntu.com/security/CVE-2024-36901",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-30 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26830",
                                "url": "https://ubuntu.com/security/CVE-2024-26830",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26680",
                                "url": "https://ubuntu.com/security/CVE-2024-26680",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-02 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52760",
                                "url": "https://ubuntu.com/security/CVE-2023-52760",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-21 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52629",
                                "url": "https://ubuntu.com/security/CVE-2023-52629",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-03-29 10:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1065.70 -proposed tracker (LP: #2075651)",
                            "",
                            "  [ Ubuntu: 5.15.0-119.129 ]",
                            "",
                            "  * jammy/linux: 5.15.0-119.129 -proposed tracker (LP: #2075665)",
                            "  * Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4",
                            "    (LP: #2073267)",
                            "    - SAUCE: Revert \"randomize_kstack: Improve entropy diffusion\"",
                            "  * CVE-2024-26921",
                            "    - inet: inet_defrag: prevent sk release while still in use",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765) //",
                            "    CVE-2024-39484",
                            "    - mmc: davinci: Don't strip remove function when driver is builtin",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765)",
                            "    - mmc: davinci_mmc: Convert to platform remove callback returning void",
                            "  * CVE-2024-39292",
                            "    - um: Add winch to winch_handlers before registering winch IRQ",
                            "  * CVE-2024-36901",
                            "    - ipv6: prevent NULL dereference in ip6_output()",
                            "  * CVE-2024-26830",
                            "    - i40e: Do not allow untrusted VF to remove administratively set MAC",
                            "  * CVE-2024-26680",
                            "    - net: atlantic: Fix DMA mapping for PTP hwts ring",
                            "  * CVE-2023-52760",
                            "    - gfs2: Fix slab-use-after-free in gfs2_qd_dealloc",
                            "  * CVE-2023-52629",
                            "    - sh: push-switch: Reorder cleanup operations to avoid use-after-free bug",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1065.70",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2075651,
                            2075665,
                            2073267,
                            2073765,
                            2073765
                        ],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:24 +0200"
                    }
                ],
                "notes": "linux-headers-5.15.0-1065-kvm version '5.15.0-1065.70' (source package linux-kvm version '5.15.0-1065.70') was added. linux-headers-5.15.0-1065-kvm version '5.15.0-1065.70' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1064-kvm. As such we can use the source package version of the removed package, '5.15.0-1064.69', 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-1065-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1065.70",
                    "version": "5.15.0-1065.70"
                },
                "cves": [],
                "launchpad_bugs_fixed": [
                    1786013
                ],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Main version: 5.15.0-1065.70",
                            "",
                            "  * Packaging resync (LP: #1786013)",
                            "    - [Packaging] debian/tracking-bug -- resync from main package",
                            ""
                        ],
                        "package": "linux-signed-kvm",
                        "version": "5.15.0-1065.70",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            1786013
                        ],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:57:01 +0200"
                    }
                ],
                "notes": "linux-image-5.15.0-1065-kvm version '5.15.0-1065.70' (source package linux-signed-kvm version '5.15.0-1065.70') was added. linux-image-5.15.0-1065-kvm version '5.15.0-1065.70' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1064-kvm. As such we can use the source package version of the removed package, '5.15.0-1064.69', 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-1065",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1065.70",
                    "version": "5.15.0-1065.70"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26921",
                        "url": "https://ubuntu.com/security/CVE-2024-26921",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-18 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39484",
                        "url": "https://ubuntu.com/security/CVE-2024-39484",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-07-05 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39292",
                        "url": "https://ubuntu.com/security/CVE-2024-39292",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-06-24 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-36901",
                        "url": "https://ubuntu.com/security/CVE-2024-36901",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-30 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26830",
                        "url": "https://ubuntu.com/security/CVE-2024-26830",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26680",
                        "url": "https://ubuntu.com/security/CVE-2024-26680",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-02 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52760",
                        "url": "https://ubuntu.com/security/CVE-2023-52760",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-21 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52629",
                        "url": "https://ubuntu.com/security/CVE-2023-52629",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-03-29 10:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2075651,
                    2075665,
                    2073267,
                    2073765,
                    2073765
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26921",
                                "url": "https://ubuntu.com/security/CVE-2024-26921",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-18 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39484",
                                "url": "https://ubuntu.com/security/CVE-2024-39484",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-07-05 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39292",
                                "url": "https://ubuntu.com/security/CVE-2024-39292",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-06-24 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-36901",
                                "url": "https://ubuntu.com/security/CVE-2024-36901",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-30 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26830",
                                "url": "https://ubuntu.com/security/CVE-2024-26830",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26680",
                                "url": "https://ubuntu.com/security/CVE-2024-26680",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-02 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52760",
                                "url": "https://ubuntu.com/security/CVE-2023-52760",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-21 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52629",
                                "url": "https://ubuntu.com/security/CVE-2023-52629",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-03-29 10:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1065.70 -proposed tracker (LP: #2075651)",
                            "",
                            "  [ Ubuntu: 5.15.0-119.129 ]",
                            "",
                            "  * jammy/linux: 5.15.0-119.129 -proposed tracker (LP: #2075665)",
                            "  * Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4",
                            "    (LP: #2073267)",
                            "    - SAUCE: Revert \"randomize_kstack: Improve entropy diffusion\"",
                            "  * CVE-2024-26921",
                            "    - inet: inet_defrag: prevent sk release while still in use",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765) //",
                            "    CVE-2024-39484",
                            "    - mmc: davinci: Don't strip remove function when driver is builtin",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765)",
                            "    - mmc: davinci_mmc: Convert to platform remove callback returning void",
                            "  * CVE-2024-39292",
                            "    - um: Add winch to winch_handlers before registering winch IRQ",
                            "  * CVE-2024-36901",
                            "    - ipv6: prevent NULL dereference in ip6_output()",
                            "  * CVE-2024-26830",
                            "    - i40e: Do not allow untrusted VF to remove administratively set MAC",
                            "  * CVE-2024-26680",
                            "    - net: atlantic: Fix DMA mapping for PTP hwts ring",
                            "  * CVE-2023-52760",
                            "    - gfs2: Fix slab-use-after-free in gfs2_qd_dealloc",
                            "  * CVE-2023-52629",
                            "    - sh: push-switch: Reorder cleanup operations to avoid use-after-free bug",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1065.70",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2075651,
                            2075665,
                            2073267,
                            2073765,
                            2073765
                        ],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:24 +0200"
                    }
                ],
                "notes": "linux-kvm-headers-5.15.0-1065 version '5.15.0-1065.70' (source package linux-kvm version '5.15.0-1065.70') was added. linux-kvm-headers-5.15.0-1065 version '5.15.0-1065.70' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1064-kvm. As such we can use the source package version of the removed package, '5.15.0-1064.69', 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-1065-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1065.70",
                    "version": "5.15.0-1065.70"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26921",
                        "url": "https://ubuntu.com/security/CVE-2024-26921",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-18 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39484",
                        "url": "https://ubuntu.com/security/CVE-2024-39484",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-07-05 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-39292",
                        "url": "https://ubuntu.com/security/CVE-2024-39292",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-06-24 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-36901",
                        "url": "https://ubuntu.com/security/CVE-2024-36901",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-30 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26830",
                        "url": "https://ubuntu.com/security/CVE-2024-26830",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26680",
                        "url": "https://ubuntu.com/security/CVE-2024-26680",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-02 07:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52760",
                        "url": "https://ubuntu.com/security/CVE-2023-52760",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-05-21 16:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2023-52629",
                        "url": "https://ubuntu.com/security/CVE-2023-52629",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-03-29 10:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2075651,
                    2075665,
                    2073267,
                    2073765,
                    2073765
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26921",
                                "url": "https://ubuntu.com/security/CVE-2024-26921",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf (\"inet: frag: Always orphan skbs inside ip_defrag()\") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-18 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39484",
                                "url": "https://ubuntu.com/security/CVE-2024-39484",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  mmc: davinci: Don't strip remove function when driver is builtin  Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.  This also fixes a W=1 modpost warning:  WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-07-05 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-39292",
                                "url": "https://ubuntu.com/security/CVE-2024-39292",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-06-24 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-36901",
                                "url": "https://ubuntu.com/security/CVE-2024-36901",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-30 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26830",
                                "url": "https://ubuntu.com/security/CVE-2024-26830",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26680",
                                "url": "https://ubuntu.com/security/CVE-2024-26680",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-02 07:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52760",
                                "url": "https://ubuntu.com/security/CVE-2023-52760",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-05-21 16:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2023-52629",
                                "url": "https://ubuntu.com/security/CVE-2023-52629",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-03-29 10:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1065.70 -proposed tracker (LP: #2075651)",
                            "",
                            "  [ Ubuntu: 5.15.0-119.129 ]",
                            "",
                            "  * jammy/linux: 5.15.0-119.129 -proposed tracker (LP: #2075665)",
                            "  * Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4",
                            "    (LP: #2073267)",
                            "    - SAUCE: Revert \"randomize_kstack: Improve entropy diffusion\"",
                            "  * CVE-2024-26921",
                            "    - inet: inet_defrag: prevent sk release while still in use",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765) //",
                            "    CVE-2024-39484",
                            "    - mmc: davinci: Don't strip remove function when driver is builtin",
                            "  * Jammy update: v5.15.162 upstream stable release (LP: #2073765)",
                            "    - mmc: davinci_mmc: Convert to platform remove callback returning void",
                            "  * CVE-2024-39292",
                            "    - um: Add winch to winch_handlers before registering winch IRQ",
                            "  * CVE-2024-36901",
                            "    - ipv6: prevent NULL dereference in ip6_output()",
                            "  * CVE-2024-26830",
                            "    - i40e: Do not allow untrusted VF to remove administratively set MAC",
                            "  * CVE-2024-26680",
                            "    - net: atlantic: Fix DMA mapping for PTP hwts ring",
                            "  * CVE-2023-52760",
                            "    - gfs2: Fix slab-use-after-free in gfs2_qd_dealloc",
                            "  * CVE-2023-52629",
                            "    - sh: push-switch: Reorder cleanup operations to avoid use-after-free bug",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1065.70",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2075651,
                            2075665,
                            2073267,
                            2073765,
                            2073765
                        ],
                        "author": "Roxana Nicolescu <roxana.nicolescu@canonical.com>",
                        "date": "Thu, 15 Aug 2024 10:56:24 +0200"
                    }
                ],
                "notes": "linux-modules-5.15.0-1065-kvm version '5.15.0-1065.70' (source package linux-kvm version '5.15.0-1065.70') was added. linux-modules-5.15.0-1065-kvm version '5.15.0-1065.70' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1064-kvm. As such we can use the source package version of the removed package, '5.15.0-1064.69', 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-1064-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": "5.15.0-1064.69"
                },
                "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-1064-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": "5.15.0-1064.69"
                },
                "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-1064",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": "5.15.0-1064.69"
                },
                "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-1064-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1064.69",
                    "version": "5.15.0-1064.69"
                },
                "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 20240815 to 20240821",
    "from_series": "jammy",
    "to_series": "jammy",
    "from_serial": "20240815",
    "to_serial": "20240821",
    "from_manifest_filename": "daily_manifest.previous",
    "to_manifest_filename": "manifest.current"
}