{"id":"OESA-2025-2469","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\nNFSD: Protect against send buffer overflow in NFSv2 READ\n\nSince before the git era, NFSD has conserved the number of pages\nheld by each nfsd thread by combining the RPC receive and send\nbuffers into a single array of pages. This works because there are\nno cases where an operation needs a large RPC Call message and a\nlarge RPC Reply at the same time.\n\nOnce an RPC Call has been received, svc_process() updates\nsvc_rqst::rq_res to describe the part of rq_pages that can be\nused for constructing the Reply. This means that the send buffer\n(rq_res) shrinks when the received RPC record containing the RPC\nCall is large.\n\nA client can force this shrinkage on TCP by sending a correctly-\nformed RPC Call header contained in an RPC record that is\nexcessively large. The full maximum payload size cannot be\nconstructed in that case.(CVE-2022-50410)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: az6007: Fix null-ptr-deref in az6007_i2c_xfer()\n\nIn az6007_i2c_xfer, msg is controlled by user. When msg[i].buf\nis null and msg[i].len is zero, former checks on msg[i].buf would be\npassed. Malicious data finally reach az6007_i2c_xfer. If accessing\nmsg[i].buf[0] without sanity check, null ptr deref would happen.\nWe add check on msg[i].len to prevent crash.\n\nSimilar commit:\ncommit 0ed554fd769a\n("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")(CVE-2023-53220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkobject: Add sanity check for kset->kobj.ktype in kset_register()\n\nWhen I register a kset in the following way:\n\tstatic struct kset my_kset;\n\tkobject_set_name(&my_kset.kobj, "my_kset");\n        ret = kset_register(&my_kset);\n\nA null pointer dereference exception is occurred:\n[ 4453.568337] Unable to handle kernel NULL pointer dereference at \\\nvirtual address 0000000000000028\n... ...\n[ 4453.810361] Call trace:\n[ 4453.813062]  kobject_get_ownership+0xc/0x34\n[ 4453.817493]  kobject_add_internal+0x98/0x274\n[ 4453.822005]  kset_register+0x5c/0xb4\n[ 4453.825820]  my_kobj_init+0x44/0x1000 [my_kset]\n... ...\n\nBecause I didn't initialize my_kset.kobj.ktype.\n\nAccording to the description in Documentation/core-api/kobject.rst:\n - A ktype is the type of object that embeds a kobject.  Every structure\n   that embeds a kobject needs a corresponding ktype.\n\nSo add sanity check to make sure kset->kobj.ktype is not NULL.(CVE-2023-53480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-mmio: don't break lifecycle of vm_dev\n\nvm_dev has a separate lifecycle because it has a 'struct device'\nembedded. Thus, having a release callback for it is correct.\n\nAllocating the vm_dev struct with devres totally breaks this protection,\nthough. Instead of waiting for the vm_dev release callback, the memory\nis freed when the platform_device is removed. Resulting in a\nuse-after-free when finally the callback is to be called.\n\nTo easily see the problem, compile the kernel with\nCONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.\n\nThe fix is easy, don't use devres in this case.\n\nFound during my research about object lifetime problems.(CVE-2023-53515)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb\n\nThe syzbot fuzzer identified a problem in the usbnet driver:\n\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nModules linked in:\nCPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nCode: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7\nRSP: 0018:ffffc9000463f568 EFLAGS: 00010086\nRAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000\nRDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001\nRBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003\nR13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500\nFS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0\nCall Trace:\n <TASK>\n usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453\n __netdev_start_xmit include/linux/netdevice.h:4918 [inline]\n netdev_start_xmit include/linux/netdevice.h:4932 [inline]\n xmit_one net/core/dev.c:3578 [inline]\n dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594\n...\n\nThis bug is caused by the fact that usbnet trusts the bulk endpoint\naddresses its probe routine receives in the driver_info structure, and\nit does not check to see that these endpoints actually exist and have\nthe expected type and directions.\n\nThe fix is simply to add such a check.(CVE-2023-53548)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser->buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release->\nftrace_process_regex->strsep->strpbrk. We can solve this problem by\nlimiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the "proxy" option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the "any" remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor's MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n <TASK>\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n <TASK>\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)","modified":"2026-03-11T07:12:18.999008Z","published":"2025-10-17T14:55:58Z","upstream":["CVE-2022-50410","CVE-2023-53220","CVE-2023-53480","CVE-2023-53515","CVE-2023-53548","CVE-2025-39683","CVE-2025-39850"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2469"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50410"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53480"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53515"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53548"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39683"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39850"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP3","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-285.0.0.187.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","perf-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-285.0.0.187.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-285.0.0.187.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","perf-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-285.0.0.187.oe2203sp3.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-2469.json"}}],"schema_version":"1.7.5"}