{
    "summary": {
        "snap": {
            "added": [],
            "removed": [],
            "diff": []
        },
        "deb": {
            "added": [
                "linux-headers-5.15.0-1090-kvm",
                "linux-image-5.15.0-1090-kvm",
                "linux-kvm-headers-5.15.0-1090",
                "linux-modules-5.15.0-1090-kvm"
            ],
            "removed": [
                "linux-headers-5.15.0-1089-kvm",
                "linux-image-5.15.0-1089-kvm",
                "linux-kvm-headers-5.15.0-1089",
                "linux-modules-5.15.0-1089-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.1089.85",
                    "version": "5.15.0.1089.85"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1090.86",
                    "version": "5.15.0.1090.86"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1090",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1090.86",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:12:50 +0800"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-image-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1089.85",
                    "version": "5.15.0.1089.85"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1090.86",
                    "version": "5.15.0.1090.86"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1090",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1090.86",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:12:50 +0800"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            },
            {
                "name": "linux-kvm",
                "from_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1089.85",
                    "version": "5.15.0.1089.85"
                },
                "to_version": {
                    "source_package_name": "linux-meta-kvm",
                    "source_package_version": "5.15.0.1090.86",
                    "version": "5.15.0.1090.86"
                },
                "cves": [],
                "launchpad_bugs_fixed": [],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Bump ABI 5.15.0-1090",
                            ""
                        ],
                        "package": "linux-meta-kvm",
                        "version": "5.15.0.1090.86",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:12:50 +0800"
                    }
                ],
                "notes": null,
                "is_version_downgrade": false
            }
        ],
        "snap": []
    },
    "added": {
        "deb": [
            {
                "name": "linux-headers-5.15.0-1090-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1090.95",
                    "version": "5.15.0-1090.95"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-53218",
                        "url": "https://ubuntu.com/security/CVE-2024-53218",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                        "cve_priority": "low",
                        "cve_public_date": "2024-12-27 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-47691",
                        "url": "https://ubuntu.com/security/CVE-2024-47691",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-10-21 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39993",
                        "url": "https://ubuntu.com/security/CVE-2025-39993",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-15 08:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-40018",
                        "url": "https://ubuntu.com/security/CVE-2025-40018",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-24 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21855",
                        "url": "https://ubuntu.com/security/CVE-2025-21855",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-03-12 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50067",
                        "url": "https://ubuntu.com/security/CVE-2024-50067",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-10-28 01:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-53090",
                        "url": "https://ubuntu.com/security/CVE-2024-53090",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-21 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39964",
                        "url": "https://ubuntu.com/security/CVE-2025-39964",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-13 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-49390",
                        "url": "https://ubuntu.com/security/CVE-2022-49390",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-02-26 07:01:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2131414,
                    2131429,
                    2130552
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-53218",
                                "url": "https://ubuntu.com/security/CVE-2024-53218",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                                "cve_priority": "low",
                                "cve_public_date": "2024-12-27 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-47691",
                                "url": "https://ubuntu.com/security/CVE-2024-47691",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-10-21 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39993",
                                "url": "https://ubuntu.com/security/CVE-2025-39993",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-15 08:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-40018",
                                "url": "https://ubuntu.com/security/CVE-2025-40018",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-24 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21855",
                                "url": "https://ubuntu.com/security/CVE-2025-21855",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-03-12 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50067",
                                "url": "https://ubuntu.com/security/CVE-2024-50067",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-10-28 01:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-53090",
                                "url": "https://ubuntu.com/security/CVE-2024-53090",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-21 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39964",
                                "url": "https://ubuntu.com/security/CVE-2025-39964",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-13 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-49390",
                                "url": "https://ubuntu.com/security/CVE-2022-49390",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-02-26 07:01:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1090.95 -proposed tracker (LP: #2131414)",
                            "",
                            "  [ Ubuntu: 5.15.0-164.174 ]",
                            "",
                            "  * jammy/linux: 5.15.0-164.174 -proposed tracker (LP: #2131429)",
                            "  * CVE-2024-53218",
                            "    - f2fs: fix race in concurrent f2fs_stop_gc_thread",
                            "  * CVE-2024-47691",
                            "    - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()",
                            "  * CVE-2025-39993",
                            "    - media: rc: fix races with imon_disconnect()",
                            "  * i40e driver is triggering VF resets on every link state change",
                            "    (LP: #2130552)",
                            "    - i40e: avoid redundant VF link state updates",
                            "  * CVE-2025-40018",
                            "    - ipvs: Defer ip_vs_ftp unregister during netns cleanup",
                            "  * CVE-2025-21855",
                            "    - ibmvnic: Don't reference skb after sending to VIOS",
                            "  * CVE-2024-50067",
                            "    - uprobes: encapsulate preparation of uprobe args buffer",
                            "    - uprobe: avoid out-of-bounds memory access of fetching args",
                            "  * CVE-2024-53090",
                            "    - afs: Fix lock recursion",
                            "  * CVE-2025-39964",
                            "    - crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg",
                            "    - crypto: af_alg - Fix incorrect boolean values in af_alg_ctx",
                            "  * CVE-2022-49390",
                            "    - macsec: fix UAF bug for real_dev",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1090.95",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2131414,
                            2131429,
                            2130552
                        ],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:35:12 +0800"
                    }
                ],
                "notes": "linux-headers-5.15.0-1090-kvm version '5.15.0-1090.95' (source package linux-kvm version '5.15.0-1090.95') was added. linux-headers-5.15.0-1090-kvm version '5.15.0-1090.95' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1089-kvm. As such we can use the source package version of the removed package, '5.15.0-1089.94', 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-1090-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1090.95",
                    "version": "5.15.0-1090.95"
                },
                "cves": [],
                "launchpad_bugs_fixed": [
                    1786013
                ],
                "changes": [
                    {
                        "cves": [],
                        "log": [
                            "",
                            "  * Main version: 5.15.0-1090.95",
                            "",
                            "  * Packaging resync (LP: #1786013)",
                            "    - [Packaging] debian/tracking-bug -- resync from main package",
                            ""
                        ],
                        "package": "linux-signed-kvm",
                        "version": "5.15.0-1090.95",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            1786013
                        ],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:13:14 +0800"
                    }
                ],
                "notes": "linux-image-5.15.0-1090-kvm version '5.15.0-1090.95' (source package linux-signed-kvm version '5.15.0-1090.95') was added. linux-image-5.15.0-1090-kvm version '5.15.0-1090.95' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1089-kvm. As such we can use the source package version of the removed package, '5.15.0-1089.94', 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-1090",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1090.95",
                    "version": "5.15.0-1090.95"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-53218",
                        "url": "https://ubuntu.com/security/CVE-2024-53218",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                        "cve_priority": "low",
                        "cve_public_date": "2024-12-27 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-47691",
                        "url": "https://ubuntu.com/security/CVE-2024-47691",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-10-21 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39993",
                        "url": "https://ubuntu.com/security/CVE-2025-39993",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-15 08:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-40018",
                        "url": "https://ubuntu.com/security/CVE-2025-40018",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-24 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21855",
                        "url": "https://ubuntu.com/security/CVE-2025-21855",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-03-12 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50067",
                        "url": "https://ubuntu.com/security/CVE-2024-50067",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-10-28 01:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-53090",
                        "url": "https://ubuntu.com/security/CVE-2024-53090",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-21 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39964",
                        "url": "https://ubuntu.com/security/CVE-2025-39964",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-13 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-49390",
                        "url": "https://ubuntu.com/security/CVE-2022-49390",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-02-26 07:01:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2131414,
                    2131429,
                    2130552
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-53218",
                                "url": "https://ubuntu.com/security/CVE-2024-53218",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                                "cve_priority": "low",
                                "cve_public_date": "2024-12-27 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-47691",
                                "url": "https://ubuntu.com/security/CVE-2024-47691",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-10-21 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39993",
                                "url": "https://ubuntu.com/security/CVE-2025-39993",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-15 08:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-40018",
                                "url": "https://ubuntu.com/security/CVE-2025-40018",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-24 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21855",
                                "url": "https://ubuntu.com/security/CVE-2025-21855",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-03-12 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50067",
                                "url": "https://ubuntu.com/security/CVE-2024-50067",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-10-28 01:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-53090",
                                "url": "https://ubuntu.com/security/CVE-2024-53090",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-21 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39964",
                                "url": "https://ubuntu.com/security/CVE-2025-39964",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-13 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-49390",
                                "url": "https://ubuntu.com/security/CVE-2022-49390",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-02-26 07:01:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1090.95 -proposed tracker (LP: #2131414)",
                            "",
                            "  [ Ubuntu: 5.15.0-164.174 ]",
                            "",
                            "  * jammy/linux: 5.15.0-164.174 -proposed tracker (LP: #2131429)",
                            "  * CVE-2024-53218",
                            "    - f2fs: fix race in concurrent f2fs_stop_gc_thread",
                            "  * CVE-2024-47691",
                            "    - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()",
                            "  * CVE-2025-39993",
                            "    - media: rc: fix races with imon_disconnect()",
                            "  * i40e driver is triggering VF resets on every link state change",
                            "    (LP: #2130552)",
                            "    - i40e: avoid redundant VF link state updates",
                            "  * CVE-2025-40018",
                            "    - ipvs: Defer ip_vs_ftp unregister during netns cleanup",
                            "  * CVE-2025-21855",
                            "    - ibmvnic: Don't reference skb after sending to VIOS",
                            "  * CVE-2024-50067",
                            "    - uprobes: encapsulate preparation of uprobe args buffer",
                            "    - uprobe: avoid out-of-bounds memory access of fetching args",
                            "  * CVE-2024-53090",
                            "    - afs: Fix lock recursion",
                            "  * CVE-2025-39964",
                            "    - crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg",
                            "    - crypto: af_alg - Fix incorrect boolean values in af_alg_ctx",
                            "  * CVE-2022-49390",
                            "    - macsec: fix UAF bug for real_dev",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1090.95",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2131414,
                            2131429,
                            2130552
                        ],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:35:12 +0800"
                    }
                ],
                "notes": "linux-kvm-headers-5.15.0-1090 version '5.15.0-1090.95' (source package linux-kvm version '5.15.0-1090.95') was added. linux-kvm-headers-5.15.0-1090 version '5.15.0-1090.95' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1089-kvm. As such we can use the source package version of the removed package, '5.15.0-1089.94', 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-1090-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": null
                },
                "to_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1090.95",
                    "version": "5.15.0-1090.95"
                },
                "cves": [
                    {
                        "cve": "CVE-2024-53218",
                        "url": "https://ubuntu.com/security/CVE-2024-53218",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                        "cve_priority": "low",
                        "cve_public_date": "2024-12-27 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-47691",
                        "url": "https://ubuntu.com/security/CVE-2024-47691",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                        "cve_priority": "low",
                        "cve_public_date": "2024-10-21 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39993",
                        "url": "https://ubuntu.com/security/CVE-2025-39993",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-15 08:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-40018",
                        "url": "https://ubuntu.com/security/CVE-2025-40018",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-24 12:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-21855",
                        "url": "https://ubuntu.com/security/CVE-2025-21855",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-03-12 10:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-50067",
                        "url": "https://ubuntu.com/security/CVE-2024-50067",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-10-28 01:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2024-53090",
                        "url": "https://ubuntu.com/security/CVE-2024-53090",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                        "cve_priority": "medium",
                        "cve_public_date": "2024-11-21 19:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2025-39964",
                        "url": "https://ubuntu.com/security/CVE-2025-39964",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                        "cve_priority": "medium",
                        "cve_public_date": "2025-10-13 14:15:00 UTC"
                    },
                    {
                        "cve": "CVE-2022-49390",
                        "url": "https://ubuntu.com/security/CVE-2022-49390",
                        "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                        "cve_priority": "high",
                        "cve_public_date": "2025-02-26 07:01:00 UTC"
                    }
                ],
                "launchpad_bugs_fixed": [
                    2131414,
                    2131429,
                    2130552
                ],
                "changes": [
                    {
                        "cves": [
                            {
                                "cve": "CVE-2024-53218",
                                "url": "https://ubuntu.com/security/CVE-2024-53218",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().",
                                "cve_priority": "low",
                                "cve_public_date": "2024-12-27 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-47691",
                                "url": "https://ubuntu.com/security/CVE-2024-47691",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  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  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t  - f2fs_stop_gc_thread \t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.",
                                "cve_priority": "low",
                                "cve_public_date": "2024-10-21 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39993",
                                "url": "https://ubuntu.com/security/CVE-2025-39993",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  media: rc: fix races with imon_disconnect()  Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465  CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace:  <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.  Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.  As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.  Thread 1 vfd_write                      Thread 2 imon_disconnect                                         ...                                         if                                           usb_put_dev(ictx->usbdev_intf0)                                         else                                           usb_put_dev(ictx->usbdev_intf1) ... while   send_packet     if       pipe = usb_sndintpipe(         ictx->usbdev_intf0) UAF     else       pipe = usb_sndctrlpipe(         ictx->usbdev_intf0, 0) UAF  Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.  Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.  Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-15 08:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-40018",
                                "url": "https://ubuntu.com/security/CVE-2025-40018",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-24 12:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-21855",
                                "url": "https://ubuntu.com/security/CVE-2025-21855",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: Don't reference skb after sending to VIOS  Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb.  It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free:  ==================================================================  BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  Read of size 4 at addr c00000024eb48a70 by task hxecom/14495  <...>  Call Trace:  [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)  [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0  [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8  [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0  [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]  [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358  <...>  Freed by task 0:  kasan_save_stack+0x34/0x68  kasan_save_track+0x2c/0x50  kasan_save_free_info+0x64/0x108  __kasan_mempool_poison_object+0x148/0x2d4  napi_skb_cache_put+0x5c/0x194  net_tx_action+0x154/0x5b8  handle_softirqs+0x20c/0x60c  do_softirq_own_stack+0x6c/0x88  <...>  The buggy address belongs to the object at c00000024eb48a00 which   belongs to the cache skbuff_head_cache of size 224 ==================================================================",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-03-12 10:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-50067",
                                "url": "https://ubuntu.com/security/CVE-2024-50067",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf(\"%s\\n\", str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  </TASK>  This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-10-28 01:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2024-53090",
                                "url": "https://ubuntu.com/security/CVE-2024-53090",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>",
                                "cve_priority": "medium",
                                "cve_public_date": "2024-11-21 19:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2025-39964",
                                "url": "https://ubuntu.com/security/CVE-2025-39964",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg  Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion.  Furthermore, concurrent writes may create inconsistencies in the internal socket state.  Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.",
                                "cve_priority": "medium",
                                "cve_public_date": "2025-10-13 14:15:00 UTC"
                            },
                            {
                                "cve": "CVE-2022-49390",
                                "url": "https://ubuntu.com/security/CVE-2022-49390",
                                "cve_description": "In the Linux kernel, the following vulnerability has been resolved:  macsec: fix UAF bug for real_dev  Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:  ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace:  ...  macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662  dev_get_iflink+0x73/0xe0 net/core/dev.c:637  default_operstate net/core/link_watch.c:42 [inline]  rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54  linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161  Allocated by task 22209:  ...  alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549  rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235  veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748  Freed by task 8:  ...  kfree+0xd6/0x4d0 mm/slub.c:4552  kvfree+0x42/0x50 mm/util.c:615  device_release+0x9f/0x240 drivers/base/core.c:2229  kobject_cleanup lib/kobject.c:673 [inline]  kobject_release lib/kobject.c:704 [inline]  kref_put include/linux/kref.h:65 [inline]  kobject_put+0x1c8/0x540 lib/kobject.c:721  netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327  After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.",
                                "cve_priority": "high",
                                "cve_public_date": "2025-02-26 07:01:00 UTC"
                            }
                        ],
                        "log": [
                            "",
                            "  * jammy/linux-kvm: 5.15.0-1090.95 -proposed tracker (LP: #2131414)",
                            "",
                            "  [ Ubuntu: 5.15.0-164.174 ]",
                            "",
                            "  * jammy/linux: 5.15.0-164.174 -proposed tracker (LP: #2131429)",
                            "  * CVE-2024-53218",
                            "    - f2fs: fix race in concurrent f2fs_stop_gc_thread",
                            "  * CVE-2024-47691",
                            "    - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()",
                            "  * CVE-2025-39993",
                            "    - media: rc: fix races with imon_disconnect()",
                            "  * i40e driver is triggering VF resets on every link state change",
                            "    (LP: #2130552)",
                            "    - i40e: avoid redundant VF link state updates",
                            "  * CVE-2025-40018",
                            "    - ipvs: Defer ip_vs_ftp unregister during netns cleanup",
                            "  * CVE-2025-21855",
                            "    - ibmvnic: Don't reference skb after sending to VIOS",
                            "  * CVE-2024-50067",
                            "    - uprobes: encapsulate preparation of uprobe args buffer",
                            "    - uprobe: avoid out-of-bounds memory access of fetching args",
                            "  * CVE-2024-53090",
                            "    - afs: Fix lock recursion",
                            "  * CVE-2025-39964",
                            "    - crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg",
                            "    - crypto: af_alg - Fix incorrect boolean values in af_alg_ctx",
                            "  * CVE-2022-49390",
                            "    - macsec: fix UAF bug for real_dev",
                            ""
                        ],
                        "package": "linux-kvm",
                        "version": "5.15.0-1090.95",
                        "urgency": "medium",
                        "distributions": "jammy",
                        "launchpad_bugs_fixed": [
                            2131414,
                            2131429,
                            2130552
                        ],
                        "author": "Zixing Liu <zixing.liu@canonical.com>",
                        "date": "Mon, 08 Dec 2025 10:35:12 +0800"
                    }
                ],
                "notes": "linux-modules-5.15.0-1090-kvm version '5.15.0-1090.95' (source package linux-kvm version '5.15.0-1090.95') was added. linux-modules-5.15.0-1090-kvm version '5.15.0-1090.95' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1089-kvm. As such we can use the source package version of the removed package, '5.15.0-1089.94', 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-1089-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": "5.15.0-1089.94"
                },
                "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-1089-kvm",
                "from_version": {
                    "source_package_name": "linux-signed-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": "5.15.0-1089.94"
                },
                "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-1089",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": "5.15.0-1089.94"
                },
                "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-1089-kvm",
                "from_version": {
                    "source_package_name": "linux-kvm",
                    "source_package_version": "5.15.0-1089.94",
                    "version": "5.15.0-1089.94"
                },
                "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 20251215 to 20251216",
    "from_series": "jammy",
    "to_series": "jammy",
    "from_serial": "20251215",
    "to_serial": "20251216",
    "from_manifest_filename": "daily_manifest.previous",
    "to_manifest_filename": "manifest.current"
}