{"schema_version":"1.7.2","id":"OESA-2026-2077","modified":"2026-04-25T05:49:56Z","published":"2026-04-25T05:49:56Z","upstream":["CVE-2026-23171","CVE-2026-23439","CVE-2026-23450","CVE-2026-31400","CVE-2026-31402","CVE-2026-31403","CVE-2026-31426"],"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\nbonding: fix use-after-free due to enslave fail after slave array update\n\nFix a use-after-free which happens due to enslave failure after the new\nslave has been added to the array. Since the new slave can be used for Tx\nimmediately, we can use it after it has been freed by the enslave error\ncleanup path which frees the allocated slave memory. Slave update array is\nsupposed to be called last when further enslave failures are not expected.\nMove it after xdp setup to avoid any problems.\n\nIt is very easy to reproduce the problem with a simple xdp_pass prog:\n ip l add bond1 type bond mode balance-xor\n ip l set bond1 up\n ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass\n ip l add dumdum type dummy\n\nThen run in parallel:\n while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;\n mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"\n\nThe crash happens almost immediately:\n [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI\n [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]\n [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)\n [  605.602979] Tainted: [B]=BAD_PAGE\n [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210\n [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89\n [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213\n [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000\n [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be\n [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c\n [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000\n [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84\n [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000\n [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0\n [  605.603373] Call Trace:\n [  605.603392]  <TASK>\n [  605.603410]  __dev_queue_xmit+0x448/0x32a0\n [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10\n [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10\n [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10\n [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603546]  ? _printk+0xcb/0x100\n [  605.603566]  ? __pfx__printk+0x10/0x10\n [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603627]  ? add_taint+0x5e/0x70\n [  605.603648]  ? add_taint+0x2a/0x70\n [  605.603670]  ? end_report.cold+0x51/0x75\n [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding](CVE-2026-23171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n\n\nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0\n(success) without actually creating a socket. Callers such as\nfou_create() then proceed to dereference the uninitialized socket\npointer, resulting in a NULL pointer dereference.\n\nThe captured NULL deref crash:\n  BUG: kernel NULL pointer dereference, address: 0000000000000018\n  RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764)\n  [...]\n  Call Trace:\n    <TASK>\n    genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114)\n    genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209)\n    [...]\n    netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n    genl_rcv (net/netlink/genetlink.c:1219)\n    netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n    netlink_sendmsg (net/netlink/af_netlink.c:1894)\n    __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1))\n    __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1))\n    __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1))\n    do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n    entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)\n\nThis patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so\ncallers correctly take their error paths. There is only one caller of\nthe vulnerable function and only privileged users can trigger it.(CVE-2026-23439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()\n\nSyzkaller reported a panic in smc_tcp_syn_recv_sock() [1].\n\nsmc_tcp_syn_recv_sock() is called in the TCP receive path\n(softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP\nlistening socket). It reads sk_user_data to get the smc_sock\npointer. However, when the SMC listen socket is being closed\nconcurrently, smc_close_active() sets clcsock->sk_user_data\nto NULL under sk_callback_lock, and then the smc_sock itself\ncan be freed via sock_put() in smc_release().\n\nThis leads to two issues:\n\n1) NULL pointer dereference: sk_user_data is NULL when\n   accessed.\n2) Use-after-free: sk_user_data is read as non-NULL, but the\n   smc_sock is freed before its fields (e.g., queued_smc_hs,\n   ori_af_ops) are accessed.\n\nThe race window looks like this (the syzkaller crash [1]\ntriggers via the SYN cookie path: tcp_get_cookie_sock() ->\nsmc_tcp_syn_recv_sock(), but the normal tcp_check_req() path\nhas the same race):\n\n  CPU A (softirq)              CPU B (process ctx)\n\n  tcp_v4_rcv()\n    TCP_NEW_SYN_RECV:\n    sk = req->rsk_listener\n    sock_hold(sk)\n    /* No lock on listener */\n                               smc_close_active():\n                                 write_lock_bh(cb_lock)\n                                 sk_user_data = NULL\n                                 write_unlock_bh(cb_lock)\n                                 ...\n                                 smc_clcsock_release()\n                                 sock_put(smc->sk) x2\n                                   -> smc_sock freed!\n    tcp_check_req()\n      smc_tcp_syn_recv_sock():\n        smc = user_data(sk)\n          -> NULL or dangling\n        smc->queued_smc_hs\n          -> crash!\n\nNote that the clcsock and smc_sock are two independent objects\nwith separate refcounts. TCP stack holds a reference on the\nclcsock, which keeps it alive, but this does NOT prevent the\nsmc_sock from being freed.\n\nFix this by using RCU and refcount_inc_not_zero() to safely\naccess smc_sock. Since smc_tcp_syn_recv_sock() is called in\nthe TCP three-way handshake path, taking read_lock_bh on\nsk_callback_lock is too heavy and would not survive a SYN\nflood attack. Using rcu_read_lock() is much more lightweight.\n\n- Set SOCK_RCU_FREE on the SMC listen socket so that\n  smc_sock freeing is deferred until after the RCU grace\n  period. This guarantees the memory is still valid when\n  accessed inside rcu_read_lock().\n- Use rcu_read_lock() to protect reading sk_user_data.\n- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the\n  smc_sock. If the refcount has already reached zero (close\n  path completed), it returns false and we bail out safely.\n\nNote: smc_hs_congested() has a similar lockless read of\nsk_user_data without rcu_read_lock(), but it only checks for\nNULL and accesses the global smc_hs_wq, never dereferencing\nany smc_sock field, so it is not affected.\n\nReproducer was verified with mdelay injection and smc_run,\nthe issue no longer occurs with this patch applied.\n\n[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)\n\nIn the Linux kernel, a memory leak vulnerability has been identified in the sunrpc subsystem. When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request.\n\nIn cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup.\n\nThe only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up.\n\nThe solution is to add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.(CVE-2026-31400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix heap overflow in NFSv4.0 LOCK replay cache\n\nThe NFSv4.0 replay cache uses a fixed 112-byte inline buffer\n(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.\nThis size was calculated based on OPEN responses and does not account\nfor LOCK denied responses, which include the conflicting lock owner as\na variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).\n\nWhen a LOCK operation is denied due to a conflict with an existing lock\nthat has a large owner, nfsd4_encode_operation() copies the full encoded\nresponse into the undersized replay buffer via read_bytes_from_xdr_buf()\nwith no bounds check. This results in a slab-out-of-bounds write of up\nto 944 bytes past the end of the buffer, corrupting adjacent heap memory.\n\nThis can be triggered remotely by an unauthenticated attacker with two\ncooperating NFSv4.0 clients: one sets a lock with a large owner string,\nthen the other requests a conflicting lock to provoke the denial.\n\nWe could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full\nopaque, but that would increase the size of every stateowner, when most\nlockowners are not that large.\n\nInstead, fix this by checking the encoded response length against\nNFSD4_REPLAY_ISIZE before copying into the replay buffer. If the\nresponse is too large, set rp_buflen to 0 to skip caching the replay\npayload. The status is still cached, and the client already received the\ncorrect response on the original request.(CVE-2026-31402)\n\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd. The /proc/fs/nfs/exports proc entry is created at module init and persists for the module's lifetime. exports_proc_open() captures the caller's current network namespace and stores its svc_export_cache in seq->private, but takes no reference on the namespace. If the namespace is subsequently torn down (e.g. container destruction after the opener does setns() to a different namespace), nfsd_net_exit() calls nfsd_export_shutdown() which frees the cache. Subsequent reads on the still-open fd dereference the freed cache_detail, walking a freed hash table. Hold a reference on the struct net for the lifetime of the open file descriptor. This prevents nfsd_net_exit() from running -- and thus prevents nfsd_export_shutdown() from freeing the cache -- while any exports fd is open. cache_detail already stores its net pointer (cd->net, set by cache_create_net()), so exports_release() can retrieve it without additional per-file storage.(CVE-2026-31403)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: EC: clean up handlers on probe failure in acpi_ec_setup()\n\nWhen ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware\nplatforms, it has already started the EC and installed the address\nspace handler with the struct acpi_ec pointer as handler context.\nHowever, acpi_ec_setup() propagates the error without any cleanup.\n\nThe caller acpi_ec_add() then frees the struct acpi_ec for non-boot\ninstances, leaving a dangling handler context in ACPICA.\n\nAny subsequent AML evaluation that accesses an EC OpRegion field\ndispatches into acpi_ec_space_handler() with the freed pointer,\ncausing a use-after-free:\n\n BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)\n Write of size 8 at addr ffff88800721de38 by task init/1\n Call Trace:\n  <TASK>\n  mutex_lock (kernel/locking/mutex.c:289)\n  acpi_ec_space_handler (drivers/acpi/ec.c:1362)\n  acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)\n  acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)\n  acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)\n  acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)\n  acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)\n  acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)\n  </TASK>\n\n Allocated by task 1:\n  acpi_ec_alloc (drivers/acpi/ec.c:1424)\n  acpi_ec_add (drivers/acpi/ec.c:1692)\n\n Freed by task 1:\n  kfree (mm/slub.c:6876)\n  acpi_ec_add (drivers/acpi/ec.c:1751)\n\nThe bug triggers on reduced-hardware EC platforms (ec->gpe < 0)\nwhen the GPIO IRQ provider defers probing. Once the stale handler\nexists, any unprivileged sysfs read that causes AML to touch an\nEC OpRegion (battery, thermal, backlight) exercises the dangling\npointer.\n\nFix this by calling ec_remove_handlers() in the error path of\nacpi_ec_setup() before clearing first_ec. ec_remove_handlers()\nchecks each EC_FLAGS_* bit before acting, so it is safe to call\nregardless of how far ec_install_handlers() progressed:\n\n  -ENODEV  (handler not installed): only calls acpi_ec_stop()\n  -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)","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-145.0.4.132.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.4.132.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-devel-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-headers-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-source-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-tools-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.4.132.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.4.132.oe2403.aarch64.rpm","perf-6.6.0-145.0.4.132.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-145.0.4.132.oe2403.aarch64.rpm","python3-perf-6.6.0-145.0.4.132.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.4.132.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-145.0.4.132.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.4.132.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-devel-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-headers-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-source-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-tools-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.4.132.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.4.132.oe2403.x86_64.rpm","perf-6.6.0-145.0.4.132.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-145.0.4.132.oe2403.x86_64.rpm","python3-perf-6.6.0-145.0.4.132.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.4.132.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23171"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23439"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31402"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31403"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31426"}],"database_specific":{"severity":"High"}}