GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2026-2077
Vulnerability from osv_openeuler
Published
2026-04-25 11:11
Modified
2026-08-06 11:11
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

bonding: fix use-after-free due to enslave fail after slave array update

Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.

It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummy

Then run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"

The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 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 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] <TASK> [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfxdevqueue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 bonding

In the Linux kernel, the following vulnerability has been resolved:

udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n

When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: <TASK> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)

This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.(CVE-2026-23439)

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()

Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].

smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().

This leads to two issues:

1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) / No lock on listener / smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash!

Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed.

Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight.

  • Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().
  • Use rcu_read_lock() to protect reading sk_user_data.
  • Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.

Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)

In 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.

In 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.

The 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.

The 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)

In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.(CVE-2026-31402)

In 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)

In the Linux kernel, the following vulnerability has been resolved:

ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()

When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup.

The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA.

Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free:

BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK>

Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692)

Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751)

The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer.

Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed:

-ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.0.4.132.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\u0026gt;/dev/null 2\u0026gt;\u0026amp;1; done;\n mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp \u0026quot;dp=1-1023, flags=syn\u0026quot;\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 \u0026lt;80\u0026gt; 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]  \u0026lt;TASK\u0026gt;\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    \u0026lt;TASK\u0026gt;\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-\u0026gt;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-\u0026gt;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() -\u0026gt;\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-\u0026gt;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-\u0026gt;sk) x2\n                                   -\u0026gt; smc_sock freed!\n    tcp_check_req()\n      smc_tcp_syn_recv_sock():\n        smc = user_data(sk)\n          -\u0026gt; NULL or dangling\n        smc-\u0026gt;queued_smc_hs\n          -\u0026gt; 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(\u0026amp;smc-\u0026gt;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\u0026apos;s file descriptor is closed while in the middle of reading a cache_request (rp-\u0026gt;offset != 0), cache_release() decrements the request\u0026apos;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\u0026apos;s lifetime. exports_proc_open() captures the caller\u0026apos;s current network namespace and stores its svc_export_cache in seq-\u0026gt;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-\u0026gt;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  \u0026lt;TASK\u0026gt;\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  \u0026lt;/TASK\u0026gt;\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-\u0026gt;gpe \u0026lt; 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)",
  "id": "OESA-2026-2077",
  "modified": "2026-08-06T11:11:04Z",
  "published": "2026-04-25T11:11:04Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-23171",
    "CVE-2026-23439",
    "CVE-2026-23450",
    "CVE-2026-31400",
    "CVE-2026-31402",
    "CVE-2026-31403",
    "CVE-2026-31426"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.