{"id":"OESA-2026-3987","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()\n\nhci_abort_conn() read hci_skb_event(hdev->sent_cmd) when a connection\nwas pending, but hdev->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->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 -> register sqe ->\n  fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref\n  yet\n- thread b: fuse_conn_destroy() -> fuse_chan_abort() ->\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  "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);"\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->connected under fch->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->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'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'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 'int refcnt' 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() -> tcf_action_init() -> tcf_action_init_1() ->\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) >> 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->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's a buffer overflow in dm-verity-fec:\n\nif (neras && *neras <= v->fec->roots)\n\tfio->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 — 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 "already exists" 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->zone.dir or\nzone->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->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->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet'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->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-> handle sh2\n-> lock(sh2)\n-> sh2->batch_head = NULL\n-> unlock(sh2)\n-> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags)\n-> wake_up_bit(sh2->dev[i].flags)\n                                raid5_make_request()\n                                -> add_all_stripe_bios(sh2)\n                                -> lock(sh2)\n                                -> 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 -> true\n                                -> set_bit(R5_Overlap, sh2->dev[i].flags)\n                                -> unlock(sh2)\n                                -> wait_on_bit(sh2->dev[i].flags)\n-> sh2->dev[i].flags = sh1->dev[i].flags & ~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's device flag's snaphot when no held head_sh->stripe_lock.\n- Move sh/head_sh->batch_head = NULL to the end of protected zone , and ,\n  any concurrent add_all_stripe_bios() grabs sh->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 -> 0x0000000000000099 --> 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'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() -> 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   <IRQ>\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   </IRQ>\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 ->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'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'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 <67> 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 <TASK>\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 </TASK>(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->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 ("vhost: cache avail index in\nvhost_enable_notify()") which changed vhost_enable_notify() to compare\nthe freshly read avail index against vq->last_avail_idx instead of the\npreviously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move\nsmp_rmb() into vhost_get_avail_idx()") 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->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->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->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'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'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->work_pending is set), udp_tunnel_nic_unregister()\nreturns early:\n\n\tif (utn->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->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 "syz-executor", 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 & *data) >> offshift` where the left operand is a 16-bit\nvalue promoted to a 32-bit int. Any offshift >= 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 >= 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->is_freed and then uses its\nei->list to add it to the srcu link list as the list field is a union with\nthe rcu list head. As the ei->list is used to iterate over an SRCU\nprotected list without taking the eventfs_mutex, there's nothing stopping\nthe iteration over that list to see the ei->rcu instead of the ei->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->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->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->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->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->netns_id (-1)\n  skip get_net_ns_by_id()\n                                         write opts->netns_id (id)\n  read opts->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->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 'struct nfs_server' 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 'struct nfs_server' object for the duration\nof the FREE_STATEID so it doesn'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'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->ohci remains NULL (as the fw_ohci structure is zero-initialized by\ndevres_alloc()).\n\nar_context_release() immediately dereferences ctx->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->buffer\ncheck. If ctx->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->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's dirty bitmap\n\nxlog_recover_do_reg_buffer() replays each dirty region described by a\nbuffer log item's bitmap into the buffer read for that item:\n\n\tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT),\n\t\titem->ri_buf[i].iov_base,\n\t\tnbits << 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'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->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'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'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 '.cpuidle.text'\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->hcon in iso_conn_del(), to\navoid more complex reasoning on races about who holds the last\nreference.(CVE-2026-80721)","modified":"2026-09-20T13:30:32.806002034Z","published":"2026-09-20T13:23:52Z","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"],"database_specific":{"severity":"Critical"},"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"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP3","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.3.31.162.oe2403sp3"}]}],"ecosystem_specific":{"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"],"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"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3987.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}