{"schema_version":"1.7.2","id":"OESA-2025-2348","modified":"2025-09-26T13:09:24Z","published":"2025-09-26T13:09:24Z","upstream":["CVE-2022-50312","CVE-2022-50343","CVE-2022-50389","CVE-2023-53149","CVE-2023-53332","CVE-2025-39773"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel's JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrapidio: fix possible name leaks when rio_add_device() fails\n\nPatch series "rapidio: fix three possible memory leaks".\n\nThis patchset fixes three name leaks in error handling.\n - patch #1 fixes two name leaks while rio_add_device() fails.\n - patch #2 fixes a name leak while  rio_register_mport() fails.\n\n\nThis patch (of 2):\n\nIf rio_add_device() returns error, the name allocated by dev_set_name()\nneed be freed.  It should use put_device() to give up the reference in the\nerror path, so that the name can be freed in kobject_cleanup(), and the\n'rdev' can be freed in rio_release_dev().(CVE-2022-50343)\n\nIn the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)\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, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)\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)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2509.6.0.0345.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2509.6.0.0345.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50312"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50343"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53332"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39773"}],"database_specific":{"severity":"High"}}