{"schema_version":"1.7.2","id":"OESA-2025-2776","modified":"2025-12-05T13:12:19Z","published":"2025-12-05T13:12:19Z","upstream":["CVE-2024-58095","CVE-2025-21693","CVE-2025-22020","CVE-2025-22026","CVE-2025-22083","CVE-2025-22107","CVE-2025-23133","CVE-2025-23147","CVE-2025-23159","CVE-2025-37758","CVE-2025-37777","CVE-2025-37861","CVE-2025-37899","CVE-2025-37994","CVE-2025-37997","CVE-2025-38005","CVE-2025-38058","CVE-2025-38071","CVE-2025-38231","CVE-2025-38443","CVE-2025-38477","CVE-2025-38501","CVE-2025-38566","CVE-2025-39677","CVE-2025-39810","CVE-2025-39817","CVE-2025-39866","CVE-2025-39911","CVE-2025-39947","CVE-2025-39996","CVE-2025-40016"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: properly synchronize freeing resources during CPU hotunplug\n\nIn zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the\ncurrent CPU at the beginning of the operation is retrieved and used\nthroughout.  However, since neither preemption nor migration are disabled,\nit is possible that the operation continues on a different CPU.\n\nIf the original CPU is hotunplugged while the acomp_ctx is still in use,\nwe run into a UAF bug as some of the resources attached to the acomp_ctx\nare freed during hotunplug in zswap_cpu_comp_dead() (i.e. \nacomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).\n\nThe problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use\ncrypto_acomp API for hardware acceleration") when the switch to the\ncrypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was\nretrieved using get_cpu_ptr() which disables preemption and makes sure the\nCPU cannot go away from under us.  Preemption cannot be disabled with the\ncrypto_acomp API as a sleepable context is needed.\n\nUse the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating\nand freeing resources with compression/decompression paths.  Make sure\nthat acomp_ctx.req is NULL when the resources are freed.  In the\ncompression/decompression paths, check if acomp_ctx.req is NULL after\nacquiring the mutex (meaning the CPU was offlined) and retry on the new\nCPU.\n\nThe initialization of acomp_ctx.mutex is moved from the CPU hotplug\ncallback to the pool initialization where it belongs (where the mutex is\nallocated).  In addition to adding clarity, this makes sure that CPU\nhotplug cannot reinitialize a mutex that is already locked by\ncompression/decompression.\n\nPreviously a fix was attempted by holding cpus_read_lock() [1].  This\nwould have caused a potential deadlock as it is possible for code already\nholding the lock to fall into reclaim and enter zswap (causing a\ndeadlock).  A fix was also attempted using SRCU for synchronization, but\nJohannes pointed out that synchronize_srcu() cannot be used in CPU hotplug\nnotifiers [2].\n\nAlternative fixes that were considered/attempted and could have worked:\n- Refcounting the per-CPU acomp_ctx. This involves complexity in\n  handling the race between the refcount dropping to zero in\n  zswap_[de]compress() and the refcount being re-initialized when the\n  CPU is onlined.\n- Disabling migration before getting the per-CPU acomp_ctx [3], but\n  that's discouraged and is a much bigger hammer than needed, and could\n  result in subtle performance issues.\n\n[1]https://lkml.kernel.org/(CVE-2025-21693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n <TASK>\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don't ignore the return code of svc_proc_register()\n\nCurrently, nfsd_proc_stat_init() ignores the return value of\nsvc_proc_register(). If the procfile creation fails, then the kernel\nwill WARN when it tries to remove the entry later.\n\nFix nfsd_proc_stat_init() to return the same type of pointer as\nsvc_proc_register(), and fix up nfsd_net_init() to check that and fail\nthe nfsd_net construction if it occurs.\n\nsvc_proc_register() can fail if the dentry can't be allocated, or if an\nidentical dentry already exists. The second case is pretty unlikely in\nthe nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs->vs_tpg);\nvs->vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs->vs_tpg);\nvs->vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs->vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs->vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs->vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven't seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don't teardown the old target tpg mapping and just overwrite\nthe target name and the vs->vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2's\nname and we will only match that target's tpgs when we loop over the\nvs->vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it's already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()\n\nThere are actually 2 problems:\n- deleting the last element doesn't require the memmove of elements\n  [i + 1, end) over it. Actually, element i+1 is out of bounds.\n- The memmove itself should move size - i - 1 elements, because the last\n  element is out of bounds.\n\nThe out-of-bounds element still remains out of bounds after being\naccessed, so the problem is only that we touch it, not that it becomes\nin active use. But I suppose it can lead to issues if the out-of-bounds\nelement is part of an unmapped page.(CVE-2025-22107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: update channel list in reg notifier instead reg worker\n\nCurrently when ath11k gets a new channel list, it will be processed\naccording to the following steps:\n1. update new channel list to cfg80211 and queue reg_work.\n2. cfg80211 handles new channel list during reg_work.\n3. update cfg80211's handled channel list to firmware by\nath11k_reg_update_chan_list().\n\nBut ath11k will immediately execute step 3 after reg_work is just\nqueued. Since step 2 is asynchronous, cfg80211 may not have completed\nhandling the new channel list, which may leading to an out-of-bounds\nwrite error:\nBUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list\nCall Trace:\n    ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]\n    kfree+0x109/0x3a0\n    ath11k_regd_update+0x1cf/0x350 [ath11k]\n    ath11k_regd_update_work+0x14/0x20 [ath11k]\n    process_one_work+0xe35/0x14c0\n\nShould ensure step 2 is completely done before executing step 3. Thus\nWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,\ncfg80211 will notify ath11k after step 2 is done.\n\nSo enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will\nnotify ath11k after step 2 is done. At this time, there will be no\nKASAN bug during the execution of the step 3.\n\n[1] https://patchwork.kernel.org/project/linux-wireless/patch/(CVE-2025-23133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni3c: Add NULL pointer check in i3c_master_queue_ibi()\n\nThe I3C master driver may receive an IBI from a target device that has not\nbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`\nto queue an IBI work task, leading to "Unable to handle kernel read from\nunreadable memory" and resulting in a kernel panic.\n\nTypical IBI handling flow:\n1. The I3C master scans target devices and probes their respective drivers.\n2. The target device driver calls `i3c_device_request_ibi()` to enable IBI\n   and assigns `dev->ibi = ibi`.\n3. The I3C master receives an IBI from the target device and calls\n   `i3c_master_queue_ibi()` to queue the target device driver’s IBI\n   handler task.\n\nHowever, since target device events are asynchronous to the I3C probe\nsequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,\nleading to a kernel panic.\n\nAdd a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing\nan uninitialized `dev->ibi`, ensuring stability.(CVE-2025-23147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add a check to handle OOB in sfr region\n\nsfr->buf_size is in shared memory and can be modified by malicious user.\nOOB write is possible when the size is made higher than actual sfr data\nbuffer. Cap the size to allocated size for such cases.(CVE-2025-23159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()\n\ndevm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does\nnot check for this case, which can result in a NULL pointer dereference.\n\nAdd NULL check after devm_ioremap() to prevent this issue.(CVE-2025-37758)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in __smb2_lease_break_noti()\n\nMove tcp_transport free to ksmbd_conn_free. If ksmbd connection is\nreferenced when ksmbd server thread terminates, It will not be freed,\nbut conn->tcp_transport is freed. __smb2_lease_break_noti can be performed\nasynchronously when the connection is disconnected. __smb2_lease_break_noti\ncalls ksmbd_conn_write, which can cause use-after-free\nwhen conn->ksmbd_transport is already freed.(CVE-2025-37777)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue\n\nWhen the task management thread processes reply queues while the reset\nthread resets them, the task management thread accesses an invalid queue ID\n(0xFFFF), set by the reset thread, which points to unallocated memory,\ncausing a crash.\n\nAdd flag 'io_admin_reset_sync' to synchronize access between the reset,\nI/O, and admin threads. Before a reset, the reset handler sets this flag to\nblock I/O and admin processing threads. If any thread bypasses the initial\ncheck, the reset thread waits up to 10 seconds for processing to finish. If\nthe wait exceeds 10 seconds, the controller is marked as unrecoverable.(CVE-2025-37861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in session logoff\n\nThe sess->user object can currently be in use by another thread, for\nexample if another connection has sent a session setup request to\nbind to the session being free'd. The handler for that connection could\nbe in the smb2_sess_setup function which makes use of sess->user.(CVE-2025-37899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix NULL pointer access\n\nThis patch ensures that the UCSI driver waits for all pending tasks in the\nucsi_displayport_work workqueue to finish executing before proceeding with\nthe partner removal.(CVE-2025-37994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.(CVE-2025-37997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma: Add missing locking\n\nRecent kernels complain about a missing lock in k3-udma.c when the lock\nvalidator is enabled:\n\n[    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238\n[    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28\n[    4.144867] Hardware name: pp-v12 (DT)\n[    4.148648] Workqueue: events udma_check_tx_completion\n[    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    4.160834] pc : udma_start.isra.0+0x34/0x238\n[    4.165227] lr : udma_start.isra.0+0x30/0x238\n[    4.169618] sp : ffffffc083cabcf0\n[    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005\n[    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000\n[    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670\n[    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030\n[    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048\n[    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001\n[    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68\n[    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8\n[    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000\n[    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000\n[    4.244986] Call trace:\n[    4.247463]  udma_start.isra.0+0x34/0x238\n[    4.251509]  udma_check_tx_completion+0xd0/0xdc\n[    4.256076]  process_one_work+0x244/0x3fc\n[    4.260129]  process_scheduled_works+0x6c/0x74\n[    4.264610]  worker_thread+0x150/0x1dc\n[    4.268398]  kthread+0xd8/0xe8\n[    4.271492]  ret_from_fork+0x10/0x20\n[    4.275107] irq event stamp: 220\n[    4.278363] hardirqs last  enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50\n[    4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50\n[    4.294879] softirqs last  enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc\n[    4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28\n[    4.311559] ---[ end trace 0000000000000000 ]---\n\nThis commit adds the missing locking.(CVE-2025-38005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock\n\n... or we risk stealing final mntput from sync umount - raising mnt_count\nafter umount(2) has verified that victim is not busy, but before it\nhas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see\nthat it's safe to quietly undo mnt_count increment and leaves dropping\nthe reference to caller, where it'll be a full-blown mntput().\n\nCheck under mount_lock is needed; leaving the current one done before\ntaking that makes no sense - it's nowhere near common enough to bother\nwith.(CVE-2025-38058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Check return value from memblock_phys_alloc_range()\n\nAt least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of\ncontiguous free memory available at this point, the kernel will crash\nand burn because memblock_phys_alloc_range() returns 0 on failure,\nwhich leads memblock_phys_free() to throw the first 4 MiB of physical\nmemory to the wolves.\n\nAt a minimum it should fail gracefully with a meaningful diagnostic,\nbut in fact everything seems to work fine without the weird reserve\nallocation.(CVE-2025-38071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: Initialize ssc before laundromat_work to prevent NULL dereference\n\nIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc through\nnfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,\nthis can cause NULL pointer dereference.\n\nNormally the delayed start of laundromat_work allows sufficient time for\nnfsd_ssc initialization to complete. However, when the kernel waits too\nlong for userspace responses (e.g. in nfs4_state_start_net ->\nnfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done ->\ncld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the\ndelayed work may start before nfsd_ssc initialization finishes.\n\nFix this by moving nfsd_ssc initialization before starting laundromat_work.(CVE-2025-38231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix uaf in nbd_genl_connect() error path\n\nThere is a use-after-free issue in nbd:\n\nblock nbd6: Receive control failed (result -104)\nblock nbd6: shutting down sockets\n==================================================================\nBUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022\nWrite of size 4 at addr ffff8880295de478 by task kworker/u33:0/67\n\nCPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: nbd6-recv recv_work\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]\n recv_work+0x694/0xa80 drivers/block/nbd.c:1022\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nnbd_genl_connect() does not properly stop the device on certain\nerror paths after nbd_start_device() has been called. This causes\nthe error path to put nbd->config while recv_work continue to use\nthe config after putting it, leading to use-after-free in recv_work.\n\nThis patch moves nbd_start_device() after the backend file creation.(CVE-2025-38443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix race condition on qfq_aggregate\n\nA race condition can occur when 'agg' is modified in qfq_change_agg\n(called during qfq_enqueue) while other threads access it\nconcurrently. For example, qfq_dump_class may trigger a NULL\ndereference, and qfq_delete_class may cause a use-after-free.\n\nThis patch addresses the issue by:\n\n1. Moved qfq_destroy_class into the critical section.\n\n2. Added sch_tree_lock protection to qfq_dump_class and\nqfq_dump_class_stats.(CVE-2025-38477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: limit repeated connections from clients with the same IP\n\nRepeated connections from clients with the same IP address may exhaust\nthe max connections and prevent other normal client connections.\nThis patch limit repeated connections from clients with the same IP.(CVE-2025-38501)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix handling of server side tls alerts\n\nScott Mayhew discovered a security exploit in NFS over TLS in\ntls_alert_recv() due to its assumption it can read data from\nthe msg iterator's kvec..\n\nkTLS implementation splits TLS non-data record payload between\nthe control message buffer (which includes the type such as TLS\naler or TLS cipher change) and the rest of the payload (say TLS\nalert's level/description) which goes into the msg payload buffer.\n\nThis patch proposes to rework how control messages are setup and\nused by sock_recvmsg().\n\nIf no control message structure is setup, kTLS layer will read and\nprocess TLS data record types. As soon as it encounters a TLS control\nmessage, it would return an error. At that point, NFS can setup a\nkvec backed msg buffer and read in the control message such as a\nTLS alert. Msg iterator can advance the kvec pointer as a part of\nthe copy process thus we need to revert the iterator before calling\ninto the tls_alert_recv.(CVE-2025-38566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix backlog accounting in qdisc_dequeue_internal\n\nThis issue applies for the following qdiscs: hhf, fq, fq_codel, and\nfq_pie, and occurs in their change handlers when adjusting to the new\nlimit. The problem is the following in the values passed to the\nsubsequent qdisc_tree_reduce_backlog call given a tbf parent:\n\n   When the tbf parent runs out of tokens, skbs of these qdiscs will\n   be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,\n   which accounts for both qlen and backlog. However, in the case of\n   qdisc_dequeue_internal, ONLY qlen is accounted for when pulling\n   from gso_skb. This means that these qdiscs are missing a\n   qdisc_qstats_backlog_dec when dropping packets to satisfy the\n   new limit in their change handlers.\n\n   One can observe this issue with the following (with tc patched to\n   support a limit of 0):\n\n   export TARGET=fq\n   tc qdisc del dev lo root\n   tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms\n   tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000\n   echo ''; echo 'add child'; tc -s -d qdisc show dev lo\n   ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null\n   echo ''; echo 'after ping'; tc -s -d qdisc show dev lo\n   tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0\n   echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo\n   tc qdisc replace dev lo handle 2: parent 1:1 sfq\n   echo ''; echo 'post graft'; tc -s -d qdisc show dev lo\n\n   The second to last show command shows 0 packets but a positive\n   number (74) of backlog bytes. The problem becomes clearer in the\n   last show command, where qdisc_purge_queue triggers\n   qdisc_tree_reduce_backlog with the positive backlog and causes an\n   underflow in the tbf parent's backlog (4096 Mb instead of 0).\n\nTo fix this issue, the codepath for all clients of qdisc_dequeue_internal\nhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.\nqdisc_dequeue_internal handles the backlog adjustments for all cases that\ndo not directly use the dequeue handler.\n\nThe old fq_codel_change limit adjustment loop accumulated the arguments to\nthe subsequent qdisc_tree_reduce_backlog call through the cstats field.\nHowever, this is confusing and error prone as fq_codel_dequeue could also\npotentially mutate this field (which qdisc_dequeue_internal calls in the\nnon gso_skb case), so we have unified the code here with other qdiscs.(CVE-2025-39677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix memory corruption when FW resources change during ifdown\n\nbnxt_set_dflt_rings() assumes that it is always called before any TC has\nbeen created.  So it doesn't take bp->num_tc into account and assumes\nthat it is always 0 or 1.\n\nIn the FW resource or capability change scenario, the FW will return\nflags in bnxt_hwrm_if_change() that will cause the driver to\nreinitialize and call bnxt_cancel_reservations().  This will lead to\nbnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc\nmay be greater than 1.  This will cause bp->tx_ring[] to be sized too\nsmall and cause memory corruption in bnxt_alloc_cp_rings().\n\nFix it by properly scaling the TX rings by bp->num_tc in the code\npaths mentioned above.  Add 2 helper functions to determine\nbp->tx_nr_rings and bp->tx_nr_rings_per_tc.(CVE-2025-39810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Fix slab-out-of-bounds in efivarfs_d_compare\n\nObserved on kernel 6.6 (present on master as well):\n\n  BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0\n  Call trace:\n   kasan_check_range+0xe8/0x190\n   __asan_loadN+0x1c/0x28\n   memcmp+0x98/0xd0\n   efivarfs_d_compare+0x68/0xd8\n   __d_lookup_rcu_op_compare+0x178/0x218\n   __d_lookup_rcu+0x1f8/0x228\n   d_alloc_parallel+0x150/0x648\n   lookup_open.isra.0+0x5f0/0x8d0\n   open_last_lookups+0x264/0x828\n   path_openat+0x130/0x3f8\n   do_filp_open+0x114/0x248\n   do_sys_openat2+0x340/0x3c0\n   __arm64_sys_openat+0x120/0x1a0\n\nIf dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become\nnegative, leadings to oob. The issue can be triggered by parallel\nlookups using invalid filename:\n\n  T1\t\t\tT2\n  lookup_open\n   ->lookup\n    simple_lookup\n     d_add\n     // invalid dentry is added to hash list\n\n\t\t\tlookup_open\n\t\t\t d_alloc_parallel\n\t\t\t  __d_lookup_rcu\n\t\t\t   __d_lookup_rcu_op_compare\n\t\t\t    hlist_bl_for_each_entry_rcu\n\t\t\t    // invalid dentry can be retrieved\n\t\t\t     ->d_compare\n\t\t\t      efivarfs_d_compare\n\t\t\t      // oob\n\nFix it by checking 'guid' before cmp.(CVE-2025-39817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: writeback: fix use-after-free in __mark_inode_dirty()\n\nAn use-after-free issue occurred when __mark_inode_dirty() get the\nbdi_writeback that was in the progress of switching.\n\nCPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1\n......\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __mark_inode_dirty+0x124/0x418\nlr : __mark_inode_dirty+0x118/0x418\nsp : ffffffc08c9dbbc0\n........\nCall trace:\n __mark_inode_dirty+0x124/0x418\n generic_update_time+0x4c/0x60\n file_modified+0xcc/0xd0\n ext4_buffered_write_iter+0x58/0x124\n ext4_file_write_iter+0x54/0x704\n vfs_write+0x1c0/0x308\n ksys_write+0x74/0x10c\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x40/0xe4\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x194/0x198\n\nRoot cause is:\n\nsystemd-random-seed                         kworker\n----------------------------------------------------------------------\n___mark_inode_dirty                     inode_switch_wbs_work_fn\n\n  spin_lock(&inode->i_lock);\n  inode_attach_wb\n  locked_inode_to_wb_and_lock_list\n     get inode->i_wb\n     spin_unlock(&inode->i_lock);\n     spin_lock(&wb->list_lock)\n  spin_lock(&inode->i_lock)\n  inode_io_list_move_locked\n  spin_unlock(&wb->list_lock)\n  spin_unlock(&inode->i_lock)\n                                    spin_lock(&old_wb->list_lock)\n                                      inode_do_switch_wbs\n                                        spin_lock(&inode->i_lock)\n                                        inode->i_wb = new_wb\n                                        spin_unlock(&inode->i_lock)\n                                    spin_unlock(&old_wb->list_lock)\n                                    wb_put_many(old_wb, nr_switched)\n                                      cgwb_release\n                                      old wb released\n  wb_wakeup_delayed() accesses wb,\n  then trigger the use-after-free\n  issue\n\nFix this race condition by holding inode spinlock until\nwb_wakeup_delayed() finished.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path\n\nIf request_irq() in i40e_vsi_request_irq_msix() fails in an iteration\nlater than the first, the error path wants to free the IRQs requested\nso far. However, it uses the wrong dev_id argument for free_irq(), so\nit does not free the IRQs correctly and instead triggers the warning:\n\n Trying to free already-free IRQ 173\n WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0\n Modules linked in: i40e(+) [...]\n CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)\n Hardware name: [...]\n RIP: 0010:__free_irq+0x192/0x2c0\n [...]\n Call Trace:\n  <TASK>\n  free_irq+0x32/0x70\n  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]\n  i40e_vsi_request_irq+0x79/0x80 [i40e]\n  i40e_vsi_open+0x21f/0x2f0 [i40e]\n  i40e_open+0x63/0x130 [i40e]\n  __dev_open+0xfc/0x210\n  __dev_change_flags+0x1fc/0x240\n  netif_change_flags+0x27/0x70\n  do_setlink.isra.0+0x341/0xc70\n  rtnl_newlink+0x468/0x860\n  rtnetlink_rcv_msg+0x375/0x450\n  netlink_rcv_skb+0x5c/0x110\n  netlink_unicast+0x288/0x3c0\n  netlink_sendmsg+0x20d/0x430\n  ____sys_sendmsg+0x3a2/0x3d0\n  ___sys_sendmsg+0x99/0xe0\n  __sys_sendmsg+0x8a/0xf0\n  do_syscall_64+0x82/0x2c0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  [...]\n  </TASK>\n ---[ end trace 0000000000000000 ]---\n\nUse the same dev_id for free_irq() as for request_irq().\n\nI tested this with inserting code to fail intentionally.(CVE-2025-39911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Harden uplink netdev access against device unbind\n\nThe function mlx5_uplink_netdev_get() gets the uplink netdevice\npointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can\nbe removed and its pointer cleared when unbound from the mlx5_core.eth\ndriver. This results in a NULL pointer, causing a kernel panic.\n\n BUG: unable to handle page fault for address: 0000000000001300\n at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]\n Call Trace:\n  <TASK>\n  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]\n  esw_offloads_enable+0x593/0x910 [mlx5_core]\n  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]\n  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]\n  devlink_nl_eswitch_set_doit+0x60/0xd0\n  genl_family_rcv_msg_doit+0xe0/0x130\n  genl_rcv_msg+0x183/0x290\n  netlink_rcv_skb+0x4b/0xf0\n  genl_rcv+0x24/0x40\n  netlink_unicast+0x255/0x380\n  netlink_sendmsg+0x1f3/0x420\n  __sock_sendmsg+0x38/0x60\n  __sys_sendto+0x119/0x180\n  do_syscall_64+0x53/0x1d0\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEnsure the pointer is valid before use by checking it for NULL. If it\nis valid, immediately call netdev_hold() to take a reference, and\npreventing the netdevice from being freed while it is in use.(CVE-2025-39947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove\n\nThe original code uses cancel_delayed_work() in flexcop_pci_remove(), which\ndoes not guarantee that the delayed work item irq_check_work has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere flexcop_pci_remove() may free the flexcop_device while irq_check_work\nis still active and attempts to dereference the device.\n\nA typical race condition is illustrated below:\n\nCPU 0 (remove)                         | CPU 1 (delayed work callback)\nflexcop_pci_remove()                   | flexcop_pci_irq_check_work()\n  cancel_delayed_work()                |\n  flexcop_device_kfree(fc_pci->fc_dev) |\n                                       |   fc = fc_pci->fc_dev; // UAF\n\nThis is confirmed by a KASAN report:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0\nWrite of size 8 at addr ffff8880093aa8c8 by task bash/135\n...\nCall Trace:\n <IRQ>\n dump_stack_lvl+0x55/0x70\n print_report+0xcf/0x610\n ? __run_timer_base.part.0+0x7d7/0x8c0\n kasan_report+0xb8/0xf0\n ? __run_timer_base.part.0+0x7d7/0x8c0\n __run_timer_base.part.0+0x7d7/0x8c0\n ? __pfx___run_timer_base.part.0+0x10/0x10\n ? __pfx_read_tsc+0x10/0x10\n ? ktime_get+0x60/0x140\n ? lapic_next_event+0x11/0x20\n ? clockevents_program_event+0x1d4/0x2a0\n run_timer_softirq+0xd1/0x190\n handle_softirqs+0x16a/0x550\n irq_exit_rcu+0xaf/0xe0\n sysvec_apic_timer_interrupt+0x70/0x80\n </IRQ>\n...\n\nAllocated by task 1:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x1be/0x460\n flexcop_device_kmalloc+0x54/0xe0\n flexcop_pci_probe+0x1f/0x9d0\n local_pci_probe+0xdc/0x190\n pci_device_probe+0x2fe/0x470\n really_probe+0x1ca/0x5c0\n __driver_probe_device+0x248/0x310\n driver_probe_device+0x44/0x120\n __driver_attach+0xd2/0x310\n bus_for_each_dev+0xed/0x170\n bus_add_driver+0x208/0x500\n driver_register+0x132/0x460\n do_one_initcall+0x89/0x300\n kernel_init_freeable+0x40d/0x720\n kernel_init+0x1a/0x150\n ret_from_fork+0x10c/0x1a0\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 135:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x3f/0x50\n kfree+0x137/0x370\n flexcop_device_kfree+0x32/0x50\n pci_device_remove+0xa6/0x1d0\n device_release_driver_internal+0xf8/0x210\n pci_stop_bus_device+0x105/0x150\n pci_stop_and_remove_bus_device_locked+0x15/0x30\n remove_store+0xcc/0xe0\n kernfs_fop_write_iter+0x2c3/0x440\n vfs_write+0x871/0xd70\n ksys_write+0xee/0x1c0\n do_syscall_64+0xac/0x280\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the delayed work item is properly canceled and any executing delayed\nwork has finished before the device memory is deallocated.\n\nThis bug was initially identified through static analysis. To reproduce\nand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced\nartificial delays within the flexcop_pci_irq_check_work() function to\nincrease the likelihood of triggering the bug.(CVE-2025-39996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nIf we add a new entity with id 0 or a duplicated ID, it will be marked\nas UVC_INVALID_ENTITY_ID.\n\nIn a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require\nentities to have a non-zero unique ID"), we ignored all the invalid units,\nthis broke a lot of non-compatible cameras. Hopefully we are more lucky\nthis time.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[   20.830206] usb 1-1: Using ep0 maxpacket: 8\n[   20.833501] usb 1-1: config 0 descriptor??\n[   21.038518] usb 1-1: string descriptor 0 read error: -71\n[   21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201)\n[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[   21.042218] ------------[ cut here ]------------\n[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[   21.043195] Modules linked in:\n[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   21.044639] Workqueue: usb_hub_wq hub_event\n[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[   21.051136] PKRU: 55555554\n[   21.051331] Call Trace:\n[   21.051480]  <TASK>\n[   21.051611]  ? __warn+0xc4/0x210\n[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.052252]  ? report_bug+0x11b/0x1a0\n[   21.052540]  ? trace_hardirqs_on+0x31/0x40\n[   21.052901]  ? handle_bug+0x3d/0x70\n[   21.053197]  ? exc_invalid_op+0x1a/0x50\n[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20\n[   21.053924]  ? media_create_pad_link+0x91/0x2e0\n[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.054834]  ? media_create_pad_link+0x91/0x2e0\n[   21.055131]  ? _raw_spin_unlock+0x1e/0x40\n[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210\n[   21.055837]  uvc_mc_register_entities+0x358/0x400\n[   21.056144]  uvc_register_chains+0x1\n---truncated---(CVE-2025-40016)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP2","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-125.0.0.125.oe2403sp2"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","bpftool-debuginfo-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-debuginfo-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-debugsource-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-devel-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-extra-modules-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-headers-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-source-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-tools-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-tools-debuginfo-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","kernel-tools-devel-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","perf-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","perf-debuginfo-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","python3-perf-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm","python3-perf-debuginfo-6.6.0-125.0.0.125.oe2403sp2.aarch64.rpm"],"src":["kernel-6.6.0-125.0.0.125.oe2403sp2.src.rpm"],"x86_64":["bpftool-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","bpftool-debuginfo-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-debuginfo-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-debugsource-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-devel-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-extra-modules-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-headers-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-source-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-tools-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-tools-debuginfo-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","kernel-tools-devel-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","perf-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","perf-debuginfo-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","python3-perf-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm","python3-perf-debuginfo-6.6.0-125.0.0.125.oe2403sp2.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2776"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21693"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22026"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22083"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22107"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23133"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23147"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23159"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37758"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37997"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38005"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38071"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38231"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38443"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38566"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39677"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39810"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39866"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40016"}],"database_specific":{"severity":"High"}}