{"id":"OESA-2026-4810","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\nwifi: brcmsmac: Fix dma_free_coherent() size\n\ndma_alloc_consistent() may change the size to align it. The new size is\nsaved in alloced.\n\nChange the free size to match the allocation size.(CVE-2026-31661)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Validate GPIO pin LUT table size before iterating\n\n[Why&How]\nThe GPIO pin table parsers in get_gpio_i2c_info() and\nbios_parser_get_gpio_pin_info() derive an element count from the VBIOS\ntable_header.structuresize field, then iterate over gpio_pin[] entries.\nHowever, GET_IMAGE() only validates that the table header itself fits\nwithin the BIOS image. If the VBIOS reports a structuresize larger than\nthe actual mapped data, the loop reads past the end of the BIOS image,\ncausing an out-of-bounds read.\n\nFix this by calling bios_get_image() to validate that the full claimed\nstructuresize is accessible within the BIOS image before entering the\nloop in both functions.\n\n(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: vudc: fix NULL deref in vep_dequeue()\n\nvep_alloc_request() wasn't initializing vrequest->udc, so cancellations\non the FunctionFS AIO path were arriving in vep_dequeue without a valid\nUDC reference.\n\nSince vrequest->udc is never actually properly used anywhere, we opt to\nremove it, and update vep_dequeue to obtain a reference to the udc with\nep_to_vudc(), consistent with the other vep_ ops.\n\nAFAICT this bug has existed for ~10 years. Seems that nobody has really\nstressed the FunctionFS AIO path on usbip's vudc.\n\nI tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints\nvia AIO. Before the fix, running `usbip attach` from the host would\ncause the guest to oops with the following backtrace:\n\nCall trace:\n vep_dequeue+0x1c/0xe4 (P)\n usb_ep_dequeue+0x14/0x20\n ffs_aio_cancel+0x24/0x34\n __arm64_sys_io_cancel+0xb0/0x124\n do_el0_svc+0x68/0x100\n el0_svc+0x18/0x5c\n el0t_64_sync_handler+0x98/0xdc\n el0t_64_sync+0x154/0x158(CVE-2026-64331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: pin L2CAP connection during netdev registration\n\nbnep_add_connection() reads the L2CAP connection without holding the\nchannel lock, then passes its HCI device to register_netdev(). Controller\nteardown can clear and release that connection concurrently, leaving the\nnetwork device registration path to dereference a freed parent device.\n\nTake a reference to the L2CAP connection while holding the channel lock.\nRetain it until register_netdev() has taken the parent device reference.(CVE-2026-64408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: set new_stream to NULL after release\n\nIn dm_update_crtc_state(), the skip_modeset path releases new_stream\nvia dc_stream_release() but does not set the pointer to NULL.\n\nIf a later error (e.g., color management failure) triggers the fail\nlabel, the error path calls dc_stream_release() again on the same\ndangling pointer, causing a double release and potential use-after-free.\n\nFix this by setting new_stream to NULL after the initial release.\n\n(cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)(CVE-2026-68236)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix Route Information option length validation\n\nrt6_route_rcv() validates the Route Information option (RFC 4191) length\nagainst the prefix length, but both checks are off by one.\n\nrinfo->length is the ND option length in units of 8 octets and it\n*includes* the 8-byte option header, so an option carrying N bytes of\nprefix has length == 1 + N/8.  RFC 4191 section 2.3 requires length 3\nwhen Prefix Length is greater than 64, and 2 or 3 when it is greater\nthan 0.  The code accepts length >= 2 and length >= 1 respectively.\n\nipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix,\nso a Router Advertisement with (prefix_len=128, length=2) or\n(prefix_len=64, length=1) makes the kernel read up to 8 bytes past the\nend of the option.  Those bytes end up in the prefix of the route that\ngets installed, so they are visible to userspace:\n\n  # RA with a Route Information option (prefix_len=128, length=2)\n  # followed by a source link-layer address option, 01 01 de ad be ef ca fe\n  $ ip -6 route show\n  2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra\n                     ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds\n\nWhen the Route Information option is the last one in the packet, those\neight bytes come from the skb tail room instead.\n\nReject the option lengths RFC 4191 does not allow.(CVE-2026-74598)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: cap advertised IP tunnel headroom\n\nIP tunnel devices derive their advertised needed_headroom from lower\noutput devices. A stack of user-created devices can make the derived\nvalue larger than the 16-bit skb header offsets can represent. Once IP\noutput reserves it, skb head expansion can wrap those offsets.\n\nThe runtime transmit path already caps a growing needed_headroom at 512.\nApply the same cap when tunnel configuration publishes needed_headroom\nderived from a lower output device.\n\nCapping the advertised value is safe: IP tunnel transmit still expands\nthe skb when a packet needs more headroom. A nonsensical stacked\nconfiguration can therefore incur an extra reallocation, but it cannot\npublish an unbounded reservation to upper layers.(CVE-2026-80978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: kcm: Hold RCU read lock while running BPF parser\n\nkcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which\nprevents CPU migration, but does not establish an RCU read-side\ncritical section. Consequently, BPF map operations can trigger\nWARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser\nprogram.\n\nHold the RCU read lock while running the program.(CVE-2026-90143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers\n\nflexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume\nthe data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client\nhas no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so\nI/O to a v4.0 flexfiles DS oopses:\n\n  - nfs4_init_ds_session() dereferences clp->cl_session->session_state\n    while seeding the DS lease. It also only seeds cl_lease_time when\n    NFS4_SESSION_INITING is set; without a session that never happens, so\n    cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing\n    every 5 seconds. Seed the lease whenever there is no session and\n    return before touching session state.\n\n  - ff_layout_async_handle_error_v4() dereferences\n    clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the\n    v4.0 transport slot table (clp->cl_slot_tbl) when there is no session.(CVE-2026-90149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix use-after-free in siw_accept()\n\nsiw_accept() looks up the QP supplied by userspace. If that QP is\nalready in RTS, the function jumps to error cleanup before associating\nthe incoming CEP with it.\n\nThe cleanup tests whether qp->cep is non-NULL and assumes the current\ncall installed the association. However, qp->cep can point to the CEP\nof an existing connection. The cleanup then drops a reference from the\nincoming cep, not qp->cep. Once the incoming endpoint loses its\nremaining references, this can free it before the subsequent cep->qp\nstore, causing a use-after-free. It also clears the existing QP\nassociation.\n\nOnly release the association reference when qp->cep is the incoming\nCEP. This preserves an existing association and avoids accessing the\nfreed endpoint.(CVE-2026-90292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuio: Fix stale info pointer in failed registration path\n\nAfter device_add(), the UIO device is visible to userspace and /dev/uioX\ncan be opened. If a later setup step fails, __uio_register_device()\nunwinds the device but leaves idev->info pointing at the caller-owned\nstruct uio_info.\n\nThat is unsafe when an opener races with the failed registration path.\nThe open file keeps a reference to the uio_device, while the caller sees\nregistration failure and may free its struct uio_info. Later file\noperations can then follow idev->info and dereference freed memory.\n\nHandle post-device_add() failures like unregister: remove UIO attributes\nwhile the info pointer is still valid, then clear idev->info under\ninfo_lock and wake existing waiters/async users before removing the\ndevice and minor. This makes already-open file descriptors observe the\nsame "device gone" state as normal uio_unregister_device().(CVE-2026-93054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: pcie: null RX pointers after free\n\nWhen iwl_pcie_tx_init() fails after RX init, nic init unwinds via\niwl_pcie_rx_free().\n\nThe freed RX members stayed non-NULL on the live transport object,\nso later teardown or retry could touch stale RX state.\nSet rx_pool, global_table, rxq, and alloc_page to NULL after free\nto make repeated cleanup and retry paths safe.(CVE-2026-93796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: virt_wifi: don't transfer operstate before register\n\nvirt_wifi_newlink() calls netif_stacked_transfer_operstate() before\nregister_netdevice(). If the lower device is dormant, that queues the\nnew netdev on lweventlist while it is still uninitialized. If\nregistration fails after that, for example because of an invalid name\nsuch as "bad/name", free_netdev() immediately frees the object. A\nlater linkwatch_fire_event() then use-after-frees the list entry.\n\nMove the transfer to after netdev_upper_dev_link(), as macvlan and\nipvlan already do.(CVE-2026-98311)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: set timer->private_data before registering the PCM timer\n\nsnd_pcm_timer_init() calls snd_device_register() to link the new\nstruct snd_timer into the global timer list while it still carries\nhw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),\nand only afterwards sets timer->private_data = substream.\n\nOnce the timer is on the list under register_mutex, a concurrent\nreader can already reach it through the same mutex and invoke these\ncallbacks. /proc/asound/timers does this via c_resolution(), and\nsnd_timer_open()+snd_timer_start() reach start()/stop() the same way.\nAll three dereference timer->private_data, which for this brief\nwindow is NULL, giving a NULL-pointer dereference:\n\n  substream = timer->private_data;\n  return substream->runtime ? ...   // substream is NULL\n\nMove the private_data/private_free assignment before\nsnd_device_register() so the timer is never visible on the list\nwithout its private_data set. On the snd_device_register() failure\npath, private_free() (snd_pcm_timer_free()) can now run, but it only\ndoes substream->timer = NULL, which is already NULL at that point\nsince substream->timer is set to the new timer just once, after a\nsuccessful registration -- so the failure path stays safe.(CVE-2026-98314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: unlist vifs when their netdev is unregistered\n\nmac80211 only removes vifs from the local->interfaces list when\nan interface is removed via ieee80211_if_remove(), before it\nunregisters the netdev. However, it's possible for a netdev to\nbe unregistered without going through that: When the netns that\nholds the wiphy is destroyed, the wiphy is supposed to move to\nthe init_ns, but that can run into allocation failures.\n\nThen, mac80211 has an interface listed that doesn't exist, and\nwill eventually hit\n\n  BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()!\n  ...\n  _cfg80211_unregister_wdev+0x24/0x36a [cfg80211]\n  cfg80211_unregister_wdev+0x15/0x1d [cfg80211]\n  ieee80211_remove_interfaces+0x1ff/0x257 [mac80211]\n  ieee80211_unregister_hw+0x73/0x1d1 [mac80211]\n  mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim]\n\nRemove the interface from the list in ->ndo_uninit if it's still\naround to avoid this.(CVE-2026-98331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fix use-after-free in dma_chan_put() and dma_release_channel()\n\nWhen dma_device_put() drops the last reference on chan->device->ref,\ndma_device_release() runs and may free the dma_device along with its\nchannels.\n\ndma_chan_put() then still reads chan->device->owner via\ndma_chan_to_owner() for the trailing module_put(). KASAN catches it:\n\n\tslab-use-after-free in dma_chan_put+0x3e6/0x4c0\n\tRead of size 8 by task insmod/6319\n\tFreed by task 6319:\n\t  kfree+0x225/0x470\n\t  dma_chan_put+0x395/0x4c0\n\t  dmaengine_put+0xf8/0x160\n\nCache the module owner in dma_chan_put() before the put so the trailing\nmodule_put() does not need chan->device.(CVE-2026-98343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate\n\ndvfs_get_idx() may return an out-of-range index if the SCP firmware is\nbuggy or returns a stale value. Only negative indexes were rejected, so a\nlarge index walked past info->opps and could treat garbage as a clock rate\n(KASAN OOB / wrong frequency to consumers). The missing upper bound dates\nback to the original SCPI clock driver.\n\nTreat indexes >= opp count as invalid and return 0, same as idx < 0.(CVE-2026-98362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvlan: require the MAC header to be present in __vlan_insert_inner_tag()\n\n__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),\nnever that mac_len bytes of MAC header are present.  Its ETH_HLEN\nwrappers - __vlan_insert_tag() under skb_vlan_push(), and\nvlan_insert_tag() under validate_xmit_vlan() on the generic transmit\npath - therefore rewrite the first 16 bytes at skb->data: a 12-byte\nmemmove plus two 2-byte stores at +12 and +14.  No caller supplies the\nbound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().\n\nAn IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a\none-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a\nhwaccel tag; the next - clsact "action vlan push" or\nbpf_skb_vlan_push() - enters the helper with skb->len still 1.  The\nhead comes from skbuff_small_head without __GFP_ZERO, so each push\ndrags bytes from beyond skb->tail into the frame.  After three the\none-byte send leaves as 13 bytes carrying 11 bytes of uninitialised\nslab:\n\n  0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81\n           `------------------------------'\n  only 0x5a was sent; the rest is slab, here the top 56 bits of a\n  linear-map address\n\nRequire the MAC header the helper rewrites to be present, so such a\nframe is dropped rather than transmitted.(CVE-2026-98377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: fix heap OOB write on key removal\n\nWhen a key is removed (data == NULL), rsi_hal_load_key() runs:\n\n\tmemset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ);\n\nset_key is a struct rsi_set_key *, so the subscript is scaled by\nsizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is\nskb->data + 2560, and the memset writes 144 zero bytes starting\n2.4KB past the end of the 160-byte skb data buffer, corrupting\nunrelated heap objects. The intended byte offset would have been\n(u8 *)set_key + FRAME_DESC_SZ.\n\nThe write fires on every DISABLE_KEY callback, so plain disconnects,\nroams and interface teardowns trigger it on real networks.\n\nThe memset is redundant: the whole buffer is zeroed right after\nallocation, so the frame sent to the device is byte-identical\nwithout it. Drop the else branch; normal operation is unaffected.\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-98407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: fix NULL dereference in k3_udma_glue_release_rx_chn()\n\nIf devm_kcalloc() for rx_chn->flows fails in a channel request function,\nthe error path calls k3_udma_glue_release_rx_chn(), which dereferences\nthe NULL rx_chn->flows pointer in k3_udma_glue_release_rx_flow().\n\nSkip the flow release loop in k3_udma_glue_release_rx_chn() when\nrx_chn->flows is not allocated.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-98416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: xfrm: reject unrepresentable espintcp transport headers\n\nESP-in-TCP can hand xfrm packets whose transport header offset no longer\nfits after the stream parser trims the TCP envelope. The plain transport\nheader reset truncates that offset and triggers the skb warning path.\n\nUse the careful transport-header helper and drop the skb through the\nexisting XFRM error path when the offset cannot be represented.(CVE-2026-98417)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: reset the AP_VLAN tailroom counter on ifdown\n\nOn ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from\nthe AP interface, but it's never decremented again unless the AP is\nalso brought down. Thus, bringing the same AP_VLAN up again will\nincrement the counter again and eventually hit the sanity check:\n\n  WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt !=\n               master->crypto_tx_tailroom_needed_cnt);\n\nReset it on ifdown to avoid that.(CVE-2026-98422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: free inet_opt and ireq_opt after an RCU grace period\n\ntcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the\nchild socket (newinet->inet_opt) without copying it.\n\nAnother cpu can concurrently process a retransmitted SYN for the same\nrequest socket, and send a SYNACK from tcp_check_req().\ntcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt\nunder rcu_read_lock() only, and ip_build_and_send_pkt() and\nip_options_build() then read opt->optlen twice.\n\nNote that the SYNACK timer itself is not an issue: it holds a\nreference on its request socket, and inet_csk_reqsk_queue_drop()\ncalls timer_delete_sync() before the child can be freed.\n\nSince commit 079096f103fa ("tcp/dccp: install syn_recv requests\ninto ehash table"), request sockets are processed without holding\nthe listener lock, so nothing prevents the child socket from being\nfreed while the SYNACK is still being built. TCP child sockets do\nnot have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt\nwith a plain kfree(), leading to a use-after-free in\nip_options_build().\n\nA similar issue exists with request socket migration\n(net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE\nprogram). reqsk_timer_handler() clones the request socket with\ninet_reqsk_clone(), so that the old request socket and its clone\nshare the same ireq_opt, then reqsk_migrate_reset() clears the\npointer in the old one. Another cpu holding a reference on the old\nrequest socket can still be using these options (sending a SYNACK,\nor creating a child in tcp_v4_syn_recv_sock()) when the clone is\nfreed, and tcp_v4_reqsk_destructor() also uses a plain kfree().\n\nReaders already use RCU, and other paths replacing inet_opt\n(do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use\nkfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and\ntcp_v4_reqsk_destructor() as well.\n\nIPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()\nduplicates the options. tcp_v6_reqsk_destructor() has the same\nmigration issue with ipv6_opt, which is only set by CALIPSO. This\nwill be addressed in a separate patch.(CVE-2026-98432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: conntrack: fix helper UAF due to extensions realloc\n\nWhile calling the helpers, a raw pointer to the extensions area is\nwired into expectations list:\n\n  -> nf_ct_helper()\n   -> helper->help()\n    -> nf_ct_expect_related_report()\n     -> nf_ct_expect_insert()\n      -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations)\n\nIn case the connection is not confirmed yet, more extensions can be\nadded afterwards with *_ext_add() calls reallocating the extension\nspace and leaving the now invalid pointer in the expectations list\nthat is later accessed while removing the expectation.\n\nMake sure that helpers are called at the end after all the other\nextensions are already added.\n\nNote that the helper rejection now leaves the mark and labels set,\nbut that's not different from how the NAT was handled before or how\nthe mark and the labels were handled on confirmation failure.  And\nthere are no atomicity guarantees provided by the API anyway.(CVE-2026-98490)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: publish HW_DEAD after worker is done\n\nflow_offload_work_del() sets NF_FLOW_HW_DEAD before the work handler\nclears NF_FLOW_HW_PENDING. Once a flow is both HW_DYING and HW_DEAD, a\nconcurrent garbage collection pass can remove it and schedule it for RCU\nfreeing.\n\nThe offload worker holds neither an RCU read lock nor a reference to the\nflow. If it is preempted after publishing HW_DEAD, the RCU callback can\nfree the flow before the worker resumes and clears HW_PENDING, resulting\nin a use-after-free.\n\nMove HW_DEAD publication to the common worker epilogue after the pending\nbit is cleared, making it the final flow access by destroy work. Order all\npreceding flow accesses before publishing the bit that allows garbage\ncollection to free the object.(CVE-2026-98625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: mark the rcu locked areas properly\n\nWhen we bump the uref counter, there's no need to keep\nthe rcu lock because the referred hash table can't\ndisappear. Also, from the same reason in mtype_gc we\nneed the rcu lock and not a spinlock.(CVE-2026-98899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: reset ar->num_stations on hardware start\n\nWhen (multiple) hw restart occurs, we end up in a situation where we\ncannot accept new stations / mesh peers. This seems to be the\n'num_stations' in 'struct ath11k' that did not get reset properly in\nthis case. In ath11k_mac_op_start(), it was indeed the only accounting var\nthat did not get reset so let's clear it too.\n\nThis avoids problems like those:\n\n\t[1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211_reconfig_stations+0x98/0xc0\n\t[1248828.088115] Call trace:\n\t[1248828.088116]  ieee80211_reconfig_stations+0x98/0xc0 (P)\n\t[1248828.088119]  ieee80211_reconfig+0x774/0x1438\n\t[1248828.088123]  ieee80211_restart_work+0x10c/0x178\n\t[1248828.088127]  process_one_work+0x178/0x3c0\n\t[1248828.088130]  worker_thread+0x280/0x440\n\t[1248828.088133]  kthread+0xe0/0xf8\n\t[1248828.088137]  ret_from_fork+0x10/0x20\n\t[1248828.088141] ---[ end trace 0000000000000000 ]---\n\t[1248836.686604] ath11k_pci 0000:04:00.0: refusing to associate station: too many connected already (128)\n\t[1248836.686609] ath11k_pci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1\n\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1(CVE-2026-98936)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwireguard: noise: reject response consumption after intermediate initiation\n\nTwo threads begin processing the identical response message, received\ntwice. The first thread, A, runs. While it's running, the second one,\nB, gets partway through, and during that slow calculation, or even while\nblocking on down_write(), A completes and then also a handshake\ninitiation that's already been queued up runs in thread C, which itself\ntakes that same down_write(). The handshake initiation creation\nsucceeds, and sets the state back to waiting-for-response, and calls\nup_write(), at which point thread B resumes, because either its finished\nits calculations or was finally allowed to acquire down_write(). Thread\nB then copies the state back to the peer, and begins a new session,\nusing that state, which is the same session as the one made in thread A.\n\nThread A\t\t\tThread B\t\t\tThread C\n\ndown_read()\n sA = handshake->state\n memcpy(cA, handshake->crypto)\nup_read()\nif (sA != 1)\n goto fail\nslow_crypto(cA)\n\t\t\t\tdown_read()\n\t\t\t\t sB = handshake->state\n\t\t\t\t memcpy(cB, handshake->crypto)\n\t\t\t\tup_read()\n\t\t\t\tif (sB != 1)\n\t\t\t\t goto fail\n\t\t\t\tslow_crypto(cB)\ndown_write()\n if (sA != handshake->state)\n  goto fail\n memcpy(handshake->crypto, cA)\n handshake->state = 2\nup_write()\ndown_write()\n if (handshake->state != 2)\n  goto fail\n derive_session(handshake->crypto)\nup_write()\n\t\t\t\t\t\t\t\tdown_write()\n\t\t\t\t\t\t\t\t slow_crypto(handshake->crypto)\n\t\t\t\t\t\t\t\t handshake->state = 1\n\t\t\t\t\t\t\t\tup_write()\n\t\t\t\tdown_write()\n\t\t\t\t if (sB != handshake->state)\n\t\t\t\t   goto fail\n\t\t\t\t memcpy(handshake->crypto, cB)\n\t\t\t\t handshake->state = 2\n\t\t\t\tup_write()\n\t\t\t\tdown_write()\n\t\t\t\t if (handshake->state != 2)\n\t\t\t\t  goto fail\n\t\t\t\t derive_session(handshake->crypto)\n\t\t\t\tup_write()\n\nThis seems basically impossible to hit in a meaningful way in practice,\nbut ensure that it absolutely cannot happen by comparing the ephemeral\nprivate key that's on the stack with the latest one that the peer's\nhandshake state has.(CVE-2026-99059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: udp: Create exceptions before socket matching\n\nCurrently, when ICMP Fragmentation Needed and Redirect Message packets\nare locally delivered and quote a UDP packet, a FIB nexthop exception\n(FNHE) is only created if the kernel can match the UDP packet to an\nexisting socket.\n\nThis behavior allows off-path attackers to conduct a side-channel attack\non the FNHE cache in order to discover the ephemeral port used by a\nconnected UDP socket.\n\nCommit 6457378fe796 ("ipv4: use siphash instead of Jenkins in\nfnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache\nless predictible") tried to mitigate such attacks by making it harder\nfor attackers to discover hash collisions in the FNHE cache and by\nrandomizing the number of exceptions a hash bucket can hold,\nrespectively. Unfortunately, both of the mitigations can be bypassed.\n\nInstead, mitigate such attacks by always creating a FNHE, even before\ntrying to find a matching socket. Do that by calling ipv4_update_pmtu()\nand ipv4_redirect(), the helpers used when the quoted packet did not\noriginate from a socket.\n\nThis means that guesses (right or wrong) from an off-path attacker will\nalways result in a FNHE being created or updated in the cache that the\nattacker can observe.\n\nPass an oif of 0, in a similar fashion to icmp_err(). This is also the\noif used by the socket path for sockets that are not bound to a device.\n\nNote that this does not allow attackers to create FNHEs that they could\nnot create before, as both helpers can already be reached with little to\nno validation. For example, by sending an ICMP error that quotes an ICMP\nEcho Reply or one that quotes a UDP source port that matches a wildcard\nsocket.\n\nAlso note that in the good case (matched socket) the above scheme comes\nat the cost of an extra route lookup, as the no socket helpers perform\ntheir own lookup before the one performed by ipv4_sk_update_pmtu() /\nipv4_sk_redirect(). When the two resolve to different nexthops, it also\nresults in two exceptions being created for the same destination IP. One\nin the FNHE cache of the nexthop resolved by the no socket helpers and\nanother in the FNHE cache of the nexthop used by the socket.(CVE-2026-99077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: mcast: don't truncate the port group walk on teardown\n\n__br_multicast_disable_port_ctx() and br_multicast_del_port() walk\nport->mglist with hlist_for_each_entry_safe(). However,\nbr_multicast_find_del_pg() can also delete other entries from the same\nlist through br_multicast_fwd_src_remove() or __fwd_del_star_excl().\n\nIf such an entry is the iterator's saved next node, hlist_del_init()\nclears its ->next and terminates the walk early. The reproducer triggers\nthis in both teardown walks, leaving port groups in the bridge mdb with\na dangling ->key.port after del_nbp() frees the port:\n\n  BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320\n   __mdb_fill_info+0x1191/0x1320\n   br_mdb_dump+0x594/0xe40\n   rtnl_mdb_dump+0x1cf/0x5d0\n\nUse hlist_del_init_rcu() to unlink the group while preserving ->next.\nbr_multicast_del_pg() and the teardown walks run under\nbr->multicast_lock. The GC worker must acquire the same lock before\ndetaching the group for destruction, so the node remains alive while\nthe walk uses the preserved pointer.\n\nPreserving ->next means a walk can now reach a group that an earlier\niteration already deleted as a side effect. That group is off mp->ports,\nso br_multicast_find_del_pg() would fall through its port scan and hit\nthe trailing WARN_ON(1). Skip such groups at the top of that helper: a\nport group is put on port->mglist when it is created and only unlinked\nwhen it is deleted, so hlist_unhashed() identifies exactly this case.(CVE-2026-99117)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Check operator stack capacity before pushing\n\npredicate_parse() uses the first operator stack entry before processing\nany opening parentheses. A push then increments top before writing.\nThe existing check still permits that write when top already points to\nthe last allocated entry, which can access beyond the operator stack.\n\nReject the push when top reaches the last allocated entry.(CVE-2026-99142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in __tcf_action_put()\n\n__tcf_action_put() decrements the reference count before decrementing the\nbinding count. Another thread can free the action between these operations,\ncausing the binding-count update to access freed memory. KASAN reports it\nas:\n\n  BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340\n  Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64\n\nHold the action IDR mutex across both counter updates and IDR removal,\nkeeping cleanup outside the lock.(CVE-2026-99167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Verify event_call identity when updating synth_event refcount\n\nIn event_hist_trigger_parse() and hist_unreg_all(), the histogram\nregistration and unregistration paths look up find_synth_event() using\ntrace_event_name(file->event_call) and adjust se->ref if a match is\nfound.\n\nBecause find_synth_event() only compares the event basename, registering\nor removing a histogram on a non-synthetic trace event whose basename\nmatches a synthetic event erroneously modifies the synthetic event's\nreference count.  If a histogram is registered on the non-synthetic\nevent before the synthetic event is created and removed afterwards,\nse->ref is decremented without a matching increment, allowing the\nsynthetic event to be freed while an active histogram action still holds\na pointer to it.\n\nIntroduce find_synth_event_call() to verify that &se->call matches\nfile->event_call before adjusting se->ref.(CVE-2026-99233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Save the event file instead of the compatible histogram\n\ncreate_field_var_hist() creates a histogram on the matched event to\nsupply a field variable, and records it on the target so it can be torn\ndown later:\n\n\thist_data = find_compatible_hist(target_hist_data, file);\n\t...\n\t/* Save the compatible histogram information */\n\tvar_hist->hist_data = hist_data;\n\nhist_data is not the histogram it creates. It is one that was already\nthere, whose keys the new one copies. The saved pointer has a single\nuser, unregister_field_var_hists(), which runs when the target is\nremoved:\n\n\tfile = hist_data->field_var_hists[i]->hist_data->event_file;\n\nfind_compatible_hist() matches on keys alone, so it can pick one with no\nvariables of its own. check_var_refs() then returns false and the user\ncan remove it while the target still points at it:\n\n BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320\n Read of size 8 at addr ffff8880093b90e0 by task init/1\n\n Freed by task 1:\n  kfree+0x154/0x420\n  event_hist_trigger_free+0x1d5/0x320\n  event_hist_trigger_parse+0x35f3/0x69e0\n  trigger_process_regex+0x1a6/0x250\n\nSave the event file instead. It is all the dereference ever wanted, and\nit does not go away when the user removes a trigger.(CVE-2026-99235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Reject incomplete event filter expressions\n\nA non-empty expression normally finishes in predicate_parse()'s inner\nloop, which resolves the pending logical operators before jumping to\nfinalization. If the input ends after an operator, possibly followed by\nunary '!' tokens, the outer loop instead falls through with unresolved\noperator state.\n\nFor example, "common_pid == 1 || common_pid == 2 &&" leaves\nprog[0].target equal to -1. The second pass then reads prog[-1] before\nthe forward-jump check can reject it. Depending on adjacent slab\ncontents, it can also copy an out-of-bounds word into a branch target\nthat passes the forward-only check. A self-targeted perf tracepoint\ncounting event can reach this path through PERF_EVENT_IOC_SET_FILTER.\n\nReject the outer-loop fallthrough when a predicate has already been\nparsed. This ensures that non-empty expressions only reach finalization\nafter the inner loop has resolved their operators. Keep the existing\nno-filter error for input that has no predicates. Add a regression test\nfor trailing logical operators and unary negations.(CVE-2026-99236)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn\n\nl2cap_chan may be linked to l2cap_conn at most once. This is assumed in\nseveral places, eg l2cap_chan_del cleanup.\n\nThere is a TOCTOU race where the invariant is violated:\n\n    [Task 1]                          [Task 2]\n    l2cap_chan_connect                l2cap_sock_bind\n      l2cap_chan_lock                   lock_sock\n      l2cap_state_change                if (sk->sk_state != BT_OPEN)\n        chan->state = BT_CONNECT\n        l2cap_sock_state_change_cb      chan->state = BT_BOUND\n                                        sk->sk_state = BT_BOUND\n          lock_sock <------------------ release_sock\n          sk->sk_state = BT_CONNECT\n\nl2cap_sock_connect() does not check sk->sk_state, so since chan->state\nis now BT_BOUND, subsequent connect() ends up with second\n__l2cap_chan_add.\n\nExplicitly document and check the invariant in __l2cap_chan_add with\nWARN_ON_ONCE. The only callsite where it could be hit is\nl2cap_chan_connect, so add pre-check there to avoid relying on\nchan->state. chan->state read/write is not properly guarded currently so\nthere can be other TOCTOUC problems.\n\nAdd l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write.(CVE-2026-99239)","modified":"2026-11-11T12:45:08.356719623Z","published":"2026-11-11T12:26:24Z","upstream":["CVE-2026-31661","CVE-2026-64097","CVE-2026-64331","CVE-2026-64408","CVE-2026-68236","CVE-2026-74598","CVE-2026-80978","CVE-2026-90143","CVE-2026-90149","CVE-2026-90292","CVE-2026-93054","CVE-2026-93796","CVE-2026-98311","CVE-2026-98314","CVE-2026-98331","CVE-2026-98343","CVE-2026-98362","CVE-2026-98377","CVE-2026-98407","CVE-2026-98416","CVE-2026-98417","CVE-2026-98422","CVE-2026-98432","CVE-2026-98490","CVE-2026-98625","CVE-2026-98899","CVE-2026-98936","CVE-2026-99059","CVE-2026-99077","CVE-2026-99117","CVE-2026-99142","CVE-2026-99167","CVE-2026-99233","CVE-2026-99235","CVE-2026-99236","CVE-2026-99239"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4810"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31661"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64331"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68236"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74598"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90143"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93796"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98311"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98314"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98331"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98343"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98362"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98417"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98422"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98432"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98490"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98625"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98936"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99117"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99167"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99233"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99235"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99236"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99239"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-341.0.0.242.oe2203sp4"}]}],"ecosystem_specific":{"src":["kernel-5.10.0-341.0.0.242.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","perf-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-341.0.0.242.oe2203sp4.x86_64.rpm"],"aarch64":["bpftool-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","perf-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-341.0.0.242.oe2203sp4.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-4810.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}