{"schema_version":"1.7.2","id":"OESA-2025-2350","modified":"2025-09-26T13:09:38Z","published":"2025-09-26T13:09:38Z","upstream":["CVE-2022-50255","CVE-2022-50313","CVE-2023-53149","CVE-2023-53221","CVE-2023-53357","CVE-2025-38695","CVE-2025-39773","CVE-2025-39813","CVE-2025-39829"],"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\ntracing: Fix reading strings from synthetic events\n\nThe follow commands caused a crash:\n\n  # cd /sys/kernel/tracing\n  # echo 's:open char file[]' > dynamic_events\n  # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger'\n  # echo 1 > events/synthetic/open/enable\n\nBOOM!\n\nThe problem is that the synthetic event field "char file[]" will read\nthe value given to it as a string without any memory checks to make sure\nthe address is valid. The above example will pass in the user space\naddress and the sythetic event code will happily call strlen() on it\nand then strscpy() where either one will cause an oops when accessing\nuser space addresses.\n\nUse the helper functions from trace_kprobe and trace_eprobe that can\nread strings safely (and actually succeed when the address is from user\nspace and the memory is mapped in).\n\nNow the above can show:\n\n     packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr\n    in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp\n     packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix order >= MAX_ORDER warning due to crafted negative i_size\n\nAs syzbot reported [1], the root cause is that i_size field is a\nsigned type, and negative i_size is also less than EROFS_BLKSIZ.\nAs a consequence, it's handled as fast symlink unexpectedly.\n\nLet's fall back to the generic path to deal with such unusual i_size.\n\n[1] https://lore.kernel.org/r/(CVE-2022-50313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid deadlock in fs reclaim with page writeback\n\nExt4 has a filesystem wide lock protecting ext4_writepages() calls to\navoid races with switching of journalled data flag or inode format. This\nlock can however cause a deadlock like:\n\nCPU0                            CPU1\n\next4_writepages()\n  percpu_down_read(sbi->s_writepages_rwsem);\n                                ext4_change_inode_journal_flag()\n                                  percpu_down_write(sbi->s_writepages_rwsem);\n                                    - blocks, all readers block from now on\n  ext4_do_writepages()\n    ext4_init_io_end()\n      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)\n        fs_reclaim frees dentry...\n          dentry_unlink_inode()\n            iput() - last ref =>\n              iput_final() - inode dirty =>\n                write_inode_now()...\n                  ext4_writepages() tries to acquire sbi->s_writepages_rwsem\n                    and blocks forever\n\nMake sure we cannot recurse into filesystem reclaim from writeback code\nto avoid the deadlock.(CVE-2023-53149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memleak due to fentry attach failure\n\nIf it fails to attach fentry, the allocated bpf trampoline image will be\nleft in the system. That can be verified by checking /proc/kallsyms.\n\nThis meamleak can be verified by a simple bpf program as follows:\n\n  SEC("fentry/trap_init")\n  int fentry_run()\n  {\n      return 0;\n  }\n\nIt will fail to attach trap_init because this function is freed after\nkernel init, and then we can find the trampoline image is left in the\nsystem by checking /proc/kallsyms.\n\n  $ tail /proc/kallsyms\n  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]\n  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]\n\n  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'"\n  [2522] FUNC 'trap_init' type_id=119 linkage=static\n\n  $ echo $((6442453466 & 0x7fffffff))\n  2522\n\nNote that there are two left bpf trampoline images, that is because the\nlibbpf will fallback to raw tracepoint if -EINVAL is returned.(CVE-2023-53221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: check slab-out-of-bounds in md_bitmap_get_counter\n\nIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()\nwill return -EINVAL because 'page >= bitmap->pages', but the return value\nwas not checked immediately in md_bitmap_get_counter() in order to set\n*blocks value and slab-out-of-bounds occurs.\n\nMove check of 'page >= bitmap->pages' to md_bitmap_get_counter() and\nreturn directly if true.(CVE-2023-53357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure\n\nIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the\nresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may\noccur before sli4_hba.hdwqs are allocated.  This may result in a null\npointer dereference when attempting to take the abts_io_buf_list_lock for\nthe first hardware queue.  Fix by adding a null ptr check on\nphba->sli4_hba.hdwq and early return because this situation means there\nmust have been an error during port initialization.(CVE-2025-38695)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n'time' in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n  Call Trace:\n   <IRQ>\n   __netdev_alloc_skb+0x2e/0x3a0\n   br_ip6_multicast_alloc_query+0x212/0x1b70\n   __br_multicast_send_query+0x376/0xac0\n   br_multicast_send_query+0x299/0x510\n   br_multicast_query_expired.constprop.0+0x16d/0x1b0\n   call_timer_fn+0x3b/0x2a0\n   __run_timers+0x619/0x950\n   run_timer_softirq+0x11c/0x220\n   handle_softirqs+0x18e/0x560\n   __irq_exit_rcu+0x158/0x1a0\n   sysvec_apic_timer_interrupt+0x76/0x90\n   </IRQ>\n\nThis issue can be reproduced with:\n  ip link add br0 type bridge\n  echo 1 > /sys/class/net/br0/bridge/multicast_querier\n  echo 0xffffffffffffffff >\n  \t/sys/class/net/br0/bridge/multicast_query_interval\n  ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a ("net: bridge: mcast: add and enforce query\ninterval minimum"), add check for the query interval maximum to fix this\nissue.(CVE-2025-39773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix potential warning in trace_printk_seq during ftrace_dump\n\nWhen calling ftrace_dump_one() concurrently with reading trace_pipe,\na WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race\ncondition.\n\nThe issue occurs because:\n\nCPU0 (ftrace_dump)                              CPU1 (reader)\necho z > /proc/sysrq-trigger\n\n!trace_empty(&iter)\ntrace_iterator_reset(&iter) <- len = size = 0\n                                                cat /sys/kernel/tracing/trace_pipe\ntrace_find_next_entry_inc(&iter)\n  __find_next_entry\n    ring_buffer_empty_cpu <- all empty\n  return NULL\n\ntrace_printk_seq(&iter.seq)\n  WARN_ON_ONCE(s->seq.len >= s->seq.size)\n\nIn the context between trace_empty() and trace_find_next_entry_inc()\nduring ftrace_dump, the ring buffer data was consumed by other readers.\nThis caused trace_find_next_entry_inc to return NULL, failing to populate\n`iter.seq`. At this point, due to the prior trace_iterator_reset, both\n`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,\nthe WARN_ON_ONCE condition is triggered.\n\nMove the trace_printk_seq() into the if block that checks to make sure the\nreturn value of trace_find_next_entry_inc() is non-NULL in\nftrace_dump_one(), ensuring the 'iter.seq' is properly populated before\nsubsequent operations.(CVE-2025-39813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntrace/fgraph: Fix the warning caused by missing unregister notifier\n\nThis warning was triggered during testing on v6.16:\n\nnotifier callback ftrace_suspend_notifier_call already registered\nWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0\n...\nCall Trace:\n <TASK>\n blocking_notifier_chain_register+0x34/0x60\n register_ftrace_graph+0x330/0x410\n ftrace_profile_write+0x1e9/0x340\n vfs_write+0xf8/0x420\n ? filp_flush+0x8a/0xa0\n ? filp_close+0x1f/0x30\n ? do_dup2+0xaf/0x160\n ksys_write+0x65/0xe0\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen writing to the function_profile_enabled interface, the notifier was\nnot unregistered after start_graph_tracing failed, causing a warning the\nnext time function_profile_enabled was written.\n\nFixed by adding unregister_pm_notifier in the exception path.(CVE-2025-39829)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-283.0.0.186.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","perf-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-283.0.0.186.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-283.0.0.186.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","perf-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-283.0.0.186.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50255"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53357"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38695"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39773"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39813"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39829"}],"database_specific":{"severity":"High"}}