{"schema_version":"1.7.2","id":"OESA-2026-4718","modified":"2026-11-04T13:54:51Z","published":"2026-11-04T13:54:51Z","upstream":["CVE-2026-64585","CVE-2026-72164","CVE-2026-72210","CVE-2026-74295","CVE-2026-74719","CVE-2026-80932","CVE-2026-80980","CVE-2026-89476","CVE-2026-89785","CVE-2026-89786","CVE-2026-89912","CVE-2026-89929","CVE-2026-89954","CVE-2026-90116","CVE-2026-90151","CVE-2026-90214","CVE-2026-93167","CVE-2026-93806","CVE-2026-93830","CVE-2026-97421","CVE-2026-97901","CVE-2026-98169","CVE-2026-98186","CVE-2026-98196","CVE-2026-98229","CVE-2026-98254","CVE-2026-98260","CVE-2026-98339","CVE-2026-98341","CVE-2026-98364","CVE-2026-98375","CVE-2026-98451","CVE-2026-98454"],"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\ncan: esd_usb: kill anchored URBs before freeing netdevs\n\nesd_usb_disconnect() frees each CAN netdev with free_candev() inside\nits per-netdev loop and only calls unlink_all_urbs(dev) afterwards.\nThe per-netdev private data (struct esd_usb_net_priv) is embedded in\nthe net_device allocation returned by alloc_candev(), so once\nfree_candev() has run, dev->nets[i] points to freed memory.\nunlink_all_urbs() then dereferences the freed dev->nets[i] to kill the\nper-netdev TX anchor (usb_kill_anchored_urbs(&priv->tx_submitted)),\nclear active_tx_jobs, and reset priv->tx_contexts[].\n\nReorder the teardown so the anchored URBs are killed before the netdevs\nare freed, matching other CAN/USB drivers in the same directory such as\nems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then\nfree: unregister the netdevs first (which stops their TX queues), call\nunlink_all_urbs(dev) once, then free the netdevs.\n\nThis issue was found by an in-house static analysis tool.(CVE-2026-64585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: avoid moving extents to occupied clusters\n\nFor non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical\nme_goal.  ocfs2_move_extent() initializes new_phys_cpos from that goal and\nexpects ocfs2_probe_alloc_group() to replace it with a free run in the\ntarget block group.\n\nThe probe currently leaves *phys_cpos unchanged if the scan reaches the\nend of the group without finding a free run.  An occupied goal at the last\nbit can therefore survive the probe and be passed to\n__ocfs2_move_extent(), which copies file data into a cluster still owned\nby another inode before the bitmap is updated.\n\nWhen the probe does find a free run, it also subtracts move_len from the\nending bit.  The start of an N-bit run ending at i is i - N + 1, so the\ncurrent calculation can report the bit immediately before the free run.\n\nClear *phys_cpos before scanning and use the correct free-run start. \nCallers already treat a zero result as -ENOSPC, so failed probes no longer\ncontinue with an occupied caller-controlled goal.(CVE-2026-72164)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: fix off-by-one in mapping pairs decoding bounds checks\n\nIn ntfs_mapping_pairs_decompress(), attr_end points one byte past the\nend of the attribute record:\n\n    attr_end = (u8 *)attr + le32_to_cpu(attr->length);\n\nThe two bounds checks validating that mapping pair data bytes fit within\nthe attribute use strict greater-than (>), which allows a one-byte\nout-of-bounds read when the data extends exactly to attr_end:\n\n  b = *buf & 0xf;\n  if (b) {\n      if (unlikely(buf + b > attr_end))   // off-by-one\n          goto io_error;\n      for (deltaxcn = (s8)buf[b--]; b; b--)\n          deltaxcn = (deltaxcn << 8) + buf[b];\n  }\n\nWhen buf + b == attr_end, the check evaluates to false and buf[b] reads\none byte past the valid attribute boundary. The same pattern appears in\nthe LCN delta bytes check.\n\nFix both checks to use >= so that buf[b] at exactly attr_end is\ncorrectly rejected as out of bounds.(CVE-2026-72210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: hdac_hdmi: Validate written enum value\n\nhdac_hdmi_set_pin_port_mux() uses the written enum value to index the\ntexts array before calling snd_soc_dapm_put_enum_double(), which validates\nthat the value is within the enum item range.\n\nAn out-of-range value can therefore make the driver read past the texts\narray before the helper rejects the write. Move the lookup after the helper\nhas accepted the value.(CVE-2026-74295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()\n\nThe SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in\nsmc_llc_event_handler() stores an incoming qentry into the local LLC flow\nwithout first checking whether a qentry is already pending. If a malicious or\nbuggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is\nactive and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the\npointer without freeing the previous allocation, leaking one kmalloc-96 object\nper spurious message.\n\nThe sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry\nguard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a\nduplicate message when qentry is already occupied falls through to break and is\nfreed by the kfree(qentry) at the out: label, rather than silently leaking the\nexisting allocation.\n\nThe response direction (smc_llc_rx_response()) is unaffected: it already guards\nwith flow->qentry at the equivalent site and drops duplicate responses\ncorrectly.(CVE-2026-74719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: flush works in dependency order\n\nvirtio_vsock_remove() stops the virtqueues and then flushes each work\nitem before freeing the enclosing virtio_vsock.  The current order does\nnot account for dependencies between those items: tx_work may queue\nsend_pkt_work, and send_pkt_work may queue rx_work.\n\nIn particular, send_pkt_work can set restart_rx and release tx_lock.\nThe remove path can then stop the queues and flush rx_work before\nsend_pkt_work queues it.  Although the later send_pkt_work flush waits\nfor that producer to finish, nothing waits for the newly queued rx_work,\nso kfree(vsock) can race with it.\n\nKASAN reported:\n\n  BUG: KASAN: slab-use-after-free in\n  virtio_transport_rx_work+0x487/0x4b0\n  Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47\n  Workqueue: virtio_vsock virtio_transport_rx_work\n  Call Trace:\n   virtio_transport_rx_work+0x487/0x4b0\n   process_one_work+0x688/0x1120\n   worker_thread+0x45b/0xd10\n  Allocated by task 1:\n   virtio_vsock_probe+0xef/0x6b0\n  Freed by task 84:\n   kfree+0x131/0x3c0\n   virtio_vsock_remove+0xd1/0x100\n\nFlush the works in producer-to-consumer order.  virtio_vsock_vqs_del()\nhas already disabled the queue callbacks and cleared the run flags, so\nafter tx_work and send_pkt_work are drained, no source remains that can\nqueue rx_work after its flush.(CVE-2026-80932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: stop killed, freed and out_of_sync sharing a byte\n\nThe three connection state flags are single-bit bitfields, so they occupy\none byte of struct smc_connection and every store to one is a\nread-modify-write of the other two:\n\n    u8  killed : 1;\n    u8  freed : 1;\n    u8  out_of_sync : 1;\n\nThey are not written under a common lock. smc_cdc_msg_validate() sets\nout_of_sync from the receive tasklet, while smc_conn_kill() sets killed\nfrom process context under lock_sock(), and the receive path does not defer\nto the backlog when the socket is owned -- smc_cdc_msg_recv() takes only\nbh_lock_sock().\n\nGive each flag its own byte so a store no longer touches its neighbours.\nAll readers test them as booleans and are unchanged. struct smc_connection\ngrows by two bytes.(CVE-2026-80980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix stream->outcnt underflow on duplicate RECONF responses\n\nA cached RECONF chunk may contain more than one request parameter.  A\nduplicate response can therefore find and process the same ADD_OUT request\nagain while another parameter is still outstanding, rolling back outcnt\ntwice and possibly underflowing it.\n\nTrack outstanding request types as bits and clear each bit after its first\nresponse.  Later responses for the same request are then ignored.(CVE-2026-89476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init\n\nntfs_reparse_init() and ntfs_objid_init() parse the index root of the\n$Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes\nnamed $R and $O). They read its type and rule fields through\nresident_data(), which does not check that the resident attribute is\nlarge enough to hold them.\n\nmi_enum_attr() accepts a resident attribute with data_off == asize and\ndata_size == 0. For such an attribute placed last in its MFT record,\nresident_data() returns a pointer to the end of the record_size buffer,\nso reading root->type / root->rule reads past the allocation.\n\nUse resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when\nit returns NULL, as ntfs_security_init() already does for $SDH / $SII.\n\nThe attribute is only parsed while mounting a crafted image, so this\nneeds CAP_SYS_ADMIN.\n\n BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306)\n Read of size 4 at addr ffff88801219dc00 by task mount\n  ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306)\n  ntfs_fill_super (fs/ntfs3/super.c:1604)\n  get_tree_bdev_flags (fs/super.c:1703)\n  vfs_get_tree (fs/super.c:1758)\n  path_mount (fs/namespace.c:4131)\n  __x64_sys_mount (fs/namespace.c:4360)(CVE-2026-89785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix out-of-bounds read in ext4_read_inline_dir()\n\next4_read_inline_dir() can read a dirent header past the end of its inline\nbuffer, triggering a slab-out-of-bounds read during getdents64():\n\n  BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry\n  Read of size 2 at addr ffff88800f3dd23c by task exploit/148\n   ...\n   __ext4_check_dir_entry\n   ext4_read_inline_dir\n   iterate_dir\n\nThe dirent payload lives in a buffer of exactly inline_size bytes:\n\n\tdir_buf = kmalloc(inline_size, GFP_NOFS);\n\nbut iteration runs in a position space extra_offset bytes larger\n(extra_size = extra_offset + inline_size) so the synthetic "." and ".."\nland at their block-dir offsets. A dirent is formed at "dir_buf + pos -\nextra_offset", yet the ext4_check_dir_entry() length argument uses the\nlarger extra_size. A position whose dirent header would extend past\nextra_size is therefore accepted, and the rescan loop's rec_len probe and\next4_check_dir_entry() dereference de->rec_len before the entry is rejected.\n\nReject a position whose minimum-size dirent header would not fit within\nextra_size before forming de, in both the rescan and main loops, and pass\ninline_size rather than extra_size to ext4_check_dir_entry() so the length\ncheck matches the physical buffer.(CVE-2026-89786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save\n\nMAPC with V=0 drops ite->collection but leaves the ITE on the device's\nITT list, and vgic_its_save_ite() dereferences it unconditionally. A\nguest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the\nhost when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it.\nThat sequence is UNPREDICTABLE per the architecture, but KVM already\nhandles the resulting state in the translate, MOVI and DISCARD paths.\n\nSave a zeroed entry, which vgic_its_restore_ite() reads back as\ninvalid. Skipping the ITE instead would leave the ITT slot holding\nwhatever is in guest memory, and restore rejects an entry naming a\ncollection the restored collection table does not have.(CVE-2026-89912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVM: Ensure INVVPID is emulated on the correct physical CPU\n\nWhen emulating INVVPID, KVM executes INVVPID on the physical CPU using\nvpid02 (instead of the L1 assigned VPID), after doing some validations\non the operands. However, it is possible that the physical CPU KVM\nexecutes INVVPID on is different from the CPU L2 is running on.\n\nFor example, in the following scenario:\n- L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1)\n- L1 migrates to CPU #2 and executes INVVPID\n- KVM executes INVVPID on CPU #2\n- L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)\n\nThe TLB entries on CPU #1 are never invalidated, because INVVPID was\nexecuted on CPU #2, and vmcs02 never ran on a different pCPU (i.e.\nvmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH).\n\nEnsure that INVVPID is being executed on the same pCPU that L2 last ran\non, and if not, fallback to clearing last_vpid=0 to trigger a full VPID\nflush on the next nested VM-Enter (as KVM will detect L1 using a\ndifferent VPID for L2). If L2 ends up running on a different pCPU, KVM\nwill flush the TLB anyway through vmx_vcpu_load_vmcs().(CVE-2026-89929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmtd: afs: validate v2 image info bounds\n\nThe AFS v2 parser uses footer[8] to locate the image information block\ninside the current erase block, then uses the image information\nregion_count to walk entries from a fixed local array. The footer offset\nand region count come from flash contents and are not checked against the\nerase block or the local image-info array before use.\n\nReject v2 entries whose image information offset would underflow the\nerase block calculation, and reject region counts that cannot fit in the\nlocal image-info array before walking region entries.(CVE-2026-89954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: mtpav: shut down output timer before card teardown\n\nsnd_mtpav_output_timer() rearms chip->timer while holding\nchip->spinlock and accesses the card-private mtpav state.\n\nsnd_mtpav_free() currently takes the same lock and calls\ntimer_delete() when the timer is active. This only removes a\npending timer; it does not wait for a callback that is already\nrunning and does not prevent the callback from rearming the timer.\n\nA callback running on another CPU can therefore continue after\nsnd_mtpav_free() releases the lock and access the card-private\nstate while the card is being torn down. It can also rearm the\ntimer after timer_delete() has returned.\n\nCall timer_shutdown_sync() without holding chip->spinlock. This\nwaits for any running callback to finish and prevents further\nrearming before the card-private mtpav state is released.(CVE-2026-90116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: remove callback IDR entry on client allocation failure\n\nnfs4_alloc_client() allocates an NFSv4.0 callback identifier before it\nfinishes setting up the client. If any later initialization step fails,\nthe error path frees the nfs_client directly with nfs_free_client(). That\nbypasses nfs_put_client(), which is where the callback IDR entry is\nremoved during normal teardown.\n\nA failed allocation can therefore leave cb_ident_idr pointing at a freed\nnfs_client. A later NFSv4.0 callback lookup by cb_ident would find the\nstale pointer and take a reference to it.\n\nMake the callback IDR removal helper callable by the allocation failure\npath, and remove the callback identifier before freeing the client.\n\nThis was found by a local static-analysis checker for publish-before-free\nlifetime bugs and confirmed by manual inspection.(CVE-2026-90151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: xilinx: formatter_pcm: fix stream_data leak on open error\n\nIn xlnx_formatter_pcm_open(), stream_data is allocated and\nadata->play_stream or adata->capture_stream is assigned early.  If a\nlater step, such as snd_pcm_hw_constraint_step() or\nsnd_pcm_hw_constraint_integer(), fails, the function returns the error\nimmediately.  ALSA does not call the close callback when open fails, so\nstream_data is leaked and the stream pointer is left dangling, pointing\nto a substream that ALSA frees.  A later interrupt would then call\nsnd_pcm_period_elapsed() on the freed substream.\n\nFree stream_data and clear the stream pointer on the error paths.(CVE-2026-90214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncsky: Fix a4/a5 restoration in syscall trace path\n\nThe syscall trace path reloads syscall arguments from pt_regs before\ncalling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall\narguments are prepared as stack arguments before invoking syscallid.\n\nThe current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since\nthose offsets are relative to the original pt_regs base, loading them\nafter changing sp fetches the wrong slots. As a result, traced syscalls\nthat use the 5th or 6th argument may receive corrupted arguments.\n\nThis is visible with mmap2(), which takes six arguments. A small\nPTRACE_SYSCALL reproducer opens a file and maps one page with:\n\n  mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0)\n\nBefore the fix, the traced child fails the mmap and exits with 12.\nAfter the fix, the mapping succeeds and the child exits with 0.\n\nFix the trace path by loading a4/a5 from pt_regs before changing sp.\n\nTested on: ck860f, linux-4.19.15, C-SKY abiv2(CVE-2026-93167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: validate assoc response length before status and IE access\n\ncfg80211_rx_assoc_resp() initialises the status and response-IE fields\nof cfg80211_connect_resp_params from the management frame before\nproving that the frame is long enough for those offsets. S1G and\nregular association responses also have different IE offsets, but the\nS1G path only patched resp_ie after the unsafe initialiser had already\nrun.\n\nDefer resp_ie, resp_ie_len, and status to after the link-iteration\nloop. Use a bool to remember whether the frame is S1G, then validate\nthe appropriate minimum length and set all three fields in a single\nif/else block. Funnel short-frame and SME-reject cleanup through a\nshared free_bss label for the abandon paths.(CVE-2026-93806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: xgmac2: disable RBUE in default RX interrupt mask\n\nEnabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive\nand can trigger a MAC interrupt storm under heavy RX pressure. When the\nDMA runs out of RX descriptors it fires RBUE continuously until software\nrefills the ring.\n\nHowever, RBUE is redundant: the normal RX completion interrupt (RIE)\nalready triggers NAPI, which processes completed descriptors and refills\nthe ring, causing the DMA to resume. The RBUE handler itself only sets\nhandle_rx - the same outcome as RIE.\n\nOn Agilex5 under heavy RX pressure, the MAC interrupt (which includes\nRBUE) was observed firing 1,821,811,555 times against only 2,618,627\nactual RX completions - a ~695x ratio - confirming the severity of the\nstorm.\n\nRBUE does not provide OOM recovery. If page_pool is exhausted,\nstmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays\nsuspended, and RBUE fires again on the next NAPI completion - a storm\nwith no forward progress. This patch trades that storm for a clean\nstall with the same RX outcome. Proper OOM recovery is a pre-existing\ngap outside the scope of this fix.\n\nNote: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool\ncounter will always read 0 on XGMAC2 devices. This behaviour is already\ninconsistent across DWMAC core versions.\n\nRemove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX\nto prevent the interrupt storm while keeping normal RX handling intact.(CVE-2026-93830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz()\n\nSeveral corner cases, especially important on 32 bits:\n\n- umem->iova is u64, the function argument should pass in u64 or\n  iova will be truncated\n- Check that the length is not too large for the iova\n- Check that lengths > 4G don't overflow the GENMASK(CVE-2026-97421)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenetlink: pin family module during policy dump\n\nThe generic netlink controller's policy dump keeps pointers to the target\nfamily's operation and policy tables in its callback state.  A dump may be\nsplit across multiple skbs and remain pending after the initial request.\n\nNetlink pins the module which owns the dump callback, but in this case\nthat is the controller's owner rather than the target family's owner.  The\ntarget family can consequently be unregistered and its module unloaded\nwhile a policy dump is pending.  Advancing the dump then dereferences\npolicy memory from the unloaded module.\n\nTake a reference to the target family's module when the dump starts.\nDrop it from the error and done paths.  This matches the lifetime for which\nthe dump context retains the family and policy pointers.(CVE-2026-97901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential OOB read in smb3_enum_snapshots()\n\nIf snapshot_array_size is smaller than GMT_TOKEN_SIZE,\nsmb3_enum_snapshots() sets ret_data_len to\nsizeof(struct smb_snapshot_array) without verifying the actual length\nof the server's reply.\n\nBecause SMB2_ioctl() places no lower bound on the server-supplied\nOutputCount and allocates retbuf to exactly that length, a short reply\nresults in ret_data_len exceeding the size of retbuf. The subsequent\ncopy_to_user() then reads past the end of retbuf, leaking adjacent slab\nmemory to userspace.  The subsequent clamp check is ineffective as it\nonly reduces ret_data_len.\n\nFix this by rejecting replies shorter than\nsizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set\nto the 12-byte struct size rather than the 16-byte\nMIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes\nis exactly what copy_to_user() attempts to read.(CVE-2026-98169)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length\n\nmwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a\nbeacon/probe-response RSN or WPA information element and then walks that\nmany 4-byte OUIs, comparing each with memcmp(). The count comes straight\nfrom the (attacker-supplied) IE and is never checked against the\nelement's own length, and the callers admit the element on element_id\nalone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted\nRSN/WPA IE with a large pairwise count therefore makes the walk read up\nto 255 * 4 bytes past the element -- an out-of-bounds read of the\nkmemdup()'d beacon buffer, reachable from any AP whose beacon/probe\nresponse is processed during scan-result parsing.\n\nPass the number of IE bytes available at the OUI list and bound the walk\nto the element. Keep the length signed and reject a negative value\nbefore any unsigned arithmetic, so a small or zero IE length cannot\nunderflow to a large size_t and defeat the bound.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-98186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmsmac: fix UAF in brcms_free_timer()\n\nbrcms_free_timer() calls brcms_del_timer() which uses the non-synchronous\ncancel_delayed_work() to cancel the timer's underlying delayed work.  If\nthe work callback (_brcms_timer) is already running, cancel_delayed_work()\nreturns false without waiting, and brcms_free_timer() proceeds to kfree(t)\nwhile the callback still accesses t through container_of().\n\nAdd an explicit cancel_delayed_work_sync() after brcms_del_timer() to\nguarantee that any in-flight callback has completed before the timer\nstructure is freed.(CVE-2026-98196)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: save input state data before secpath resets\n\nxfrm_input() stores the current xfrm_state in the skb secpath while it\ncontinues receive-side processing. Some input paths can reset that secpath\nbefore xfrm_input() has finished dereferencing the state.\n\nReceive callback users such as VTI and XFRM interfaces can reset the\nsecpath. The VTI receive path does so before checking whether the packet\ncrosses network namespaces, while the XFRM interface path does so only for\ncross-network-namespace packets. The XFRM_MAX_DEPTH error path can also\nreset the secpath before the final drop callback reports the current\nstate's protocol.\n\nIf secpath_reset() drops the last state reference while the state is\nconcurrently deleted, xfrm_input() can still dereference the freed state\nwhen selecting transport_finish() or reporting the drop callback protocol.\n\nSave the state protocol on the stack while the state is still valid,\nand use the already saved address family for transport_finish(). A larval\nXFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This\npreserves the existing drop-path fallback while avoiding the post-reset\nstate dereferences without adding an extra state reference to every\nreceived packet.(CVE-2026-98229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: use the adjusted address for the highmem page lookup\n\nswiotlb_bounce() reads the page frame number from the slot's recorded\norig_addr, then advances orig_addr by tlb_offset to reach the address\nthe caller asked about. The highmem branch mixes the two: the offset\nwithin the page comes from the adjusted address, the page from the value\nbefore it.\n\nOnce the adjustment crosses a page boundary the pair no longer describes\none location, and the whole copy lands one page below the intended one\nfor a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE\nwrites the device data over the wrong page and leaves the intended one\nstale, DMA_TO_DEVICE feeds the device from a page the mapping may not\ncover. Partial syncs through dma_sync_single_range_for_*() are what make\ntlb_offset non-zero.\n\nThe branch test is picked the same way, so a slot recorded in lowmem can\nbe adjusted into highmem and the lowmem path then hands a highmem\naddress to phys_to_virt().\n\nTake both from orig_addr once it is final and keep pfn in the branch\nthat uses it. PhysHighMem() asks the question straight from the address,\nas dma-debug already does.(CVE-2026-98254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexec: Cleanup POSIX timers right after de_thread()\n\nA per-thread CPU timer holds a reference to the PID of the thread it is\nattached to and, while it is armed, its node is queued in that thread's\nposix_cputimers. The task is looked up by that PID.\n\nWhen a non-leader thread exec()s, de_thread() changes which task owns\nthat PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL,\nbut the node is still queued on tsk, which is alive. timer_lock_sighand()\ntakes a failed lookup to mean that the node is already dequeued, so it\nhas nothing to undo.\n\nbegin_new_exec() calls posix_cpu_timers_exit(me) right after\nexec_task_namespaces() and that removes the leftover node, so the state\nnormally stays invisible. But bprm->point_of_no_return is set before\nde_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or\nexec_task_namespaces() fails, the task dies before it gets there.\nexit_itimers() then frees the k_itimer while its node is still queued,\nand reaping tsk later erases that freed node from the rbtree.\n\nIn short:\n\n      the non-leader thread B           the parent\n\n  timer_create(CLOCK_THREAD_CPUTIME_ID)\n  timer_settime()\n    arm_timer()            // the node is queued on B\n  execve()\n    de_thread(B)\n      exchange_tids(B, leader)  // B's PID now belongs to the leader\n      release_task(leader)\n        __exit_signal(leader)\n          posix_cpu_timers_exit(leader)  // cleans leader's queue, not B's\n          __unhash_process(leader)  // that PID has no task anymore\n    exec_mmap()\n      mmap_read_lock_killable(old_mm)\n                                kill(B, SIGKILL)\n      // -EINTR\n  get_signal()\n    do_exit()\n      exit_itimers()\n        posix_timer_delete()\n          posix_cpu_timer_del()\n        posix_timer_unhash_and_free()  // freed while still queued\n                                wait4()\n                                  release_task(B)\n                                    posix_cpu_timers_exit(B)\n                                      cleanup_timerqueue()\n                                        timerqueue_del()  // use-after-free\n\nMove the POSIX timer cleanup right after de_thread() before any of the\nlater failure conditions brings the task into do_exit().\n\n[ tglx: Move the cleanup right after de_thread() ](CVE-2026-98260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: don't filter by BSS type when removing stale entries\n\nWhen an assoc AP switches to a channel that already has a BSS entry,\ncfg80211_update_assoc_bss_entry() removes that entry before rehashing\nthe real one, since the two would otherwise collide in the BSS rbtree.\n\nThe lookup for that entry also required it to match the connection's BSS\ntype, so an entry advertising e.g. the IBSS capability bit was left in\nplace, and the following cfg80211_rehash_bss() then ran into it:\n\n  WARN_ON(!cmp)\n\nChanging the type shouldn't really happen, but can be triggered by a\nrogue AP/device, so drop the check and remove any entries matching\nthe comparison.(CVE-2026-98339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: don't free driver-owned scan requests\n\nWhen an interface goes down while a scan is running, cfg80211 completes\nthe scan towards userspace and frees the scan request. However, the\ndriver can be convinced that it owns the request, since the cancellation\nis (intended to be) asynchronous.\n\nThe WARN_ON() in the netdev notifier was meant to catch this, but it's\nnot actually avoidable, so it triggers and we get a UAF in scan_done().\n\nThere doesn't seem to be a great way around it, so just track that the\ndriver is still convinced it owns the request, and then just free it on\ncompletion if it was already cancelled. Also remove the warnings since\nthey can trigger in the intended architecture.(CVE-2026-98341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold net_device reference under RCU in bundle creation\n\nxfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into\na local pointer without taking a device reference, then pass it to\nxfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via\ndst_dev_put() and frees the old net_device, causing a use-after-free\nwhen xfrm6_fill_dst() later dereferences the stale dev pointer.\n\n  BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860\n  (net/ipv6/xfrm6_policy.c:86 netdev_hold())\n  Read of size 8 at addr ffff8880142fe588 by task exploit/153\n  Call Trace:\n   xfrm6_fill_dst+0x82c/0x860\n   xfrm_resolve_and_create_bundle+0x21d4/0x2bd0\n   xfrm_lookup_with_ifid+0x485/0x1640\n   ip6_dst_lookup_flow+0x19b/0x1e0\n   udpv6_sendmsg+0x1443/0x2dd0\n\nFix this by reading dst->dev via dst_dev_rcu() and keeping the RCU\nread-side critical section active until xfrm_fill_dst() has taken the\nrequired device references.(CVE-2026-98364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/netfront: drop RX packets with a short Ethernet header\n\nhandle_incoming_queue() pulls pull_to bytes into the head before\ncalling eth_type_trans().  pull_to is the length of the first RX slot,\ncapped at RX_COPY_THRESHOLD, and that length comes from the backend.\nNothing checks it against ETH_HLEN.\n\nIf the first slot is shorter than ETH_HLEN and more slots follow, the\nhead ends up shorter than an Ethernet header while skb->len is longer,\nand eth_type_trans() BUG()s in __skb_pull().  If the whole packet is\nshorter than ETH_HLEN, eth_type_trans() reads the header past the end\nof the data instead.\n\nPull at least ETH_HLEN, and drop the packet if that fails, which also\ndrops packets too short to hold an Ethernet header.  This also checks\nthe return value of the pull, which was ignored.(CVE-2026-98375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: use finish_no_open() for non-regular inodes\n\nAn O_CREAT open can find an existing symlink or another non-regular\ninode. cifs_atomic_open() calls finish_open() on it and attaches a\ncifsFileInfo. Symlink inodes have no CIFS release operation, so the\ndentry reference held by cifsFileInfo is leaked. FMODE_OPENED also\nprevents the VFS from following the symlink.\n\nTrack whether cifs_do_create() returned an open server handle. For\nnon-regular inodes, close the handle if present, remove the pending\nopen, and call finish_no_open() so the VFS can continue the lookup.\nDo not set FMODE_CREATED unless a regular file was opened. For\nO_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's\n-EFTYPE check.\n\nDefer closing a legacy POSIX handle on a non-regular inode until\nafter inode lookup. This avoids closing it again if lookup fails.(CVE-2026-98451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix create context out-of-bounds reads\n\nsmb2_parse_contexts() validates the complete create-context area but\ndoes not limit each record to its Next field before dispatching it.  A\nmalformed chain can therefore expose bytes beyond the current context to\na handler.  The QFid handler also used a full response-structure cast\nalthough it only reads DiskFileId.\n\nThe SMB2/SMB3 lease parsers made the same layout assumption: they read\nLeaseState and LeaseFlags at canonical offsets rather than at\nDataOffset.  A valid non-canonical DataOffset could therefore yield\nunrelated in-bounds data, while a short DataLength was still accepted.\n\nLimit each context to its Next value, reject offsets before the context\nheader, and reject malformed chains.  Bound the name range by the current\ncontext and do not dispatch a known handler when DataLength is zero.  Read\nthe QFid DiskFileId only when the context data covers that field.  Parse the\nlease context from DataOffset and require DataLength to match the v1 or v2\nlease_context size used by ksmbd.  A size mismatch skips lease parsing\nwithout failing the open.(CVE-2026-98454)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-340.0.0.241.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","perf-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-340.0.0.241.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","perf-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4718"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64585"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72164"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72210"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74295"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74719"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89785"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89786"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89929"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89954"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90116"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90151"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90214"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93167"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93806"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-97421"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-97901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98169"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98186"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98196"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98254"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98260"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98339"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98341"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98364"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98375"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98451"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98454"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}