OESA-2026-3987 (CVE-2026-64405)
Vulnerability from osv_openeuler – Published: 2026-09-20 13:23 – Updated: 2026-09-20 13:23 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
hci_abort_conn() read hci_skb_event(hdev->sent_cmd) when a connection was pending, but hdev->sent_cmd can be NULL while req_status is still HCI_REQ_PEND, leading to a NULL pointer dereference and a general protection fault from the hci_rx_work() receive path.
Instead of inspecting hdev->sent_cmd, track the in-flight create connection command with a new per-connection HCI_CONN_CREATE flag and route all cancellation through hci_cancel_connect_sync(), which dispatches to a dedicated per-type cancel function. The create command is in exactly one of two states: still queued, or in flight. The cancel function holds cmd_sync_work_lock across the whole decision: the worker takes this lock to dequeue every entry, so while it is held a queued command cannot start running and an in-flight command cannot complete and let the next command become pending. This keeps the flag test and hci_cmd_sync_cancel() atomic with respect to the worker, so a queued command is simply dequeued, and an in-flight command owned by this connection is cancelled without the risk of cancelling an unrelated command that became pending in the meantime. CIS uses the same flag mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.
hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear HCI_CONN_CREATE after the create command completes, but the command status handler can free conn via hci_conn_del() (for example when the controller rejects the connection) while the worker is still blocked on the connection complete event. Hold a reference on conn across the create command so the flag can be cleared without a use-after-free.(CVE-2026-64405)
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: fix race between registration and connection abortion
This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked.
Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.(CVE-2026-68095)
In the Linux kernel, the following vulnerability has been resolved:
tcp: challenge ACK for non-exact RST in SYN-RECEIVED
The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK.
RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped.
Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.(CVE-2026-68118)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: serialize qdisc_rtab_list against concurrent get/put
qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees.
That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide.
BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048
Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.(CVE-2026-68138)
In the Linux kernel, the following vulnerability has been resolved:
iomap: fix out-of-bounds bitmap_set() with zero-length range
ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation.
Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0.
Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.(CVE-2026-68145)
In the Linux kernel, the following vulnerability has been resolved:
dm-verity: fix buffer overflow in FEC calculation
There's a buffer overflow in dm-verity-fec:
if (neras && neras <= v->fec->roots) fio->erasures[(neras)++] = i;
This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.(CVE-2026-72098)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conncount: fix zone comparison in tuple dedup
The "already exists" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument.
Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone.
nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents.
Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.(CVE-2026-72247)
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix err_chunk memory leaks in INIT handling
When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths:
-
In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it.
-
In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path.
-
In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it.
Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init().(CVE-2026-72413)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid R5_Overlap races while breaking stripe batches
KCSAN report a race in break_stripe_batch_list() vs. raid5_make_request() on sh->dev[i].flags (plain word write vs. atomic bit op)..
and .. one possible scenario is:
CPU1 CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags) -> wake_up_bit(sh2->dev[i].flags) raid5_make_request() -> add_all_stripe_bios(sh2) -> lock(sh2) -> stripe_bio_overlaps(sh2) returns true batch_head is NULL, so new bio overlap exist bio on sh2 -> true -> set_bit(R5_Overlap, sh2->dev[i].flags) -> unlock(sh2) -> wait_on_bit(sh2->dev[i].flags) -> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap
No wait_up_bit(), CPU2 could be wait_on_bit() forever...
Fix by : - Expand the protect zone. - Use batch_head's device flag's snaphot when no held head_sh->stripe_lock. - Move sh/head_sh->batch_head = NULL to the end of protected zone , and , any concurrent add_all_stripe_bios() grabs sh->stripe_lock now either: - see batch_head != null, and , is rejected by stripe_bio_overlaps() under the lock (no R5_Overlap wait ) , or , - sees batch_head == NULL, only after dev[i].flags has already been set and the prior R5_Overlap waiters worken.
KCSAN report:
BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request
write (marked) to 0xffff8e89c8117548 of 8 bytes by task 4042 on cpu 0: raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x64_sys_io_submit+0xf7/0x220 x64_sys_call+0x1907/0x1c60 do_syscall_64+0x130/0x570 entry_SYSCALL_64_after_hwframe+0x76/0x7e
read to 0xffff8e89c8117548 of 8 bytes by task 4010 on cpu 5: break_stripe_batch_list+0x249/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 md_thread+0x15a/0x2d0 kthread+0x1e3/0x220 ret_from_fork+0x37a/0x410 ret_from_fork_asm+0x1a/0x30
value changed: 0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap(CVE-2026-72420)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Proper rollback if the ioremap fails
bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.(CVE-2026-72496)
In the Linux kernel, the following vulnerability has been resolved:
tcp: clear sock_ops cb flags before force-closing a child socket
A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it.
If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me():
WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: <IRQ> tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 </IRQ>
The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.(CVE-2026-74268)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().
syzbot reported use-after-free in nsim_fib4_prepare_event(). [0]
The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe.
- mlxsw_sp_router_fib4_event()
- rocker_router_fib_event()
- nsim_fib4_prepare_event()
refcount_inc_not_zero() must be used, but it would be too late there.
Let's guarantee the lifetime of fib_info in fib_leaf_notify().
Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock.
[0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: <TASK> __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>(CVE-2026-74289)
In the Linux kernel, the following vulnerability has been resolved:
vhost: fix vhost_get_avail_idx for a non empty ring
vhost_get_avail_idx is supposed to report whether it has updated vq->avail_idx. Instead, it returns whether all entries have been consumed, which is usually the same. But not always - in drivers/vhost/net.c and when mergeable buffers have been enabled, the driver checks whether the combined entries are big enough to store an incoming packet. If not, the driver re-enables notifications with available entries still in the ring. The incorrect return value from vhost_get_avail_idx propagates through vhost_enable_notify and causes the host to livelock if the guest is not making progress, as vhost will immediately disable notifications and retry using the available entries.
This goes back to commit d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") which changed vhost_enable_notify() to compare the freshly read avail index against vq->last_avail_idx instead of the previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move smp_rmb() into vhost_get_avail_idx()") then carried over the same comparison when refactoring vhost_enable_notify() to call the unified vhost_get_avail_idx().
The obvious fix is to make vhost_get_avail_idx do what the comment says it does and report whether new entries have been added.(CVE-2026-74356)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix deadlock in read error recovery path
raid1d and raid10d may resubmit a split md cloned bio while handling a read error. In this case, resubmitting the bio can lead to a deadlock if the array is suspended before md_handle_request() acquires an active_io reference via percpu_ref_tryget_live().
Since the cloned bio already holds an active_io reference, trying to acquire another reference via percpu_ref_tryget_live() can lead to a deadlock while the array is suspended.
Fix this by using percpu_ref_get() for md cloned bios.(CVE-2026-74375)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Fix advertising data UAFs
hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response.
An advertising termination event can therefore interleave as follows:
hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false
KASAN reported:
BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730
Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller.
Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait.(CVE-2026-74509)
In the Linux kernel, the following vulnerability has been resolved:
iommu/iommufd: Fix IOPF group ownership UAF
iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list.
When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF.
Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD.(CVE-2026-74520)
In the Linux kernel, the following vulnerability has been resolved:
net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()
syzbot reported a memory leak [1] in the UDP tunnel NIC offload code.
When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early:
if (utn->work_pending)
return;
Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently.
Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn.
To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock.
The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work.
[1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm "syz-executor", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478(CVE-2026-74543)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds
u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char,
0-255) into the kernel knode object without bounds validation. When a
packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates
ntohs(offmask & *data) >> offshift where the left operand is a 16-bit
value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior
per C11 6.5.7p3, triggerable by an unprivileged user via user/network
namespaces.
UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int
Fix this by rejecting offshift >= 16 during filter creation in u32_change().(CVE-2026-74544)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: make nft_object rhltable per table
The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too.
Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup().(CVE-2026-74565)
In the Linux kernel, the following vulnerability has been resolved:
eventfs: Use children field for rcu head and add memory barriers
When an eventfs inode is freed, it sets ei->is_freed and then uses its ei->list to add it to the srcu link list as the list field is a union with the rcu list head. As the ei->list is used to iterate over an SRCU protected list without taking the eventfs_mutex, there's nothing stopping the iteration over that list to see the ei->rcu instead of the ei->list and it will read a corrupt target.
To fix this, change the union of the rcu list head with the children list. On freeing the eventfs inode, set the is_free and execute a smp_wmb() before adding the eventfs inode to the SRCU list.
On iteration of the ei->children list, at the start, execute a smp_rmb() and then read the is_freed of the ei to see if the children list is still valid. If is_freed is set, then the ei_child read is not valid and the loop should exit immediately.(CVE-2026-74605)
In the Linux kernel, the following vulnerability has been resolved:
packet: use consistent hard_header_len in TX_RING send path
tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative.
Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb().
The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.(CVE-2026-74668)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix netns reference imbalance in conntrack kfuncs
The opts argument of the BPF conntrack kfuncs can point to a shared map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference.
The reference imbalance can occur as follows:
CPU 0 CPU 1 read opts->netns_id (-1) skip get_net_ns_by_id() write opts->netns_id (id) read opts->netns_id (id) put_net(net) / no matching get /
The reverse transition leaks the reference. Repeating the unmatched put can destroy a live namespace and crash later users.
The kernel reported:
Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700 Call Trace: __sys_bpf+0x1662/0x50c0 __x64_sys_bpf+0x73/0xb0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception
Snapshot every input field of opts with READ_ONCE() before validating or using it. The netns_id snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation. The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation.(CVE-2026-74715)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: avoid out-of-bounds write in ip_vs_nat_icmp
Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area.
Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header.
Modify some IPv4 header checks by reading the ihl field only once.(CVE-2026-74724)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Pin the 'struct nfs_server' during a FREE_STATEID call
Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.(CVE-2026-74730)
In the Linux kernel, the following vulnerability has been resolved:
firewire: ohci: fix NULL pointer dereference in ar_context_release
During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release().
When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()).
ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772
To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer.(CVE-2026-74734)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: revalidate ihl to prevent out-of-bounds access
While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access.
One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls.
Add check to drop the packet if the ihl field is changed.(CVE-2026-74747)
In the Linux kernel, the following vulnerability has been resolved:
xfs: bounds-check buffer log item's dirty bitmap
xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item:
memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT),
item->ri_buf[i].iov_base,
nbits << XFS_BLF_SHIFT);
The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere.
Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error.
Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.(CVE-2026-80536)
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.(CVE-2026-80549)
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Ensure first IDAW remains constant
The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL.
Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.(CVE-2026-80551)
In the Linux kernel, the following vulnerability has been resolved:
openrisc: signal: do not restore privileged SR bits on sigreturn
restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control.
An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason.
Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry.
Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged.(CVE-2026-80560)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Mark LPI enter functions as __cpuidle
When function tracing or Kprobes is enabled, entering an ACPI Low Power Idle (LPI) state triggers the following RCU splat:
RCU not on for: acpi_idle_lpi_enter+0x4/0xd8 WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228
The acpi_idle_lpi_enter() function is invoked within the cpuidle path after RCU has already been disabled for the current local CPU. Consequently, ftrace's function_trace_call() expects RCU to be actively watching before recording trace data, emitting a warning if it is not.
Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with __cpuidle. This moves these functions into the '.cpuidle.text' section, implicitly disabling ftrace instrumentation (notrace) along this sensitive path and preventing trace-induced RCU warnings during idle entry.(CVE-2026-80611)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: fix unaligned memory access in timestamp adjustment
Use get_unaligned_be32() and put_unaligned_be32() to safely read and write the timestamp fields. This prevents performance degradation due to unaligned memory access or even a crash on strict alignment architectures.
This follows the implementation of timestamp parsing in the networking stack at tcp_parse_options() and synproxy_parse_options().(CVE-2026-80637)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: ensure no dangling hcon references in iso_conn
After iso_conn_del(), ISO sockets should not dereference the hcon any more. Currently, clearing iso_conn::hcon relies on iso_conn_del() releasing the last reference to the iso_conn.
Simplify this by explicitly clearing conn->hcon in iso_conn_del(), to avoid more complex reasoning on races about who holds the last reference.(CVE-2026-80721)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.31.162.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.31.162.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.31.162.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.3.31.162.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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\nBluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()\n\nhci_abort_conn() read hci_skb_event(hdev-\u0026gt;sent_cmd) when a connection\nwas pending, but hdev-\u0026gt;sent_cmd can be NULL while req_status is still\nHCI_REQ_PEND, leading to a NULL pointer dereference and a general\nprotection fault from the hci_rx_work() receive path.\n\nInstead of inspecting hdev-\u0026gt;sent_cmd, track the in-flight create\nconnection command with a new per-connection HCI_CONN_CREATE flag and\nroute all cancellation through hci_cancel_connect_sync(), which\ndispatches to a dedicated per-type cancel function. The create command\nis in exactly one of two states: still queued, or in flight. The cancel\nfunction holds cmd_sync_work_lock across the whole decision: the worker\ntakes this lock to dequeue every entry, so while it is held a queued\ncommand cannot start running and an in-flight command cannot complete\nand let the next command become pending. This keeps the flag test and\nhci_cmd_sync_cancel() atomic with respect to the worker, so a queued\ncommand is simply dequeued, and an in-flight command owned by this\nconnection is cancelled without the risk of cancelling an unrelated\ncommand that became pending in the meantime. CIS uses the same flag\nmechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.\n\nhci_acl_create_conn_sync() and hci_le_create_conn_sync() clear\nHCI_CONN_CREATE after the create command completes, but the command\nstatus handler can free conn via hci_conn_del() (for example when the\ncontroller rejects the connection) while the worker is still blocked on\nthe connection complete event. Hold a reference on conn across the\ncreate command so the flag can be cleared without a use-after-free.(CVE-2026-64405)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse-uring: fix race between registration and connection abortion\n\nThis fixes this race:\n- thread a: io_uring_enter -\u0026gt; register sqe -\u0026gt;\n fuse_uring_create_ring_ent -\u0026gt; allocate ent but doesn\u0026apos;t grab queue_ref\n yet\n- thread b: fuse_conn_destroy() -\u0026gt; fuse_chan_abort() -\u0026gt;\n fuse_uring_abort() is a no-op due to queue ref being 0\n- thread a: grabs the queue_ref, queue_ref is now 1, rest of\n fuse_uring_do_register() logic executes\n- thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs\n and calls\n \u0026quot;wait_event(ring-\u0026gt;stop_waitq, atomic_read(\u0026amp;ring-\u0026gt;queue_refs) == 0);\u0026quot;\nThe abort/unmount thread will hang indefinitely in unkillable state as\nnothing will decrement queue_refs or wake stop_waitq, and the ring,\nqueue, and ent are leaked.\n\nFix this by checking fch-\u0026gt;connected under fch-\u0026gt;lock after the created\nent has grabbed a ref count on the queue. This ensures that in the\nscenario above, it is guaranteed that we either release the queue ref\nand wake up stop_waitq (in case fuse_chan_wait_aborted() is already\nwaiting) in fuse_uring_do_register() when we detect !fch-\u0026gt;connected, or\nif the connection is aborted after the check, it is guaranteed that the\nasync teardown worker will be running in the background cleaning up ents\nand decrementing the ent\u0026apos;s ref on the queue, which will unblock the\neventual queue and ring teardown.(CVE-2026-68095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: challenge ACK for non-exact RST in SYN-RECEIVED\n\nThe SYN-RECEIVED request-socket path in tcp_check_req() accepts an\nin-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A\nnon-exact RST therefore removes the request instead of eliciting a\nchallenge ACK.\n\nRFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in\nSYN-RECEIVED: an exact RST resets the connection, while a non-exact\nin-window RST must trigger a challenge ACK and be dropped.\n\nApply that check before the ACK-field validation, following the RFC\nsequence-number, RST, then ACK processing order. Factor the per-netns\nchallenge ACK quota out of tcp_send_challenge_ack() so request sockets\ncan share it. Use the request socket\u0026apos;s send_ack() callback and its own\nout-of-window ACK timestamp to send and rate-limit the response.(CVE-2026-68118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: serialize qdisc_rtab_list against concurrent get/put\n\nqdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly\nlinked list qdisc_rtab_list and a plain non-atomic \u0026apos;int refcnt\u0026apos; with no\nlock. This was only safe because every caller historically held the RTNL\nmutex, which serialized all rate-table lookups, inserts and frees.\n\nThat invariant no longer holds. cls_flower sets\nTCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false\nfor it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through\ntcf_exts_validate_ex() -\u0026gt; tcf_action_init() -\u0026gt; tcf_action_init_1() -\u0026gt;\ntcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the\nRTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each\nadding a flower filter with a police action carrying the same rate, then\nrace on qdisc_rtab_list and on the non-atomic refcnt, leading to a\nuse-after-free / double-free of the kmalloc-2k struct qdisc_rate_table.\nqdisc_rtab_list is a single global (not per-netns), so the corrupted\nobject is shared system-wide.\n\n BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160\n qdisc_put_rtab+0x12f/0x160\n tcf_police_init+0xda9/0x1590\n tcf_action_init_1+0x460/0x6b0\n tcf_action_init+0x439/0xa40\n tcf_exts_validate_ex+0x42d/0x550\n fl_change+0xddd/0x7da0\n tc_new_tfilter+0xaa7/0x2420\n rtnetlink_rcv_msg+0x95e/0xe90\n which belongs to the cache kmalloc-2k of size 2048\n\nProtect qdisc_rtab_list and the refcount with a dedicated spinlock. The\n(sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before\ntaking the lock; if a concurrent inserter added an identical table in the\nmeantime the freshly allocated one is freed under the lock, so no\nduplicate is leaked. qdisc_put_rtab() now decrements the refcount and\nunlinks under the same lock.(CVE-2026-68138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: fix out-of-bounds bitmap_set() with zero-length range\n\nifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk\nas (off + len - 1) \u0026gt;\u0026gt; i_blkbits. When off is 0 and len is 0, the\nunsigned subtraction underflows to SIZE_MAX, producing a huge\nlast_blk and nr_blks value that causes bitmap_set() to write far\nbeyond the ifs-\u0026gt;state allocation.\n\nRegarding ifs_set_range_uptodate(), it is temporarily safe because len\ncannot be passed in as 0. However, for ifs_set_range_dirty() this is\nreachable from __iomap_write_end(): when copy_folio_from_iter_atomic()\nreturns 0 (e.g. user buffer fault) and the folio is already uptodate,\nthe guard at the top of __iomap_write_end() does not trigger because\n!folio_test_uptodate() is false, and iomap_set_range_dirty() is called\nwith copied == 0.\n\nAdd a !len guard to both functions before the computation, so that a\nzero-length range is a no-op.(CVE-2026-68145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-verity: fix buffer overflow in FEC calculation\n\nThere\u0026apos;s a buffer overflow in dm-verity-fec:\n\nif (neras \u0026amp;\u0026amp; *neras \u0026lt;= v-\u0026gt;fec-\u0026gt;roots)\n\tfio-\u0026gt;erasures[(*neras)++] = i;\n\nThis allows *neras to reach roots + 1 (the post-increment pushes it past\nroots). This value is then passed as no_eras to decode_rs8(). Inside the\nRS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator\npolynomial loop writes lambda[j] where j can reach nroots + 1 \u2014 one\nelement past the end of lambda[] (which is sized nroots + 1, valid\nindices 0..nroots). The out-of-bounds write lands on syn[0], corrupting\nthe syndrome buffer.(CVE-2026-72098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: fix zone comparison in tuple dedup\n\nThe \u0026quot;already exists\u0026quot; dedup logic in __nf_conncount_add() decides\nwhether a connection has already been counted and can be skipped instead\nof incrementing the connlimit count. It compares the conntrack zone of a\nlist entry with the zone of the connection being added using\nnf_ct_zone_id() and nf_ct_zone_equal(), passing conn-\u0026gt;zone.dir or\nzone-\u0026gt;dir as the direction argument.\n\nThose helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0\nand IP_CT_DIR_REPLY is 1. However, zone-\u0026gt;dir is a u8 bitmask:\nNF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and\nNF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction\nshifts the meaning of every non-zero value. An ORIG-only zone passes 1\nand is tested as REPLY, while REPL-only and default zones pass 2 or 3 and\ntest bits beyond the valid direction range. In those cases\nnf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using\nthe real zone id, so different zones can be treated as equal and dedup\ncollapses to tuple equality alone.\n\nnf_conncount stores and compares the original-direction tuple for a\nconnection. If an skb already has an attached conntrack entry,\nget_ct_or_tuple_from_skb() explicitly copies\nct-\u0026gt;tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet\u0026apos;s\nctinfo. Therefore the zone comparison in the tuple dedup path must use\nIP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a\nzone id applies, not which direction this conncount tuple represents.\n\nFix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly.\nDo not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone\nids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the\ndirection-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional\nzone contains the ORIG bit, so it naturally returns the real zone id;\nreply-only zones continue to fall back for original-direction tuple\ncomparisons.(CVE-2026-72247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix err_chunk memory leaks in INIT handling\n\nWhen sctp_verify_init() encounters unrecognized parameters, it allocates an\nerr_chunk to report them. However, this chunk is leaked in several code\npaths:\n\n1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after\n sctp_verify_init() has populated err_chunk, the function returns\n immediately without freeing it.\n\n2. In sctp_sf_do_unexpected_init(), the same leak occurs on the\n security_sctp_assoc_request() failure path.\n\n3. In sctp_sf_do_unexpected_init(), on the success path after copying\n unrecognized parameters to the INIT-ACK, the function returns without\n freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees\n it.\n\nFix all three leaks by adding sctp_chunk_free(err_chunk) calls before\nreturning in the error paths and on the success path in\nsctp_sf_do_unexpected_init().(CVE-2026-72413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: avoid R5_Overlap races while breaking stripe batches\n\nKCSAN report a race in break_stripe_batch_list() vs. raid5_make_request()\non sh-\u0026gt;dev[i].flags (plain word write vs. atomic bit op)..\n\nand .. one possible scenario is:\n\nCPU1 CPU2\nbreak_stripe_batch_list(sh1)\n-\u0026gt; handle sh2\n-\u0026gt; lock(sh2)\n-\u0026gt; sh2-\u0026gt;batch_head = NULL\n-\u0026gt; unlock(sh2)\n-\u0026gt; test_and_clear_bit(R5_Overlap, sh2-\u0026gt;dev[i].flags)\n-\u0026gt; wake_up_bit(sh2-\u0026gt;dev[i].flags)\n raid5_make_request()\n -\u0026gt; add_all_stripe_bios(sh2)\n -\u0026gt; lock(sh2)\n -\u0026gt; stripe_bio_overlaps(sh2) returns true\n\t\t\t\t batch_head is NULL, so new bio overlap\n\t\t\t\t exist bio on sh2 -\u0026gt; true\n -\u0026gt; set_bit(R5_Overlap, sh2-\u0026gt;dev[i].flags)\n -\u0026gt; unlock(sh2)\n -\u0026gt; wait_on_bit(sh2-\u0026gt;dev[i].flags)\n-\u0026gt; sh2-\u0026gt;dev[i].flags = sh1-\u0026gt;dev[i].flags \u0026amp; ~R5_Overlap\n\nNo wait_up_bit(), CPU2 could be wait_on_bit() forever...\n\nFix by :\n- Expand the protect zone.\n- Use batch_head\u0026apos;s device flag\u0026apos;s snaphot when no held head_sh-\u0026gt;stripe_lock.\n- Move sh/head_sh-\u0026gt;batch_head = NULL to the end of protected zone , and ,\n any concurrent add_all_stripe_bios() grabs sh-\u0026gt;stripe_lock now either:\n\t- see batch_head != null, and , is rejected by stripe_bio_overlaps()\n\t under the lock (no R5_Overlap wait ) , or ,\n\t- sees batch_head == NULL, only after dev[i].flags has already been\n\t set and the prior R5_Overlap waiters worken.\n\nKCSAN report:\n================================================\n BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request\n\n write (marked) to 0xffff8e89c8117548 of 8 bytes by task 4042 on cpu 0:\n raid5_make_request+0xea0/0x2930\n md_handle_request+0x4a2/0xa40\n md_submit_bio+0x109/0x1a0\n __submit_bio+0x2ec/0x390\n submit_bio_noacct_nocheck+0x457/0x710\n submit_bio_noacct+0x2a7/0xc20\n submit_bio+0x56/0x250\n blkdev_direct_IO+0x54c/0xda0\n blkdev_write_iter+0x38f/0x570\n aio_write+0x22b/0x490\n io_submit_one+0xa51/0xf70\n __x64_sys_io_submit+0xf7/0x220\n x64_sys_call+0x1907/0x1c60\n do_syscall_64+0x130/0x570\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n read to 0xffff8e89c8117548 of 8 bytes by task 4010 on cpu 5:\n break_stripe_batch_list+0x249/0x480\n handle_stripe_clean_event+0x720/0x9b0\n handle_stripe+0x32fb/0x4500\n handle_active_stripes.isra.0+0x6e0/0xa50\n raid5d+0x7e0/0xba0\n md_thread+0x15a/0x2d0\n kthread+0x1e3/0x220\n ret_from_fork+0x37a/0x410\n ret_from_fork_asm+0x1a/0x30\n\n value changed: 0x0000000000000019 -\u0026gt; 0x0000000000000099 --\u0026gt; R5_Overlap(CVE-2026-72420)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Proper rollback if the ioremap fails\n\nbnxt_qplib_alloc_dpi returns success even if ioremap fails.\nAdd the proper rollback when the ioremap fails and return\n-ENOMEM status.(CVE-2026-72496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: clear sock_ops cb flags before force-closing a child socket\n\nA child socket inherits the listener\u0026apos;s bpf_sock_ops_cb_flags via\nsk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() /\ntcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where\ninet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs\nwithout it.\n\nIf BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -\u0026gt; tcp_set_state()\ncalls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me():\n\n WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550\n RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n tcp_done+0xba/0x250 net/ipv4/tcp.c:5095\n tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787\n tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926\n tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164\n \u0026lt;/IRQ\u0026gt;\n\nThe child is freed before it is ever established, so it should run no\nsock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(),\nthe common point for the IPv4, IPv6 and chtls forced-close paths and for the\nMPTCP -\u0026gt;syn_recv_sock() failure path (dispose_child), which reaches tcp_done()\non a child that was never established too.(CVE-2026-74268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: fib: Don\u0026apos;t dump dying fib_info in fib_leaf_notify().\n\nsyzbot reported use-after-free in nsim_fib4_prepare_event(). [0]\n\nThe problem is that the following functions call fib_info_hold() /\nrefcount_inc() while dumping fib_info under RCU, which is unsafe.\n\n * mlxsw_sp_router_fib4_event()\n * rocker_router_fib_event()\n * nsim_fib4_prepare_event()\n\nrefcount_inc_not_zero() must be used, but it would be too late\nthere.\n\nLet\u0026apos;s guarantee the lifetime of fib_info in fib_leaf_notify().\n\nNote that IPv6 does not need the corresponding change since\nfib6_table_dump() holds fib6_table.tb6_lock.\n\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420\nModules linked in:\nCPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026\nWorkqueue: netns cleanup_net\nRIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25\nCode: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a \u0026lt;67\u0026gt; 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f\nRSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293\nRAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0\nRBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005\nR10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000\nR13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000\nFS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __refcount_add include/linux/refcount.h:-1 [inline]\n __refcount_inc include/linux/refcount.h:366 [inline]\n refcount_inc include/linux/refcount.h:383 [inline]\n fib_info_hold include/net/ip_fib.h:629 [inline]\n nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline]\n nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline]\n nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043\n call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25\n call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline]\n fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline]\n fib_table_notify net/ipv4/fib_trie.c:2194 [inline]\n fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217\n fib_net_dump net/core/fib_notifier.c:70 [inline]\n register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108\n nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596\n nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline]\n nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058\n devlink_reload+0x501/0x8d0 net/devlink/dev.c:475\n devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558\n ops_pre_exit_list net/core/net_namespace.c:161 [inline]\n ops_undo_list+0x187/0x940 net/core/net_namespace.c:234\n cleanup_net+0x56e/0x800 net/core/net_namespace.c:702\n process_one_work kernel/workqueue.c:3314 [inline]\n process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397\n worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478\n kthread+0x388/0x470 kernel/kthread.c:436\n ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;(CVE-2026-74289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost: fix vhost_get_avail_idx for a non empty ring\n\nvhost_get_avail_idx is supposed to report whether it has updated\nvq-\u0026gt;avail_idx. Instead, it returns whether all entries have been\nconsumed, which is usually the same. But not always - in\ndrivers/vhost/net.c and when mergeable buffers have been enabled, the\ndriver checks whether the combined entries are big enough to store an\nincoming packet. If not, the driver re-enables notifications with\navailable entries still in the ring. The incorrect return value from\nvhost_get_avail_idx propagates through vhost_enable_notify and causes\nthe host to livelock if the guest is not making progress, as vhost will\nimmediately disable notifications and retry using the available entries.\n\nThis goes back to commit d3bb267bbdcb (\u0026quot;vhost: cache avail index in\nvhost_enable_notify()\u0026quot;) which changed vhost_enable_notify() to compare\nthe freshly read avail index against vq-\u0026gt;last_avail_idx instead of the\npreviously cached vq-\u0026gt;avail_idx. Commit 7ad472397667 (\u0026quot;vhost: move\nsmp_rmb() into vhost_get_avail_idx()\u0026quot;) then carried over the same\ncomparison when refactoring vhost_enable_notify() to call the unified\nvhost_get_avail_idx().\n\nThe obvious fix is to make vhost_get_avail_idx do what the comment\nsays it does and report whether new entries have been added.(CVE-2026-74356)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: fix deadlock in read error recovery path\n\nraid1d and raid10d may resubmit a split md cloned bio while handling\na read error. In this case, resubmitting the bio can lead to a deadlock\nif the array is suspended before md_handle_request() acquires an\nactive_io reference via percpu_ref_tryget_live().\n\nSince the cloned bio already holds an active_io reference,\ntrying to acquire another reference via percpu_ref_tryget_live()\ncan lead to a deadlock while the array is suspended.\n\nFix this by using percpu_ref_get() for md cloned bios.(CVE-2026-74375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: Fix advertising data UAFs\n\nhci_find_adv_instance() returns an adv_info pointer that is valid only\nwhile hdev-\u0026gt;lock is held. The advertising command-sync paths perform\ninstance lookups without that lock and, in some cases, retain the pointer\nwhile waiting for a controller response.\n\nAn advertising termination event can therefore interleave as follows:\n\n hci_cmd_sync_work hci_rx_work\n hci_find_adv_instance()\n __hci_cmd_sync_status()\n wait for controller reply hci_dev_lock()\n hci_remove_adv_instance()\n kfree(adv)\n adv-\u0026gt;scan_rsp_changed = false\n\nKASAN reported:\n\n BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300\n Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88\n Workqueue: hci0 hci_cmd_sync_work\n Call Trace:\n hci_set_ext_scan_rsp_data_sync+0x2e1/0x300\n hci_schedule_adv_instance_sync+0x390/0x4c0\n hci_cmd_sync_work+0x173/0x300\n Allocated by task 87:\n hci_add_adv_instance+0x538/0xac0\n add_advertising+0x885/0x1160\n Freed by task 89:\n kfree+0x131/0x3c0\n hci_remove_adv_instance+0x1d8/0x3b0\n hci_le_ext_adv_term_evt+0x17b/0x730\n\nProtect the instance lookup and payload construction in the extended\nadvertising, scan response, and periodic advertising data paths. Snapshot\nthe advertising parameters under hdev-\u0026gt;lock, but release the lock before\nwaiting for the controller.\n\nClear advertising-data dirty bits before issuing their commands and\nrestore them after a failure using a fresh lookup. Likewise, update the\nreported transmit power through a fresh lookup after the parameter command\ncompletes. No adv_info pointer then survives an HCI command wait.(CVE-2026-74509)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/iommufd: Fix IOPF group ownership UAF\n\niopf_group_alloc() links each last-page IOPF group into the generic IOPF\npending list before invoking the domain fault handler.\niommufd_fault_iopf_handler() also queued an accepted group in the\nIOMMUFD deliver list without removing it from the generic pending list.\n\nWhen detach or HWPT replacement drops the device\u0026apos;s IOPF reference count\nto zero, an IOMMU driver may call iopf_queue_remove_device(). That\nfunction responds to and frees groups through the generic pending list\nwithout removing the same groups from IOMMUFD\u0026apos;s deliver list or response\nxarray. A later read, response, or cleanup can then access the freed\ngroup and cause a UAF.\n\nFix this by dequeuing an accepted group from the generic pending list\nbefore IOMMUFD queues it for userspace response.\nMake iopf_group_response() send a response regardless of pending-list\nmembership, so the dequeued group can still be completed by IOMMUFD.(CVE-2026-74520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()\n\nsyzbot reported a memory leak [1] in the UDP tunnel NIC offload code.\n\nWhen device registration fails (e.g. in register_netdevice()), netdev core\nunwinds by sending a single NETDEV_UNREGISTER notification. If work was queued\nduring NETDEV_REGISTER (utn-\u0026gt;work_pending is set), udp_tunnel_nic_unregister()\nreturns early:\n\n\tif (utn-\u0026gt;work_pending)\n\t\treturn;\n\nBecause failed registrations do not enter netdev_wait_allrefs_any(), no\nsubsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the\nstruct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked\npermanently.\n\nFix this by removing the early return. Instead, synchronously cancel any\npending work with cancel_delayed_work_sync() before freeing @utn.\n\nTo be able to call cancel_delayed_work_sync() while holding RTNL (the work also\nneeds RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL\nis contended, requeue the work with a 1 jiffy delay (via queue_delayed_work())\nto prevent high CPU contention while waiting for RTNL lock.\n\nThe utn-\u0026gt;work_pending bookkeeping is no longer needed and is removed, as\nthe workqueue core already tracks the pending/running state of the work.\n\n[1]\nBUG: memory leak\nunreferenced object 0xffff888127d5f840 (size 96):\n comm \u0026quot;syz-executor\u0026quot;, pid 5806, jiffies 4294942188\n backtrace (crc 99fdb6c8):\n __kmalloc_noprof+0x3bf/0x550\n udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline]\n udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline]\n udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931\n notifier_call_chain+0x59/0x160 kernel/notifier.c:85\n call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250\n register_netdevice+0xc10/0xeb0 net/core/dev.c:11478(CVE-2026-74543)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: validate offshift to prevent shift-out-of-bounds\n\nu32_change() copies the user-provided tc_u32_sel.offshift (unsigned char,\n0-255) into the kernel knode object without bounds validation. When a\npacket later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates\n`ntohs(offmask \u0026amp; *data) \u0026gt;\u0026gt; offshift` where the left operand is a 16-bit\nvalue promoted to a 32-bit int. Any offshift \u0026gt;= 32 is undefined behavior\nper C11 6.5.7p3, triggerable by an unprivileged user via user/network\nnamespaces.\n\nUBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43\nshift exponent 32 is too large for 32-bit type int\n\nFix this by rejecting offshift \u0026gt;= 16 during filter creation in\nu32_change().(CVE-2026-74544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: make nft_object rhltable per table\n\nThe nft_object rhltable is global, this allows for accessing objects\nthat are being dismangled from lookup path by other existing netns.\nGiven the nft_obj_destroy() releases the object inmediately, this might\nlead to use-after-free of these objects that are being released.\nMake the existing rhltable per table to address this issue to deal with\nwith the nft_rcv_nl_event() path too.\n\nUpdate nft_obj_lookup() to take the table as non-const, otherwise,\ncompiler complains when passing the objname_ht to rhltable_lookup().(CVE-2026-74565)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventfs: Use children field for rcu head and add memory barriers\n\nWhen an eventfs inode is freed, it sets ei-\u0026gt;is_freed and then uses its\nei-\u0026gt;list to add it to the srcu link list as the list field is a union with\nthe rcu list head. As the ei-\u0026gt;list is used to iterate over an SRCU\nprotected list without taking the eventfs_mutex, there\u0026apos;s nothing stopping\nthe iteration over that list to see the ei-\u0026gt;rcu instead of the ei-\u0026gt;list\nand it will read a corrupt target.\n\nTo fix this, change the union of the rcu list head with the children list.\nOn freeing the eventfs inode, set the is_free and execute a smp_wmb()\nbefore adding the eventfs inode to the SRCU list.\n\nOn iteration of the ei-\u0026gt;children list, at the start, execute a smp_rmb()\nand then read the is_freed of the ei to see if the children list is still\nvalid. If is_freed is set, then the ei_child read is not valid and the\nloop should exit immediately.(CVE-2026-74605)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npacket: use consistent hard_header_len in TX_RING send path\n\ntpacket_snd() reads dev-\u0026gt;hard_header_len independently for skb\nallocation and header construction in tpacket_fill_skb(). Concurrent\nnetdevice reconfiguration can therefore make the reserved headroom\nsmaller than the amount later pushed, or make copylen - hard_header_len\nnegative.\n\nSnapshot hard_header_len once before processing ring frames and use it\nfor the frame limit, headroom allocation, copy length, and skb\nconstruction. Pass the snapshot to tpacket_fill_skb().\n\nThe separate SOCK_DGRAM consistency problem between hard_header_len and\nheader_ops-\u0026gt;create is not addressed here.(CVE-2026-74668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix netns reference imbalance in conntrack kfuncs\n\nThe opts argument of the BPF conntrack kfuncs can point to a shared\nmap value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read\nopts-\u0026gt;netns_id separately when acquiring and releasing the network\nnamespace reference.\n\nThe reference imbalance can occur as follows:\n\n CPU 0 CPU 1\n read opts-\u0026gt;netns_id (-1)\n skip get_net_ns_by_id()\n write opts-\u0026gt;netns_id (id)\n read opts-\u0026gt;netns_id (id)\n put_net(net) /* no matching get */\n\nThe reverse transition leaks the reference. Repeating the unmatched put\ncan destroy a live namespace and crash later users.\n\nThe kernel reported:\n\n Oops: general protection fault, probably for non-canonical address\n KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]\n RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700\n Call Trace:\n __sys_bpf+0x1662/0x50c0\n __x64_sys_bpf+0x73/0xb0\n do_syscall_64+0xf9/0x540\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n Kernel panic - not syncing: Fatal exception\n\nSnapshot every input field of opts with READ_ONCE() before validating or\nusing it. The netns_id snapshot keeps the namespace get/put pair\nbalanced, while the other snapshots keep the remaining options from\nchanging partway through an invocation. The individual reads can still\nobserve an inconsistent combination during a concurrent update, but each\nselected field value remains stable for that invocation.(CVE-2026-74715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: avoid out-of-bounds write in ip_vs_nat_icmp\n\nSashiko warns that local attacker can modify the packet\nwhile it is processed by IPVS. Some places read the\nIP ihl field multiple times which can cause out-of-bounds\naccess. One such place is ip_vs_nat_icmp where we\ncan write after the validated area.\n\nFix it by providing ciph argument just like it is done for\nIPv6 and use ciph-\u0026gt;len as offset to the embedded transport\nheader.\n\nModify some IPv4 header checks by reading the ihl field\nonly once.(CVE-2026-74724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Pin the \u0026apos;struct nfs_server\u0026apos; during a FREE_STATEID call\n\nDan Aloni reports that he was able to hit a use-after-free bug if a\nFREE_STATEID operation gets delayed for whatever reason. Fix this by\nbumping the refcount of the \u0026apos;struct nfs_server\u0026apos; object for the duration\nof the FREE_STATEID so it doesn\u0026apos;t get cleaned up from underneath us\nwhile operations are still in flight.(CVE-2026-74730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: ohci: fix NULL pointer dereference in ar_context_release\n\nDuring the error handling path of the driver\u0026apos;s probe function, a NULL\npointer dereference can occur in ar_context_release().\n\nWhen pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping\nfails), the devres cleanup mechanism invokes release_ohci(). This function\nunconditionally calls ar_context_release() to clean up the asynchronous\nreceive contexts. However, if ar_context_init() was not yet called,\nctx-\u0026gt;ohci remains NULL (as the fw_ohci structure is zero-initialized by\ndevres_alloc()).\n\nar_context_release() immediately dereferences ctx-\u0026gt;ohci to get the dev\npointer before checking if the context was actually initialized, leading to\na crash:\n\nOops: general protection fault, probably for non-canonical address\n0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nRIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543\nCall Trace:\n release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567\n release_nodes drivers/base/devres.c:546 [inline]\n devres_release_all+0x1a8/0x260 drivers/base/devres.c:576\n device_unbind_cleanup drivers/base/dd.c:597 [inline]\n really_probe+0x451/0xae0 drivers/base/dd.c:772\n\nTo fix this, move the assignment of the dev pointer after the !ctx-\u0026gt;buffer\ncheck. If ctx-\u0026gt;buffer is NULL, it indicates that the context was never\nsuccessfully initialized and there is nothing to release, safely avoiding\nthe dereference of the uninitialized ctx-\u0026gt;ohci pointer.(CVE-2026-74734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: revalidate ihl to prevent out-of-bounds access\n\nWhile the outer IP header is already pulled into the skb head,\nwe must be careful and revalidate the embedded headers after\nreading them from the skb frags to prevent out-of-bounds\naccess.\n\nOne such place reported by Sashiko is ip_vs_nat_icmp() where\nlocal process can change the ihl field and after\nskb_ensure_writable() we can see larger value which is a\nproblem for the ip_send_check(cih) calls.\n\nAdd check to drop the packet if the ihl field is changed.(CVE-2026-74747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: bounds-check buffer log item\u0026apos;s dirty bitmap\n\nxlog_recover_do_reg_buffer() replays each dirty region described by a\nbuffer log item\u0026apos;s bitmap into the buffer read for that item:\n\n\tmemcpy(xfs_buf_offset(bp, (uint)bit \u0026lt;\u0026lt; XFS_BLF_SHIFT),\n\t\titem-\u0026gt;ri_buf[i].iov_base,\n\t\tnbits \u0026lt;\u0026lt; XFS_BLF_SHIFT);\n\nThe destination offset (bit/nbits, from the logged dirty bitmap) and the\nbuffer size (from the logged blf_len) are both attacker-controlled and\notherwise unrelated, yet the only thing bounding the copy is an ASSERT(),\nwhich compiles away on production kernels. A crafted image logging a\nsmall blf_len together with a bitmap bit past the end of that buffer\ndrives the memcpy() past the buffer\u0026apos;s allocation, corrupting adjacent\nkernel heap during mount-time log recovery. This is reachable by anyone\nwho can get a crafted image mounted -- the malicious-filesystem threat\nmodel XFS already guards against elsewhere.\n\nTurn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery\nof the buffer with -EFSCORRUPTED, consistent with the validate-and-fail\nidiom already used in xlog_recover_do_inode_buffer() and\nxfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes\nSTATIC int and its three callers propagate the error.\n\nFound and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted\nimage trips a slab-out-of-bounds write before this change and fails\nrecovery cleanly with -EFSCORRUPTED after it.(CVE-2026-80536)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio_ccw: Move cp cleanup out of not operational\n\nThe fsm_notoper() routine is called when the device has been\nlost, and is (by definition) no longer operational. Since this\ncan happen asynchronously from the normal behavior of the\ndriver, the cleanup may happen when holding other locks\nin the calling sequence (notably, the cio subchannel lock).\n\nPush the cleanup of the private-\u0026gt;cp resources to a workqueue,\nwhere it can be done out from under that lock sequence and\na future patch can safely manage the locking requirements.(CVE-2026-80549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio_ccw: Ensure first IDAW remains constant\n\nThe first IDAW in a list does not need to be on a 2K/4K boundary\nlike all others, and so is read separately to accurately calculate\nthe size of the buffer needed to read the full IDAL.\n\nVerify that the address found in the first IDAW is unchanged between\nreads, to ensure a consistent set of IDAWs being worked with.(CVE-2026-80551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenrisc: signal: do not restore privileged SR bits on sigreturn\n\nrestore_sigcontext() copies the whole supervision register (SR) from the\nsignal frame and only clears SPR_SR_SM before the value is reloaded into\nthe hardware SR (through ESR and l.rfe) on the return to user space. All\nother SR bits are left under user control.\n\nAn unprivileged task can thus return from a signal handler through a\ncrafted sigframe that clears SPR_SR_DME. With the data MMU disabled the\nCPU performs no translation or protection on data accesses, so the task\ngains read and write access to arbitrary physical memory, a local\nprivilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH\nand the cache-enable bits are exposed the same way. The ptrace GPR regset\nalready refuses any change to SR for exactly this reason.\n\nRestore only the arithmetic flag bits (F, CY, OV) from the signal frame\nand take every privileged control bit from the SR the kernel saved on\nsignal entry.\n\nVerified with qemu-system-or1k -M or1k-sim: before this change an\nunprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to\nphysical address 0x03000000 (beyond the kernel\u0026apos;s mem=32M); afterwards the\nsame PoC receives SIGSEGV and physical memory is unchanged.(CVE-2026-80560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: processor_idle: Mark LPI enter functions as __cpuidle\n\nWhen function tracing or Kprobes is enabled, entering an ACPI Low\nPower Idle (LPI) state triggers the following RCU splat:\n\n RCU not on for: acpi_idle_lpi_enter+0x4/0xd8\n WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228\n\nThe acpi_idle_lpi_enter() function is invoked within the cpuidle\npath after RCU has already been disabled for the current local CPU.\nConsequently, ftrace\u0026apos;s function_trace_call() expects RCU to be\nactively watching before recording trace data, emitting a warning\nif it is not.\n\nFix this by annotating acpi_idle_lpi_enter(), the generic __weak\nstub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter()\nwith __cpuidle. This moves these functions into the \u0026apos;.cpuidle.text\u0026apos;\nsection, implicitly disabling ftrace instrumentation (notrace) along\nthis sensitive path and preventing trace-induced RCU warnings during\nidle entry.(CVE-2026-80611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: fix unaligned memory access in timestamp adjustment\n\nUse get_unaligned_be32() and put_unaligned_be32() to safely read and\nwrite the timestamp fields. This prevents performance degradation due to\nunaligned memory access or even a crash on strict alignment\narchitectures.\n\nThis follows the implementation of timestamp parsing in the networking\nstack at tcp_parse_options() and synproxy_parse_options().(CVE-2026-80637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: ensure no dangling hcon references in iso_conn\n\nAfter iso_conn_del(), ISO sockets should not dereference the hcon any\nmore. Currently, clearing iso_conn::hcon relies on iso_conn_del()\nreleasing the last reference to the iso_conn.\n\nSimplify this by explicitly clearing conn-\u0026gt;hcon in iso_conn_del(), to\navoid more complex reasoning on races about who holds the last\nreference.(CVE-2026-80721)",
"id": "OESA-2026-3987",
"modified": "2026-09-20T13:23:52Z",
"published": "2026-09-20T13:23:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68118"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72420"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74375"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74543"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74605"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80536"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80721"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2026-64405",
"CVE-2026-68095",
"CVE-2026-68118",
"CVE-2026-68138",
"CVE-2026-68145",
"CVE-2026-72098",
"CVE-2026-72247",
"CVE-2026-72413",
"CVE-2026-72420",
"CVE-2026-72496",
"CVE-2026-74268",
"CVE-2026-74289",
"CVE-2026-74356",
"CVE-2026-74375",
"CVE-2026-74509",
"CVE-2026-74520",
"CVE-2026-74543",
"CVE-2026-74544",
"CVE-2026-74565",
"CVE-2026-74605",
"CVE-2026-74668",
"CVE-2026-74715",
"CVE-2026-74724",
"CVE-2026-74730",
"CVE-2026-74734",
"CVE-2026-74747",
"CVE-2026-80536",
"CVE-2026-80549",
"CVE-2026-80551",
"CVE-2026-80560",
"CVE-2026-80611",
"CVE-2026-80637",
"CVE-2026-80721"
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.