{"schema_version":"1.7.2","id":"OESA-2025-2774","modified":"2025-12-05T13:11:59Z","published":"2025-12-05T13:11:59Z","upstream":["CVE-2025-21693","CVE-2025-21915","CVE-2025-22020","CVE-2025-22083","CVE-2025-22107","CVE-2025-23147","CVE-2025-23159","CVE-2025-37758","CVE-2025-37812","CVE-2025-37839","CVE-2025-37863","CVE-2025-37891","CVE-2025-38234","CVE-2025-38349","CVE-2025-39785"],"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\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\ncdx: Fix possible UAF error in driver_override_show()\n\nFixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c\n\nThis function driver_override_show() is part of DEVICE_ATTR_RW, which\nincludes both driver_override_show() and driver_override_store().\nThese functions can be executed concurrently in sysfs.\n\nThe driver_override_store() function uses driver_set_override() to\nupdate the driver_override value, and driver_set_override() internally\nlocks the device (device_lock(dev)). If driver_override_show() reads\ncdx_dev->driver_override without locking, it could potentially access\na freed pointer if driver_override_store() frees the string\nconcurrently. This could lead to printing a kernel address, which is a\nsecurity risk since DEVICE_ATTR can be read by all users.\n\nAdditionally, a similar pattern is used in drivers/amba/bus.c, as well\nas many other bus drivers, where device_lock() is taken in the show\nfunction, and it has been working without issues.\n\nThis potential bug was detected by our experimental static analysis\ntool, which analyzes locking APIs and paired functions to identify\ndata races and atomicity violations.(CVE-2025-21915)\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\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\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\nusb: cdns3: Fix deadlock when using NCM gadget\n\nThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit\n58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").\n\nUnder PREEMPT_RT the deadlock can be readily triggered by heavy network\ntraffic, for example using "iperf --bidir" over NCM ethernet link.\n\nThe deadlock occurs because the threaded interrupt handler gets\npreempted by a softirq, but both are protected by the same spinlock.\nPrevent deadlock by disabling softirq during threaded irq handler.(CVE-2025-37812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: remove wrong sb->s_sequence check\n\nJournal emptiness is not determined by sb->s_sequence == 0 but rather by\nsb->s_start == 0 (which is set a few lines above). Furthermore 0 is a\nvalid transaction ID so the check can spuriously trigger. Remove the\ninvalid WARN_ON.(CVE-2025-37839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: don't allow datadir only\n\nIn theory overlayfs could support upper layer directly referring to a data\nlayer, but there's no current use case for this.\n\nOriginally, when data-only layers were introduced, this wasn't allowed,\nonly introduced by the "datadir+" feature, but without actually handling\nthis case, resulting in an Oops.\n\nFix by disallowing datadir without lowerdir.(CVE-2025-37863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ump: Fix buffer overflow at UMP SysEx message conversion\n\nThe conversion function from MIDI 1.0 to UMP packet contains an\ninternal buffer to keep the incoming MIDI bytes, and its size is 4, as\nit was supposed to be the max size for a MIDI1 UMP packet data.\nHowever, the implementation overlooked that SysEx is handled in a\ndifferent format, and it can be up to 6 bytes, as found in\ndo_convert_to_ump().  It leads eventually to a buffer overflow, and\nmay corrupt the memory when a longer SysEx message is received.\n\nThe fix is simply to extend the buffer size to 6 to fit with the SysEx\nUMP message.(CVE-2025-37891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Fix race in push_rt_task\n\nOverview\n========\nWhen a CPU chooses to call push_rt_task and picks a task to push to\nanother CPU's runqueue then it will call find_lock_lowest_rq method\nwhich would take a double lock on both CPUs' runqueues. If one of the\nlocks aren't readily available, it may lead to dropping the current\nrunqueue lock and reacquiring both the locks at once. During this window\nit is possible that the task is already migrated and is running on some\nother CPU. These cases are already handled. However, if the task is\nmigrated and has already been executed and another CPU is now trying to\nwake it up (ttwu) such that it is queued again on the runqeue\n(on_rq is 1) and also if the task was run by the same CPU, then the\ncurrent checks will pass even though the task was migrated out and is no\nlonger in the pushable tasks list.\n\nCrashes\n=======\nThis bug resulted in quite a few flavors of crashes triggering kernel\npanics with various crash signatures such as assert failures, page\nfaults, null pointer dereferences, and queue corruption errors all\ncoming from scheduler itself.\n\nSome of the crashes:\n-> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO)\n   Call Trace:\n   ? __die_body+0x1a/0x60\n   ? die+0x2a/0x50\n   ? do_trap+0x85/0x100\n   ? pick_next_task_rt+0x6e/0x1d0\n   ? do_error_trap+0x64/0xa0\n   ? pick_next_task_rt+0x6e/0x1d0\n   ? exc_invalid_op+0x4c/0x60\n   ? pick_next_task_rt+0x6e/0x1d0\n   ? asm_exc_invalid_op+0x12/0x20\n   ? pick_next_task_rt+0x6e/0x1d0\n   __schedule+0x5cb/0x790\n   ? update_ts_time_stats+0x55/0x70\n   schedule_idle+0x1e/0x40\n   do_idle+0x15e/0x200\n   cpu_startup_entry+0x19/0x20\n   start_secondary+0x117/0x160\n   secondary_startup_64_no_verify+0xb0/0xbb\n\n-> BUG: kernel NULL pointer dereference, address: 00000000000000c0\n   Call Trace:\n   ? __die_body+0x1a/0x60\n   ? no_context+0x183/0x350\n   ? __warn+0x8a/0xe0\n   ? exc_page_fault+0x3d6/0x520\n   ? asm_exc_page_fault+0x1e/0x30\n   ? pick_next_task_rt+0xb5/0x1d0\n   ? pick_next_task_rt+0x8c/0x1d0\n   __schedule+0x583/0x7e0\n   ? update_ts_time_stats+0x55/0x70\n   schedule_idle+0x1e/0x40\n   do_idle+0x15e/0x200\n   cpu_startup_entry+0x19/0x20\n   start_secondary+0x117/0x160\n   secondary_startup_64_no_verify+0xb0/0xbb\n\n-> BUG: unable to handle page fault for address: ffff9464daea5900\n   kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p))\n\n-> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running)\n   Call Trace:\n   ? __die_body+0x1a/0x60\n   ? die+0x2a/0x50\n   ? do_trap+0x85/0x100\n   ? dequeue_top_rt_rq+0xa2/0xb0\n   ? do_error_trap+0x64/0xa0\n   ? dequeue_top_rt_rq+0xa2/0xb0\n   ? exc_invalid_op+0x4c/0x60\n   ? dequeue_top_rt_rq+0xa2/0xb0\n   ? asm_exc_invalid_op+0x12/0x20\n   ? dequeue_top_rt_rq+0xa2/0xb0\n   dequeue_rt_entity+0x1f/0x70\n   dequeue_task_rt+0x2d/0x70\n   __schedule+0x1a8/0x7e0\n   ? blk_finish_plug+0x25/0x40\n   schedule+0x3c/0xb0\n   futex_wait_queue_me+0xb6/0x120\n   futex_wait+0xd9/0x240\n   do_futex+0x344/0xa90\n   ? get_mm_exe_file+0x30/0x60\n   ? audit_exe_compare+0x58/0x70\n   ? audit_filter_rules.constprop.26+0x65e/0x1220\n   __x64_sys_futex+0x148/0x1f0\n   do_syscall_64+0x30/0x80\n   entry_SYSCALL_64_after_hwframe+0x62/0xc7\n\n-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0\n   Call Trace:\n   ? __die_body+0x1a/0x60\n   ? no_context+0x183/0x350\n   ? spurious_kernel_fault+0x171/0x1c0\n   ? exc_page_fault+0x3b6/0x520\n   ? plist_check_list+0x15/0x40\n   ? plist_check_list+0x2e/0x40\n   ? asm_exc_page_fault+0x1e/0x30\n   ? _cond_resched+0x15/0x30\n   ? futex_wait_queue_me+0xc8/0x120\n   ? futex_wait+0xd9/0x240\n   ? try_to_wake_up+0x1b8/0x490\n   ? futex_wake+0x78/0x160\n   ? do_futex+0xcd/0xa90\n   ? plist_check_list+0x15/0x40\n   ? plist_check_list+0x2e/0x40\n   ? plist_del+0x6a/0xd0\n   ? plist_check_list+0x15/0x40\n   ? plist_check_list+0x2e/0x40\n   ? dequeue_pushable_task+0x20/0x70\n   ? __schedule+0x382/0x7e0\n   ? asm_sysvec_reschedule_i\n---truncated---(CVE-2025-38234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: don't decrement ep refcount while still holding the ep mutex\n\nJann Horn points out that epoll is decrementing the ep refcount and then\ndoing a\n\n    mutex_unlock(&ep->mtx);\n\nafterwards. That's very wrong, because it can lead to a use-after-free.\n\nThat pattern is actually fine for the very last reference, because the\ncode in question will delay the actual call to "ep_free(ep)" until after\nit has unlocked the mutex.\n\nBut it's wrong for the much subtler "next to last" case when somebody\n*else* may also be dropping their reference and free the ep while we're\nstill using the mutex.\n\nNote that this is true even if that other user is also using the same ep\nmutex: mutexes, unlike spinlocks, can not be used for object ownership,\neven if they guarantee mutual exclusion.\n\nA mutex "unlock" operation is not atomic, and as one user is still\naccessing the mutex as part of unlocking it, another user can come in\nand get the now released mutex and free the data structure while the\nfirst user is still cleaning up.\n\nSee our mutex documentation in Documentation/locking/mutex-design.rst,\nin particular the section [1] about semantics:\n\n\t"mutex_unlock() may access the mutex structure even after it has\n\t internally released the lock already - so it's not safe for\n\t another context to acquire the mutex and assume that the\n\t mutex_unlock() context is not using the structure anymore"\n\nSo if we drop our ep ref before the mutex unlock, but we weren't the\nlast one, we may then unlock the mutex, another user comes in, drops\n_their_ reference and releases the 'ep' as it now has no users - all\nwhile the mutex_unlock() is still accessing it.\n\nFix this by simply moving the ep refcount dropping to outside the mutex:\nthe refcount itself is atomic, and doesn't need mutex protection (that's\nthe whole _point_ of refcounts: unlike mutexes, they are inherently\nabout object lifetimes).(CVE-2025-38349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/hisilicon/hibmc: fix irq_request()'s irq name variable is local\n\nThe local variable is passed in request_irq (), and there will be use\nafter free problem, which will make request_irq failed. Using the global\nirq name instead of it to fix.(CVE-2025-39785)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-125.0.0.112.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-125.0.0.112.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-devel-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-headers-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-source-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-tools-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-125.0.0.112.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-125.0.0.112.oe2403.aarch64.rpm","perf-6.6.0-125.0.0.112.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-125.0.0.112.oe2403.aarch64.rpm","python3-perf-6.6.0-125.0.0.112.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-125.0.0.112.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-125.0.0.112.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-125.0.0.112.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-devel-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-headers-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-source-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-tools-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-125.0.0.112.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-125.0.0.112.oe2403.x86_64.rpm","perf-6.6.0-125.0.0.112.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-125.0.0.112.oe2403.x86_64.rpm","python3-perf-6.6.0-125.0.0.112.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-125.0.0.112.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2774"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21693"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21915"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22020"},{"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-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-37812"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37839"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38349"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39785"}],"database_specific":{"severity":"High"}}