{
    "summary": {
        "snap": {
            "added": [],
            "removed": [],
            "diff": []
        },
        "deb": {
            "added": [
                "linux-headers-5.15.0-1078-kvm",
                "linux-image-5.15.0-1078-kvm",
                "linux-kvm-headers-5.15.0-1078",
                "linux-modules-5.15.0-1078-kvm"
            ],
            "removed": [
                "linux-headers-5.15.0-1077-kvm",
                "linux-image-5.15.0-1077-kvm",
                "linux-kvm-headers-5.15.0-1077",
                "linux-modules-5.15.0-1077-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.1077.73",
                    "version": "5.15.0.1077.73"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1078.74",
                    "version": "5.15.0.1078.74"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1078",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1078.74",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 17:09:39 +0100"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-image-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1077.73",
                    "version": "5.15.0.1077.73"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1078.74",
                    "version": "5.15.0.1078.74"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1078",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1078.74",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 17:09:39 +0100"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1077.73",
                    "version": "5.15.0.1077.73"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1078.74",
                    "version": "5.15.0.1078.74"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1078",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1078.74",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 17:09:39 +0100"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            }
        ],
        "snap": []
    },
    "added": {
        "deb": [
            {
                "name": "linux-headers-5.15.0-1078-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1078.83",
                    "version": "5.15.0-1078.83"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26837",
                        "url": "https://ubuntu.com/security/CVE-2024-26837",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21756",
                        "url": "https://ubuntu.com/security/CVE-2025-21756",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-27 03:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50256",
                        "url": "https://ubuntu.com/security/CVE-2024-50256",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21702",
                        "url": "https://ubuntu.com/security/CVE-2025-21702",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21703",
                        "url": "https://ubuntu.com/security/CVE-2025-21703",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21700",
                        "url": "https://ubuntu.com/security/CVE-2025-21700",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-46826",
                        "url": "https://ubuntu.com/security/CVE-2024-46826",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-09-27 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56651",
                        "url": "https://ubuntu.com/security/CVE-2024-56651",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50248",
                        "url": "https://ubuntu.com/security/CVE-2024-50248",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-0995",
                        "url": "https://ubuntu.com/security/CVE-2022-0995",
                        "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                        "cve_priority": "high",
                        "cve_public_date": "2022-03-25 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21701",
                        "url": "https://ubuntu.com/security/CVE-2025-21701",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-57798",
                        "url": "https://ubuntu.com/security/CVE-2024-57798",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-01-11 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56658",
                        "url": "https://ubuntu.com/security/CVE-2024-56658",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                        "cve_priority": "high",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-35864",
                        "url": "https://ubuntu.com/security/CVE-2024-35864",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-05-19 09:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26928",
                        "url": "https://ubuntu.com/security/CVE-2024-26928",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-28 12:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2102572,
                    2104380,
                    2102587,
                    2096976,
                    2097824
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26837",
                                "url": "https://ubuntu.com/security/CVE-2024-26837",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21756",
                                "url": "https://ubuntu.com/security/CVE-2025-21756",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-27 03:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50256",
                                "url": "https://ubuntu.com/security/CVE-2024-50256",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21702",
                                "url": "https://ubuntu.com/security/CVE-2025-21702",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21703",
                                "url": "https://ubuntu.com/security/CVE-2025-21703",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21700",
                                "url": "https://ubuntu.com/security/CVE-2025-21700",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-46826",
                                "url": "https://ubuntu.com/security/CVE-2024-46826",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-09-27 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56651",
                                "url": "https://ubuntu.com/security/CVE-2024-56651",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50248",
                                "url": "https://ubuntu.com/security/CVE-2024-50248",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-0995",
                                "url": "https://ubuntu.com/security/CVE-2022-0995",
                                "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                                "cve_priority": "high",
                                "cve_public_date": "2022-03-25 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21701",
                                "url": "https://ubuntu.com/security/CVE-2025-21701",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-57798",
                                "url": "https://ubuntu.com/security/CVE-2024-57798",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-01-11 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56658",
                                "url": "https://ubuntu.com/security/CVE-2024-56658",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                                "cve_priority": "high",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-35864",
                                "url": "https://ubuntu.com/security/CVE-2024-35864",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-05-19 09:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26928",
                                "url": "https://ubuntu.com/security/CVE-2024-26928",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-28 12:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1078.83 -proposed tracker (LP: #2102572)",
                            "",
                            "  * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport",
                            "    (LP: #2104380)",
                            "    - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n",
                            "",
                            "  [ Ubuntu: 5.15.0-138.148 ]",
                            "",
                            "  * jammy/linux: 5.15.0-138.148 -proposed tracker (LP: #2102587)",
                            "  * ipsec_offload in rtnetlink.sh from ubunsu_kselftests_net fails on O/J",
                            "    (LP: #2096976)",
                            "    - SAUCE: selftest: netfilter: fix null IP field in kci_test_ipsec_offload",
                            "  * CVE-2025-21756",
                            "    - vsock: Keep the binding until socket destruction",
                            "    - vsock: Orphan socket after transport release",
                            "  * CVE-2024-50256",
                            "    - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()",
                            "  * CVE-2025-21702",
                            "    - pfifo_tail_enqueue: Drop new packet when sch->limit == 0",
                            "  * CVE-2025-21703",
                            "    - netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()",
                            "  * CVE-2025-21700",
                            "    - net: sched: Disallow replacing of child qdisc from one parent to another",
                            "  * CVE-2024-46826",
                            "    - ELF: fix kernel.randomize_va_space double read",
                            "  * CVE-2024-56651",
                            "    - can: hi311x: hi3110_can_ist(): fix potential use-after-free",
                            "  * iBFT iSCSI out-of-bounds shift UBSAN warning (LP: #2097824)",
                            "    - iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()",
                            "  * CVE-2024-50248",
                            "    - ntfs3: Add bounds checking to mi_enum_attr()",
                            "    - fs/ntfs3: Sequential field availability check in mi_enum_attr()",
                            "  * CVE-2022-0995",
                            "    - watch_queue: Use the bitmap API when applicable",
                            "  * CVE-2024-26837",
                            "    - net: bridge: switchdev: Skip MDB replays of deferred events on offload",
                            "  * CVE-2025-21701",
                            "    - net: avoid race between device unregistration and ethnl ops",
                            "  * CVE-2024-57798",
                            "    - drm/dp_mst: Skip CSN if topology probing is not done yet",
                            "    - drm/dp_mst: Ensure mst_primary pointer is valid in",
                            "      drm_dp_mst_handle_up_req()",
                            "  * CVE-2024-56658",
                            "    - net: defer final 'struct net' free in netns dismantle",
                            "  * CVE-2024-35864",
                            "    - smb: client: fix potential UAF in smb2_is_valid_lease_break()",
                            "  * CVE-2024-35864/CVE-2024-26928",
                            "    - smb: client: fix potential UAF in cifs_debug_files_proc_show()",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1078.83",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2102572,
                            2104380,
                            2102587,
                            2096976,
                            2097824
                        ],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 16:48:45 +0100"
                    }
                ],
                "notes": "linux-headers-5.15.0-1078-kvm version '5.15.0-1078.83' (source package linux-kvm version '5.15.0-1078.83') was added. linux-headers-5.15.0-1078-kvm version '5.15.0-1078.83' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1077-kvm. As such we can use the source package version of the removed package, '5.15.0-1077.82', 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.",
                "is_version_downgrade": false
            },
            {
                "name": "linux-image-5.15.0-1078-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1078.83",
                    "version": "5.15.0-1078.83"
                },
                "cves": [],
                "launchpad_bugs_fixed": [
                    1786013
                ],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Main version: 5.15.0-1078.83",
                            "",
                            "  * Packaging resync (LP: #1786013)",
                            "    - [Packaging] debian/tracking-bug -- resync from main package",
                            ""
                        ],
                        "package": "linux-signed-kvm",
                        "version": "5.15.0-1078.83",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            1786013
                        ],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 17:08:28 +0100"
                    }
                ],
                "notes": "linux-image-5.15.0-1078-kvm version '5.15.0-1078.83' (source package linux-signed-kvm version '5.15.0-1078.83') was added. linux-image-5.15.0-1078-kvm version '5.15.0-1078.83' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1077-kvm. As such we can use the source package version of the removed package, '5.15.0-1077.82', 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.",
                "is_version_downgrade": false
            },
            {
                "name": "linux-kvm-headers-5.15.0-1078",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1078.83",
                    "version": "5.15.0-1078.83"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26837",
                        "url": "https://ubuntu.com/security/CVE-2024-26837",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21756",
                        "url": "https://ubuntu.com/security/CVE-2025-21756",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-27 03:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50256",
                        "url": "https://ubuntu.com/security/CVE-2024-50256",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21702",
                        "url": "https://ubuntu.com/security/CVE-2025-21702",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21703",
                        "url": "https://ubuntu.com/security/CVE-2025-21703",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21700",
                        "url": "https://ubuntu.com/security/CVE-2025-21700",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-46826",
                        "url": "https://ubuntu.com/security/CVE-2024-46826",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-09-27 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56651",
                        "url": "https://ubuntu.com/security/CVE-2024-56651",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50248",
                        "url": "https://ubuntu.com/security/CVE-2024-50248",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-0995",
                        "url": "https://ubuntu.com/security/CVE-2022-0995",
                        "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                        "cve_priority": "high",
                        "cve_public_date": "2022-03-25 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21701",
                        "url": "https://ubuntu.com/security/CVE-2025-21701",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-57798",
                        "url": "https://ubuntu.com/security/CVE-2024-57798",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-01-11 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56658",
                        "url": "https://ubuntu.com/security/CVE-2024-56658",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                        "cve_priority": "high",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-35864",
                        "url": "https://ubuntu.com/security/CVE-2024-35864",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-05-19 09:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26928",
                        "url": "https://ubuntu.com/security/CVE-2024-26928",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-28 12:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2102572,
                    2104380,
                    2102587,
                    2096976,
                    2097824
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26837",
                                "url": "https://ubuntu.com/security/CVE-2024-26837",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21756",
                                "url": "https://ubuntu.com/security/CVE-2025-21756",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-27 03:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50256",
                                "url": "https://ubuntu.com/security/CVE-2024-50256",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21702",
                                "url": "https://ubuntu.com/security/CVE-2025-21702",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21703",
                                "url": "https://ubuntu.com/security/CVE-2025-21703",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21700",
                                "url": "https://ubuntu.com/security/CVE-2025-21700",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-46826",
                                "url": "https://ubuntu.com/security/CVE-2024-46826",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-09-27 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56651",
                                "url": "https://ubuntu.com/security/CVE-2024-56651",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50248",
                                "url": "https://ubuntu.com/security/CVE-2024-50248",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-0995",
                                "url": "https://ubuntu.com/security/CVE-2022-0995",
                                "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                                "cve_priority": "high",
                                "cve_public_date": "2022-03-25 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21701",
                                "url": "https://ubuntu.com/security/CVE-2025-21701",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-57798",
                                "url": "https://ubuntu.com/security/CVE-2024-57798",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-01-11 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56658",
                                "url": "https://ubuntu.com/security/CVE-2024-56658",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                                "cve_priority": "high",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-35864",
                                "url": "https://ubuntu.com/security/CVE-2024-35864",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-05-19 09:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26928",
                                "url": "https://ubuntu.com/security/CVE-2024-26928",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-28 12:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1078.83 -proposed tracker (LP: #2102572)",
                            "",
                            "  * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport",
                            "    (LP: #2104380)",
                            "    - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n",
                            "",
                            "  [ Ubuntu: 5.15.0-138.148 ]",
                            "",
                            "  * jammy/linux: 5.15.0-138.148 -proposed tracker (LP: #2102587)",
                            "  * ipsec_offload in rtnetlink.sh from ubunsu_kselftests_net fails on O/J",
                            "    (LP: #2096976)",
                            "    - SAUCE: selftest: netfilter: fix null IP field in kci_test_ipsec_offload",
                            "  * CVE-2025-21756",
                            "    - vsock: Keep the binding until socket destruction",
                            "    - vsock: Orphan socket after transport release",
                            "  * CVE-2024-50256",
                            "    - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()",
                            "  * CVE-2025-21702",
                            "    - pfifo_tail_enqueue: Drop new packet when sch->limit == 0",
                            "  * CVE-2025-21703",
                            "    - netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()",
                            "  * CVE-2025-21700",
                            "    - net: sched: Disallow replacing of child qdisc from one parent to another",
                            "  * CVE-2024-46826",
                            "    - ELF: fix kernel.randomize_va_space double read",
                            "  * CVE-2024-56651",
                            "    - can: hi311x: hi3110_can_ist(): fix potential use-after-free",
                            "  * iBFT iSCSI out-of-bounds shift UBSAN warning (LP: #2097824)",
                            "    - iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()",
                            "  * CVE-2024-50248",
                            "    - ntfs3: Add bounds checking to mi_enum_attr()",
                            "    - fs/ntfs3: Sequential field availability check in mi_enum_attr()",
                            "  * CVE-2022-0995",
                            "    - watch_queue: Use the bitmap API when applicable",
                            "  * CVE-2024-26837",
                            "    - net: bridge: switchdev: Skip MDB replays of deferred events on offload",
                            "  * CVE-2025-21701",
                            "    - net: avoid race between device unregistration and ethnl ops",
                            "  * CVE-2024-57798",
                            "    - drm/dp_mst: Skip CSN if topology probing is not done yet",
                            "    - drm/dp_mst: Ensure mst_primary pointer is valid in",
                            "      drm_dp_mst_handle_up_req()",
                            "  * CVE-2024-56658",
                            "    - net: defer final 'struct net' free in netns dismantle",
                            "  * CVE-2024-35864",
                            "    - smb: client: fix potential UAF in smb2_is_valid_lease_break()",
                            "  * CVE-2024-35864/CVE-2024-26928",
                            "    - smb: client: fix potential UAF in cifs_debug_files_proc_show()",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1078.83",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2102572,
                            2104380,
                            2102587,
                            2096976,
                            2097824
                        ],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 16:48:45 +0100"
                    }
                ],
                "notes": "linux-kvm-headers-5.15.0-1078 version '5.15.0-1078.83' (source package linux-kvm version '5.15.0-1078.83') was added. linux-kvm-headers-5.15.0-1078 version '5.15.0-1078.83' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1077-kvm. As such we can use the source package version of the removed package, '5.15.0-1077.82', 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.",
                "is_version_downgrade": false
            },
            {
                "name": "linux-modules-5.15.0-1078-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1078.83",
                    "version": "5.15.0-1078.83"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-26837",
                        "url": "https://ubuntu.com/security/CVE-2024-26837",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-04-17 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21756",
                        "url": "https://ubuntu.com/security/CVE-2025-21756",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-27 03:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50256",
                        "url": "https://ubuntu.com/security/CVE-2024-50256",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21702",
                        "url": "https://ubuntu.com/security/CVE-2025-21702",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21703",
                        "url": "https://ubuntu.com/security/CVE-2025-21703",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-18 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21700",
                        "url": "https://ubuntu.com/security/CVE-2025-21700",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-46826",
                        "url": "https://ubuntu.com/security/CVE-2024-46826",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-09-27 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56651",
                        "url": "https://ubuntu.com/security/CVE-2024-56651",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50248",
                        "url": "https://ubuntu.com/security/CVE-2024-50248",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-09 11:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-0995",
                        "url": "https://ubuntu.com/security/CVE-2022-0995",
                        "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                        "cve_priority": "high",
                        "cve_public_date": "2022-03-25 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21701",
                        "url": "https://ubuntu.com/security/CVE-2025-21701",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-02-13 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-57798",
                        "url": "https://ubuntu.com/security/CVE-2024-57798",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-01-11 13:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-56658",
                        "url": "https://ubuntu.com/security/CVE-2024-56658",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                        "cve_priority": "high",
                        "cve_public_date": "2024-12-27 15:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-35864",
                        "url": "https://ubuntu.com/security/CVE-2024-35864",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-05-19 09:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-26928",
                        "url": "https://ubuntu.com/security/CVE-2024-26928",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                        "cve_priority": "high",
                        "cve_public_date": "2024-04-28 12:15:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2102572,
                    2104380,
                    2102587,
                    2096976,
                    2097824
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-26837",
                                "url": "https://ubuntu.com/security/CVE-2024-26837",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-04-17 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21756",
                                "url": "https://ubuntu.com/security/CVE-2025-21756",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  vsock: Keep the binding until socket destruction  Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().  Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:      1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)     2. transport->release() calls vsock_remove_bound() without checking if        sk was bound and moved to bound list (refcnt=1)     3. vsock_bind() assumes sk is in unbound list and before        __vsock_insert_bound(vsock_bound_sockets()) calls        __vsock_remove_bound() which does:            list_del_init(&vsk->bound_table); // nop            sock_put(&vsk->sk);               // refcnt=0  BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057  dump_stack_lvl+0x68/0x90  print_report+0x174/0x4f6  kasan_report+0xb9/0x190  __vsock_bind+0x62e/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Allocated by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  __kasan_slab_alloc+0x85/0x90  kmem_cache_alloc_noprof+0x131/0x450  sk_prot_alloc+0x5b/0x220  sk_alloc+0x2c/0x870  __vsock_create.constprop.0+0x2e/0xb60  vsock_create+0xe4/0x420  __sock_create+0x241/0x650  __sys_socket+0xf2/0x1a0  __x64_sys_socket+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 2057:  kasan_save_stack+0x1e/0x40  kasan_save_track+0x10/0x30  kasan_save_free_info+0x37/0x60  __kasan_slab_free+0x4b/0x70  kmem_cache_free+0x1a1/0x590  __sk_destruct+0x388/0x5a0  __vsock_bind+0x5e1/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150  __vsock_bind+0x66d/0x730  vsock_bind+0x97/0xe0  __sys_bind+0x154/0x1f0  __x64_sys_bind+0x6e/0xb0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150  vsock_remove_bound+0x187/0x1e0  __vsock_release+0x383/0x4a0  vsock_release+0x90/0x120  __sock_release+0xa3/0x250  sock_close+0x14/0x20  __fput+0x359/0xa80  task_work_run+0x107/0x1d0  do_exit+0x847/0x2560  do_group_exit+0xb8/0x250  __x64_sys_exit_group+0x3a/0x50  x64_sys_call+0xfec/0x14f0  do_syscall_64+0x93/0x1b0  entry_SYSCALL_64_after_hwframe+0x76/0x7e",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-27 03:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50256",
                                "url": "https://ubuntu.com/security/CVE-2024-50256",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  I got a syzbot report without a repro [1] crashing in nf_send_reset6()  I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header.  Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  [1]  skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   eth_header+0x38/0x1f0 net/ethernet/eth.c:83   dev_hard_header include/linux/netdevice.h:3208 [inline]   nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358   nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]   br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424   __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562   __netif_receive_skb_one_core net/core/dev.c:5666 [inline]   __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781   netif_receive_skb_internal net/core/dev.c:5867 [inline]   netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926   tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550   tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007   tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053   new_sync_write fs/read_write.c:590 [inline]   vfs_write+0xa6d/0xc90 fs/read_write.c:683   ksys_write+0x183/0x2b0 fs/read_write.c:736   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21702",
                                "url": "https://ubuntu.com/security/CVE-2025-21702",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  pfifo_tail_enqueue: Drop new packet when sch->limit == 0  Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.  Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.  The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B.  - Qdisc_A's type must have '->graft()' function to create parent/child relationship.    Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.  - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.  - Qdisc_B is configured to have `sch->limit == 0`.  - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.  Enqueue packet through Qdisc_A will lead to:  - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)  - Qdisc_B->q.qlen += 1  - pfifo_tail_enqueue() return `NET_XMIT_CN`  - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.  The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.  Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21703",
                                "url": "https://ubuntu.com/security/CVE-2025-21703",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()  qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-18 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21700",
                                "url": "https://ubuntu.com/security/CVE-2025-21700",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: sched: Disallow replacing of child qdisc from one parent to another  Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script  Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr  step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr  step3. a class for nesting tc class add dev lo classid 1:2 drr  step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr  step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024  step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr  step7. tc class add dev lo classid 3:1 drr  step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo  step 9. Display the class/qdisc layout  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 limit 1000p  qdisc drr 3: dev lo parent 1:2  step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0  step 11. Redisplay again the qdiscs/classes  tc class ls dev lo  class drr 1:1 root leaf 2: quantum 64Kb  class drr 1:2 root leaf 3: quantum 64Kb  class drr 1:3 root leaf 4: quantum 64Kb  class drr 3:1 root leaf 4: quantum 64Kb  tc qdisc ls  qdisc drr 1: dev lo root refcnt 2  qdisc plug 2: dev lo parent 1:1  qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p  qdisc drr 3: dev lo parent 1:2  Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent.  b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.  Step 12.  send one packet to plug echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13.  send one packet to the grafted fifo echo \"\" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))  step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1  The semantics of \"replace\" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could \"fix\" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of \"disallow such config\".  Joint work with Lion Ackermann <nnamrec@gmail.com>",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-46826",
                                "url": "https://ubuntu.com/security/CVE-2024-46826",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ELF: fix kernel.randomize_va_space double read  ELF loader uses \"randomize_va_space\" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.  Issue exactly one load for consistent value across one exec.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-09-27 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56651",
                                "url": "https://ubuntu.com/security/CVE-2024-56651",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  can: hi311x: hi3110_can_ist(): fix potential use-after-free  The commit a22bd630cfff (\"can: hi311x: do not report txerr and rxerr during bus-off\") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).  The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.  Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50248",
                                "url": "https://ubuntu.com/security/CVE-2024-50248",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don't stray beyond valid memory region.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-09 11:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-0995",
                                "url": "https://ubuntu.com/security/CVE-2022-0995",
                                "cve_description": "An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.",
                                "cve_priority": "high",
                                "cve_public_date": "2022-03-25 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21701",
                                "url": "https://ubuntu.com/security/CVE-2025-21701",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: avoid race between device unregistration and ethnl ops  The following trace can be seen if a device is being unregistered while its number of channels are being modified.    DEBUG_LOCKS_WARN_ON(lock->magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    <TASK>    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea.  Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough.  Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-02-13 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-57798",
                                "url": "https://ubuntu.com/security/CVE-2024-57798",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()  While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req().  Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used.  v2: Fix kfreeing the request if getting an mst_primary reference fails.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-01-11 13:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-56658",
                                "url": "https://ubuntu.com/security/CVE-2024-56658",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  net: defer final 'struct net' free in netns dismantle  Ilya reported a slab-use-after-free in dst_destroy [1]  Issue is in xfrm6_net_init() and xfrm4_net_init() :  They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.  But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :  if (dst->ops->destroy)     dst->ops->destroy(dst);  dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.  See a relevant issue fixed in :  ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\")  A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier())  [1]  BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace:  <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)  </IRQ>  <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414)  </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated---",
                                "cve_priority": "high",
                                "cve_public_date": "2024-12-27 15:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-35864",
                                "url": "https://ubuntu.com/security/CVE-2024-35864",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-05-19 09:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-26928",
                                "url": "https://ubuntu.com/security/CVE-2024-26928",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.",
                                "cve_priority": "high",
                                "cve_public_date": "2024-04-28 12:15:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1078.83 -proposed tracker (LP: #2102572)",
                            "",
                            "  * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport",
                            "    (LP: #2104380)",
                            "    - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n",
                            "",
                            "  [ Ubuntu: 5.15.0-138.148 ]",
                            "",
                            "  * jammy/linux: 5.15.0-138.148 -proposed tracker (LP: #2102587)",
                            "  * ipsec_offload in rtnetlink.sh from ubunsu_kselftests_net fails on O/J",
                            "    (LP: #2096976)",
                            "    - SAUCE: selftest: netfilter: fix null IP field in kci_test_ipsec_offload",
                            "  * CVE-2025-21756",
                            "    - vsock: Keep the binding until socket destruction",
                            "    - vsock: Orphan socket after transport release",
                            "  * CVE-2024-50256",
                            "    - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()",
                            "  * CVE-2025-21702",
                            "    - pfifo_tail_enqueue: Drop new packet when sch->limit == 0",
                            "  * CVE-2025-21703",
                            "    - netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()",
                            "  * CVE-2025-21700",
                            "    - net: sched: Disallow replacing of child qdisc from one parent to another",
                            "  * CVE-2024-46826",
                            "    - ELF: fix kernel.randomize_va_space double read",
                            "  * CVE-2024-56651",
                            "    - can: hi311x: hi3110_can_ist(): fix potential use-after-free",
                            "  * iBFT iSCSI out-of-bounds shift UBSAN warning (LP: #2097824)",
                            "    - iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()",
                            "  * CVE-2024-50248",
                            "    - ntfs3: Add bounds checking to mi_enum_attr()",
                            "    - fs/ntfs3: Sequential field availability check in mi_enum_attr()",
                            "  * CVE-2022-0995",
                            "    - watch_queue: Use the bitmap API when applicable",
                            "  * CVE-2024-26837",
                            "    - net: bridge: switchdev: Skip MDB replays of deferred events on offload",
                            "  * CVE-2025-21701",
                            "    - net: avoid race between device unregistration and ethnl ops",
                            "  * CVE-2024-57798",
                            "    - drm/dp_mst: Skip CSN if topology probing is not done yet",
                            "    - drm/dp_mst: Ensure mst_primary pointer is valid in",
                            "      drm_dp_mst_handle_up_req()",
                            "  * CVE-2024-56658",
                            "    - net: defer final 'struct net' free in netns dismantle",
                            "  * CVE-2024-35864",
                            "    - smb: client: fix potential UAF in smb2_is_valid_lease_break()",
                            "  * CVE-2024-35864/CVE-2024-26928",
                            "    - smb: client: fix potential UAF in cifs_debug_files_proc_show()",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1078.83",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2102572,
                            2104380,
                            2102587,
                            2096976,
                            2097824
                        ],
                        "author": "Stefan Bader <stefan.bader@canonical.com>",
                        "date": "Thu, 27 Mar 2025 16:48:45 +0100"
                    }
                ],
                "notes": "linux-modules-5.15.0-1078-kvm version '5.15.0-1078.83' (source package linux-kvm version '5.15.0-1078.83') was added. linux-modules-5.15.0-1078-kvm version '5.15.0-1078.83' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1077-kvm. As such we can use the source package version of the removed package, '5.15.0-1077.82', 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.",
                "is_version_downgrade": false
            }
        ],
        "snap": []
    },
    "removed": {
        "deb": [
            {
                "name": "linux-headers-5.15.0-1077-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": "5.15.0-1077.82"
                },
                "to_version": {
                    "source_package_name": null,
                    "source_package_version": null,
                    "version": null
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-image-5.15.0-1077-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": "5.15.0-1077.82"
                },
                "to_version": {
                    "source_package_name": null,
                    "source_package_version": null,
                    "version": null
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-kvm-headers-5.15.0-1077",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": "5.15.0-1077.82"
                },
                "to_version": {
                    "source_package_name": null,
                    "source_package_version": null,
                    "version": null
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-modules-5.15.0-1077-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1077.82",
                    "version": "5.15.0-1077.82"
                },
                "to_version": {
                    "source_package_name": null,
                    "source_package_version": null,
                    "version": null
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [],
                "notes": null,
                "is_version_downgrade": false
            }
        ],
        "snap": []
    },
    "notes": "Changelog diff for Ubuntu 22.04 jammy image from daily image serial 20250414 to 20250416",
    "from_series": "jammy",
    "to_series": "jammy",
    "from_serial": "20250414",
    "to_serial": "20250416",
    "from_manifest_filename": "daily_manifest.previous",
    "to_manifest_filename": "manifest.current"
}