{"schema_version":"1.7.2","id":"OESA-2025-2006","modified":"2025-08-15T12:39:34Z","published":"2025-08-15T12:39:34Z","upstream":["CVE-2025-21920","CVE-2025-21926","CVE-2025-22004","CVE-2025-38352"],"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\nvlan: enforce underlying device type\n\nCurrently, VLAN devices can be created on top of non-ethernet devices.\n\nBesides the fact that it doesn't make much sense, this also causes a\nbug which leaks the address of a kernel function to usermode.\n\nWhen creating a VLAN device, we initialize GARP (garp_init_applicant)\nand MRP (mrp_init_applicant) for the underlying device.\n\nAs part of the initialization process, we add the multicast address of\neach applicant to the underlying device, by calling dev_mc_add.\n\n__dev_mc_add uses dev->addr_len to determine the length of the new\nmulticast address.\n\nThis causes an out-of-bounds read if dev->addr_len is greater than 6,\nsince the multicast addresses provided by GARP and MRP are only 6\nbytes long.\n\nThis behaviour can be reproduced using the following commands:\n\nip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo\nip l set up dev gretest\nip link add link gretest name vlantest type vlan id 100\n\nThen, the following command will display the address of garp_pdu_rcv:\n\nip maddr show | grep 01:80:c2:00:00:21\n\nFix the bug by enforcing the type of the underlying device during VLAN\ndevice initialization.(CVE-2025-21920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: fix ownership in __udp_gso_segment\n\nIn __udp_gso_segment the skb destructor is removed before segmenting the\nskb but the socket reference is kept as-is. This is an issue if the\noriginal skb is later orphaned as we can hit the following bug:\n\n  kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)\n  RIP: 0010:ip_rcv_core+0x8b2/0xca0\n  Call Trace:\n   ip_rcv+0xab/0x6e0\n   __netif_receive_skb_one_core+0x168/0x1b0\n   process_backlog+0x384/0x1100\n   __napi_poll.constprop.0+0xa1/0x370\n   net_rx_action+0x925/0xe50\n\nThe above can happen following a sequence of events when using\nOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an\nOVS_ACTION_ATTR_OUTPUT action:\n\n1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb\n   goes through queue_gso_packets and then __udp_gso_segment, where its\n   destructor is removed.\n2. The segments' data are copied and sent to userspace.\n3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the\n   same original skb is sent to its path.\n4. If it later hits skb_orphan, we hit the bug.\n\nFix this by also removing the reference to the socket in\n__udp_gso_segment.(CVE-2025-21926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix use after free in lec_send()\n\nThe ->send() operation frees skb so save the length before calling\n->send() to avoid a use after free.(CVE-2025-22004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nposix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()\n\nIf an exiting non-autoreaping task has already passed exit_notify() and\ncalls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent\nor debugger right after unlock_task_sighand().\n\nIf a concurrent posix_cpu_timer_del() runs at that moment, it won't be\nable to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or\nlock_task_sighand() will fail.\n\nAdd the tsk->exit_state check into run_posix_cpu_timers() to fix this.\n\nThis fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because\nexit_task_work() is called before exit_notify(). But the check still\nmakes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail\nanyway in this case.(CVE-2025-38352)","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-277.0.0.180.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","perf-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-277.0.0.180.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-277.0.0.180.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","perf-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-277.0.0.180.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38352"}],"database_specific":{"severity":"High"}}