{"schema_version":"1.7.2","id":"OESA-2026-4357","modified":"2026-10-16T11:59:44Z","published":"2026-10-16T11:59:44Z","upstream":["CVE-2025-40067","CVE-2026-52914","CVE-2026-53041","CVE-2026-53329","CVE-2026-63808","CVE-2026-63834","CVE-2026-63835","CVE-2026-63934","CVE-2026-64190","CVE-2026-64567","CVE-2026-68091","CVE-2026-68192","CVE-2026-68245","CVE-2026-68414","CVE-2026-72005","CVE-2026-74408","CVE-2026-74417","CVE-2026-74586","CVE-2026-74594","CVE-2026-74609","CVE-2026-74668","CVE-2026-74688","CVE-2026-80547","CVE-2026-80548","CVE-2026-80551","CVE-2026-80554","CVE-2026-80754","CVE-2026-80805","CVE-2026-80806","CVE-2026-80854","CVE-2026-80921","CVE-2026-80984","CVE-2026-80989","CVE-2026-80994","CVE-2026-89440","CVE-2026-89477","CVE-2026-89480","CVE-2026-89481","CVE-2026-89485","CVE-2026-89487","CVE-2026-89492","CVE-2026-89511","CVE-2026-89643","CVE-2026-89663","CVE-2026-89672","CVE-2026-89676","CVE-2026-89699","CVE-2026-89711","CVE-2026-89713","CVE-2026-89729","CVE-2026-89768","CVE-2026-89778","CVE-2026-89823","CVE-2026-89854","CVE-2026-89856","CVE-2026-89861","CVE-2026-89920","CVE-2026-89927","CVE-2026-89932","CVE-2026-89965","CVE-2026-89973","CVE-2026-89995","CVE-2026-90025","CVE-2026-90102","CVE-2026-90234","CVE-2026-90316","CVE-2026-90329"],"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\nfs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist\n\nIndex allocation requires at least one bit in the $BITMAP attribute to\ntrack usage of index entries. If the bitmap is empty while index blocks\nare already present, this reflects on-disk corruption.\n\nsyzbot triggered this condition using a malformed NTFS image. During a\nrename() operation involving a long filename (which spans multiple\nindex entries), the empty bitmap allowed the name to be added without\nvalid tracking. Subsequent deletion of the original entry failed with\n-ENOENT, due to unexpected index state.\n\nReject such cases by verifying that the bitmap is not empty when index\nblocks exist.(CVE-2025-40067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix fragment reassembly length accounting\n\nbatman-adv keeps a running payload length for queued fragments and uses it\nto validate a fragment chain before reassembly.\n\nThat accounting currently allows the accumulated fragment length to be\ntruncated during updates. As a result, malformed fragment chains can\nbypass the intended validation and drive reassembly with inconsistent\nlength state, leading to a local denial of service.\n\nFix the accounting by storing the accumulated length in a length-typed\nfield and rejecting update overflows before the existing validation logic\nruns.\n\nThe fix was verified against the original reproducer and against valid\nfragment reassembly paths.(CVE-2026-52914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix listxattr handling when the buffer is full\n\n[BUG]\nIf an OCFS2 inode has both inline and block-based xattrs, listxattr()\ncan return a size larger than the caller's buffer when the inline names\nconsume that buffer exactly.\n\nkernel BUG at mm/usercopy.c:102!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nRIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102\nCall Trace:\n __check_heap_object+0xe3/0x120 mm/slub.c:8243\n check_heap_object mm/usercopy.c:196 [inline]\n __check_object_size mm/usercopy.c:250 [inline]\n __check_object_size+0x5c5/0x780 mm/usercopy.c:215\n check_object_size include/linux/ucopysize.h:22 [inline]\n check_copy_size include/linux/ucopysize.h:59 [inline]\n copy_to_user include/linux/uaccess.h:219 [inline]\n listxattr+0xb0/0x170 fs/xattr.c:926\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x137/0x320 fs/xattr.c:988\n __do_sys_listxattr fs/xattr.c:1001 [inline]\n __se_sys_listxattr fs/xattr.c:998 [inline]\n __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998\n ...\n\n[CAUSE]\nCommit 936b8834366e ("ocfs2: Refactor xattr list and remove\nocfs2_xattr_handler().") replaced the old per-handler list accounting\nwith ocfs2_xattr_list_entry(), but it kept using size == 0 to detect\nprobe mode.\n\nThat assumption stops being true once ocfs2_listxattr() finishes the\ninline-xattr pass. If the inline names fill the caller buffer exactly,\nthe block-xattr pass runs with a non-NULL buffer and a remaining size of\nzero. ocfs2_xattr_list_entry() then skips the bounds check, keeps\ncounting block names, and returns a positive size larger than the\nsupplied buffer.\n\n[FIX]\nDetect probe mode by testing whether the destination buffer pointer is\nNULL instead of whether the remaining size is zero.\n\nThat restores the pre-refactor behavior and matches the OCFS2 getxattr\nhelpers. Once the remaining buffer reaches zero while more names are\nleft, the block-xattr pass now returns -ERANGE instead of reporting a\nsize larger than the allocated list buffer.(CVE-2026-53041)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Use krealloc_array() in dal_vector_reserve()\n\n[Why & How]\ndal_vector_reserve() computes the allocation size as\n"capacity * vector->struct_size" using uint32_t arithmetic, which can\nsilently wrap to a small value on overflow. This would cause krealloc to\nreturn a smaller buffer than expected, leading to heap overflows on\nsubsequent vector appends.\n\nReplace krealloc() with krealloc_array() which performs an internal\noverflow check and returns NULL on wrap, preventing the issue.\n\n(cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)(CVE-2026-53329)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix potential use-after-free in exfat_find_dir_entry()\n\nIn exfat_find_dir_entry(), the buffer_head obtained from\nexfat_get_dentry() is released with brelse(bh) before the fall-through\nTYPE_EXTEND branch reads the directory entry through ep (which points\ninto bh->b_data):\n\n\tbrelse(bh);\n\tif (entry_type == TYPE_EXTEND) {\n\t\t...\n\t\tlen = exfat_extract_uni_name(ep, entry_uniname);\n\t\t...\n\t}\n\nAfter brelse() drops our reference, nothing guarantees that the\nunderlying page backing bh->b_data remains valid for the subsequent\nexfat_extract_uni_name() read. This is the same pattern fixed in\ncommit fc961522ddbd ("exfat: Fix potential use after free in\nexfat_load_upcase_table()").\n\nMove brelse(bh) so it runs after ep is no longer dereferenced on\neach branch.\n\nConfirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y\n+ CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image\n(long filename with same-hash collisions forcing the TYPE_EXTEND path).\nWith a debug-only invalidate_bdev() inserted between brelse(bh) and\nthe ep read to make the stale-deref window deterministic, the\nunpatched kernel faults:\n\n  BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0\n  BUG: unable to handle page fault for address: ffff88801a5fa0c2\n  Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n  RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0\n\nWith this patch applied, the same instrumented harness completes\ncleanly under the same sanitizer stack. I have not reproduced a\ncrash on an uninstrumented kernel under ordinary reclaim; the\ninstrumented A/B establishes the lifetime violation and that the\npatch closes it, not an unaided triggerability claim.(CVE-2026-63808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tp_meter: restrict number of unacked list entries\n\nWhen the unacked_list is unbound, an attacker could send messages with\nsmall lengths and appropriated seqno + gaps to force the receiver to\nallocate more and more unacked_list entries. And the end either causing an\nout-of-memory situation or increase the management overhead for the (large)\nlist that significant portions of CPU cycles are wasted in searching\nthrough the list.\n\nWhen limiting the list to a specific number, it is important to still\ncorrectly add a new entry to the list. But if the list became larger than\nthe limit, the last entry of the list (with the highest seqno) must be\ndropped to still allow the earlier seqnos to finish and therefore to\ncontinue the process. Otherwise, the process might get stuck with too high\nseqnos which are not handled by batadv_tp_ack_unordered().(CVE-2026-63834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: v: prevent OGM aggregation on disabled hardif\n\nWhen an interface gets disabled, the worker is correctly disabled by\nbatadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable().\nIn this process, the skb aggr_list is also freed.\n\nBut batadv_v_ogm_send_meshif() can still queue new skbs (via\nbatadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all\ncores can no longer find the RCU protected list of hard interfaces. These\nqueued skbs will never be freed or consumed by batadv_v_ogm_aggr_work.\n\nThe batadv_v_ogm_iface_disable() function must block\nbatadv_v_ogm_queue_on_if() to avoid leak of skbs.(CVE-2026-63835)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: gyro: itg3200: fix i2c read into the wrong stack location\n\nitg3200_read_all_channels() takes `__be16 *buf' as a parameter and\nfills the i2c_msg destination as `(char *)&buf'. Since `buf' is the\nparameter (a pointer), `&buf' is the address of the local pointer\nslot on the stack of itg3200_read_all_channels(), not the address\nof the caller's scan buffer. The (char *) cast hides the type\nmismatch.\n\ni2c_transfer() therefore writes ITG3200_SCAN_ELEMENTS * sizeof(s16)\n= 8 bytes into the parameter's stack slot, which is discarded when\nthe function returns. The caller's scan buffer in\nitg3200_trigger_handler() is never written to, so\niio_push_to_buffers_with_timestamp() pushes uninitialised stack\ncontents to userspace via /dev/iio:deviceX every scan -- both a\nfunctional bug (no actual gyroscope or temperature data is\ndelivered through the triggered buffer) and an information leak.\n\nThe non-buffered read_raw() path is unaffected: it goes through\nitg3200_read_reg_s16() which uses `&out' on a local s16 value,\nwhere that is correct.\n\nDrop the spurious `&' so the i2c read writes into the caller's\nbuffer.(CVE-2026-63934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: team: fix NULL pointer dereference in team_xmit during mode change\n\n__team_change_mode() clears team->ops with memset() before restoring\nsafe dummy handlers via team_adjust_ops(). A concurrent team_xmit()\nrunning under RCU on another CPU can read team->ops.transmit during\nthis window and call a NULL function pointer, crashing the kernel.\n\nThe race requires a mode change (CAP_NET_ADMIN) concurrent with\ntransmit on the team device.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n Oops: 0010 [#1] SMP KASAN NOPTI\n RIP: 0010:0x0\n Call Trace:\n  team_xmit (drivers/net/team/team_core.c:1853)\n  dev_hard_start_xmit (net/core/dev.c:3904)\n  __dev_queue_xmit (net/core/dev.c:4871)\n  packet_sendmsg (net/packet/af_packet.c:3109)\n  __sys_sendto (net/socket.c:2265)\n\nThe original code assumed that no ports means no traffic, so mode\nchanges could freely memset()/memcpy() the ops.  AF_PACKET with\nforced carrier breaks that assumption.\n\nPrevent the race instead of making it safe: replace memset()/memcpy()\nwith per-field updates that never touch transmit or receive.  Those\ntwo handlers are managed solely by team_adjust_ops(), which already\ninstalls dummies when tx_en_port_count == 0 (always true during mode\nchange since no ports are present).  WRITE_ONCE/READ_ONCE prevent\nstore/load tearing on the handler pointers.\n\nsynchronize_net() before exit_op() drains in-flight readers that may\nstill reference old mode state from before port removal switched the\nhandlers to dummies.(CVE-2026-64190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject free space cache with more entries than pages\n\nWhen loading a v1 free space cache, __load_free_space_cache() takes\nnum_entries and num_bitmaps straight from the on-disk\nbtrfs_free_space_header. That header is stored in the tree_root under a key\nwith type 0, which the tree-checker has no case for, so neither count is\nvalidated before the load trusts it.\n\nThe load loops num_entries times and maps the next page whenever the current\none runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which\ndoes io_ctl->pages[io_ctl->index++]. But pages[] is allocated in\nio_ctl_init() from the cache inode's i_size, not from num_entries:\n\n\tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);\n\tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);\n\nSo if num_entries claims more records than the pages can hold, io_ctl->index\nruns off the end of pages[]. The write side never hits this because\nio_ctl_add_entry() and io_ctl_add_bitmap() both stop once\nio_ctl->index >= io_ctl->num_pages; the read side just never had the same\ncheck.\n\nTo trigger it, take a clean cache (num_entries = <N> here), set num_entries\nin the header to 0x10000, and fix up the leaf checksum so it still passes\nthe tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and\npages[] is a 16-pointer (kmalloc-128) array. The load now tries to read\n65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the\narray:\n\n  BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)\n  Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58\n   io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)\n   __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820)\n   load_free_space_cache (fs/btrfs/free-space-cache.c:1017)\n   caching_thread (fs/btrfs/block-group.c:880)\n   btrfs_work_helper (fs/btrfs/async-thread.c:312)\n   process_one_work\n   worker_thread\n   kthread\n   ret_from_fork\n\nfree-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc()\nat line 565, which is why that is the frame KASAN names. The out-of-bounds\nslot is then treated as a struct page and handed to crc32c(), so the bad\nread turns into a GP fault.\n\nAdd the missing check to io_ctl_check_crc(), which is where both the entry\nloop and the bitmap loop end up. When num_entries is too large the load now\nfails like any corrupt cache: __load_free_space_cache() drops it and rebuilds\nthe free space from the extent tree, so a valid cache is never rejected.(CVE-2026-64567)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: wacom: stop hardware after post-start probe failures\n\nwacom_parse_and_register() starts HID hardware before registering inputs\nand initializing pad LEDs/remotes. Those later steps can fail, but their\nerror paths currently release Wacom resources without stopping the HID\nhardware.\n\nRoute post-hid_hw_start() failures through hid_hw_stop() before\nreleasing driver resources.\n\nThis issue was identified during our ongoing static-analysis research while\nreviewing kernel code.(CVE-2026-68091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: make release_scratchbuffers idempotent\n\nbrcmf_pcie_release_scratchbuffers() frees the shared.scratch and\nshared.ringupd DMA buffers with dma_free_coherent() but does not clear\nthe pointers afterwards, unlike the sibling release_ringbuffers() which\nNULLs commonrings/flowrings/idxbuf on release.\n\nBoth the bus_reset .reset callback (brcmf_pcie_reset) and\nbrcmf_pcie_remove() call release_scratchbuffers.  When reset teardown\nhas run before removal, remove's own teardown would call\ndma_free_coherent() a second time on the already-freed DMA allocation.\n\nNULL the pointers after free, matching release_ringbuffers(), so a later\nrelease observes that the allocation has already been released.  This\npatch makes repeated sequential release safe; the reset-work lifetime is\nhandled separately by the following patch.\n\nThis issue was found by an in-house static analysis tool.(CVE-2026-68192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()\n\nThe vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only\nvalid while the lock is still being held. Once xa_unlock_irqrestore is\ncalled and returned, the pointer is no longer under lock and is subject\nto modification. Since, the caller still dereferences vm->task_info in\namdgpu_vm_get_task_info_vm() after the lock is removed, this causes a\nuse after unlock problem.\n\nRemove the lifetime issue present in amdgpu_vm_get_task_info_pasid()\nthrough removing the amdgpu_vm_get_vm_from_pasid() function from\namdgpu_vm.c and making the relevant code inline to hold the lock while\nit is still in use.\n\n(cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)(CVE-2026-68245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: cancel sched scan results work on unregister\n\ncfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a\ndriver result notification while a scheduled scan request is present. The\nwork callback recovers the containing cfg80211_registered_device and then\nlocks the wiphy and walks the scheduled-scan request list.\n\nwiphy_unregister() already makes the wiphy unreachable and drains rdev work\nitems before cfg80211_dev_free() can release the object, but it does not\ndrain sched_scan_res_wk. A queued or running result work item can therefore\ncross the unregister/free boundary and access freed rdev state.\n\nThe buggy scenario involves two paths, with each column showing the order\nwithin that path:\n\nscheduled-scan result path:        unregister/free path:\n1. cfg80211_sched_scan_results()   1. interface teardown stops and\n   queues rdev->sched_scan_res_wk.    removes the scheduled scan request.\n2. cfg80211_wq starts the work     2. wiphy_unregister() drains other\n   item and recovers rdev.            rdev work items.\n3. The worker locks rdev->wiphy    3. cfg80211_dev_free() destroys and\n   and walks rdev state.              frees rdev.\n\nCancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev\nwork items. cancel_work_sync() removes a pending result notification and\nwaits for an already running callback, so cfg80211_dev_free() cannot free\nrdev while this work item is still active.\n\nValidation reproduced this kernel report:\nBUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530\nWorkqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211]\nRead of size 8\nCall trace:\n  dump_stack_lvl+0x66/0xa0\n  print_report+0xce/0x630\n  cfg80211_sched_scan_results_wk+0x4a6/0x530\n  srso_alias_return_thunk+0x5/0xfbef5\n  __virt_addr_valid+0x224/0x430\n  kasan_report+0xac/0xe0\n  lockdep_hardirqs_on_prepare+0xea/0x1a0\n  process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212)\n  lock_is_held_type+0x8f/0x100\n  worker_thread+0x5ad/0xfd0\n  __kthread_parkme+0xc6/0x200\n  kthread+0x31e/0x410\n  trace_hardirqs_on+0x1a/0x170\n  ret_from_fork+0x576/0x810\n  __switch_to+0x57e/0xe20\n  __switch_to_asm+0x33/0x70\n  ret_from_fork_asm+0x1a/0x30(CVE-2026-68414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rt2x00: avoid full teardown before work setup in probe\n\nrt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for\nall probe failures. However, drv_data allocation and workqueue allocation\ncan fail before intf_work, autowakeup_work and sleep_work have been\ninitialized.\n\nDo not enter the full remove path until the probe has reached the point\nwhere those work items are set up. Return directly for drv_data allocation\nfailure, and use a small early cleanup path for workqueue allocation\nfailure.\n\nThis issue was found by our static analysis tool and then confirmed by\nmanual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The\nearly probe exits should not call a common teardown path that assumes the\nlater work setup has already completed.\n\nA QEMU PoC forced alloc_ordered_workqueue() to fail before the work\ninitializers are reached. The resulting fail path entered\nrt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with\nrt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.(CVE-2026-72005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: fix OOB access from firmware tx status queue ID\n\nath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a\n4-bit hardware field (0-15), but the txq array only has\nATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array\naccess.\n\nAdd a bounds check on ts.qid before using it as an array index.(CVE-2026-74408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix integer overflow in radeon_align_pitch()\n\nradeon_align_pitch() has the same kind of overflow issue as the old\namdgpu helper: both the alignment round-up add and the final\n'aligned * cpp' calculation can overflow signed int.\n\nIf that wraps, radeon_mode_dumb_create() can end up returning an\ninvalid pitch or creating a zero-sized dumb buffer.\n\nFix this by using check_add_overflow() for the alignment round-up and\ncheck_mul_overflow() for the final pitch calculation, returning 0 on\noverflow. Also reject zero pitch and size in\nradeon_mode_dumb_create().\n\nFound via AST-based call-graph analysis using sqry.(CVE-2026-74417)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: clear new_transport when removing a peer\n\nsctp_process_asconf_param() stores a newly added peer transport in\nasoc->new_transport. After all parameters in the ASCONF chunk have been\nprocessed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the\nnew transport.\n\nAn authenticated ASCONF from a remote SCTP peer can add a transport and\nremove it again with a wildcard DEL-IP parameter in the same chunk. The\nwildcard deletion preserves the transport on which the ASCONF arrived, but\nremoves the newly added transport through\nsctp_assoc_del_nonprimary_peers(). The removal does not clear\nasoc->new_transport, leaving it pointing to the removed transport.\n\nsctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points\nto the removed transport without holding a transport reference. During\nlocal address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on\ncontrol_chunk_list. After the transport is freed by RCU, a successful\nASCONF_ACK for the replacement address releases the queued HEARTBEAT and\nsctp_outq_select_transport() reads the freed transport's state.\n\nThe issue was found during a static audit of SCTP objects. With an\nauthenticated peer, the reproducer triggered the same KASAN report in 2\nof 2 unpatched runs on a KASAN-enabled netdev/main kernel:\n\n  BUG: KASAN: slab-use-after-free in sctp_outq_select_transport\n  Read of size 4 at addr ffff88800b9bd95c by task python3/197\n\n  Call Trace:\n   sctp_outq_select_transport+0x549/0x8b0 [sctp]\n   sctp_outq_flush+0x306/0x2c60 [sctp]\n   sctp_transport_immediate_rtx+0xaf/0x260 [sctp]\n   sctp_process_asconf_ack+0xa48/0xf70 [sctp]\n\n  Allocated by task 197:\n   sctp_transport_new+0x68/0x650 [sctp]\n   sctp_assoc_add_peer+0x258/0x12a0 [sctp]\n   sctp_process_asconf+0x5e9/0x1090 [sctp]\n\n  Last potentially related work creation:\n   __call_rcu_common.constprop.0+0x77/0xb70\n   sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp]\n   sctp_process_asconf+0xd9c/0x1090 [sctp]\n\nThe first invalid access was a four-byte read of transport->state at\nnet/sctp/outqueue.c:833. The same reproducer completed the full\nauthenticated ASCONF and local-address replacement sequence with this\nchange without a KASAN report or oops.\n\nClear new_transport when its peer is removed, before it can be used to\ncreate the HEARTBEAT.(CVE-2026-74586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: Shut down rtpoll_timer in psi_cgroup_free()\n\npsi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath\nand can race psi_trigger_destroy() taking down the last rtpoll trigger under\nrtpoll_trigger_lock:\n\n  psi_schedule_rtpoll_work()        psi_trigger_destroy()\n\n  rcu_read_lock();\n  task = rcu_dereference(rtpoll_task);\n                                    rcu_assign_pointer(rtpoll_task, NULL);\n                                    timer_delete(&rtpoll_timer);\n  mod_timer(&rtpoll_timer, ...);\n  rcu_read_unlock();\n                                    synchronize_rcu();\n                                    kthread_stop(task_to_destroy);\n\nThe group can then be freed with the re-armed timer still pending, and\npoll_timer_fn() runs on freed memory.\n\n461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling\nmechanism") deleted the timer synchronously after the synchronize_rcu(),\nwhich prevented this but raced trigger creation instead: the deletion could\ncancel the timer that a new trigger set armed during the grace period and,\nas creation also reinitialized the timer at the time, corrupt it.\n8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the\ninitialization into group_init() and the deletion into the locked section,\ntrading the creation races for the window above.\n\nNeither placement in the destruction path works. A pending timer firing\nwhile the group is alive is harmless though. poll_timer_fn() just wakes the\nrtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's\nlifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it\nby then. timer_shutdown_sync() because the timer is never armed again.(CVE-2026-74594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: read le->link under the node lock in tipc_node_link_down()\n\ntipc_node_link_down() caches the link pointer before taking n->lock:\n\n\tstruct tipc_link *l = le->link;\t\t/* unlocked */\n\n\tif (!l)\n\t\treturn;\n\ttipc_node_write_lock(n);\n\tif (!tipc_link_is_establishing(l)) {\t/* deref l */\n\t...\n\t\ttipc_link_reset(l);\t\t/* write into l */\n\tif (delete) {\n\t\tkfree(l);\n\t\tle->link = NULL;\n\nThe delete=true caller frees that very object under n->lock, so the lock\ndoes not protect the cached pointer against it:\n\n - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link\n   supervision timer via tipc_node_timeout(), reads l unlocked and then\n   dereferences it under n->lock;\n - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable()\n   -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true)\n   -> kfree(l).\n\nThe link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers\ndisable_media() only schedules the asynchronous cleanup_bearer() work, so\nits synchronize_net() runs after the links are already gone.  An in-flight\nCPU A that has read l therefore dereferences freed memory once B frees it:\na use-after-free read in tipc_link_is_establishing(), and a use-after-free\nwrite via tipc_link_reset() on the establishing branch.\n\nThe following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6:\n\n  BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285)\n  Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0\n   tipc_link_is_establishing (net/tipc/link.c:285)\n   tipc_node_link_down (net/tipc/node.c:1076)\n   tipc_node_timeout (net/tipc/node.c:843)\n  Allocated by task 9549:\n   tipc_link_create (net/tipc/link.c:490)\n   tipc_node_check_dest (net/tipc/node.c:1279)\n   tipc_disc_rcv (net/tipc/discover.c:252)\n   tipc_udp_recv (net/tipc/udp_media.c:389)\n  Freed by task 9549:\n   tipc_node_link_down (net/tipc/node.c:1084)\n   tipc_node_delete_links (net/tipc/node.c:1320)\n   bearer_disable (net/tipc/bearer.c:414)\n   __tipc_nl_bearer_disable (net/tipc/bearer.c:992)\n\nMove the le->link read inside tipc_node_write_lock(), so it is serialised\nagainst the kfree() in the delete path.  A racing teardown now either has\nnot run yet, and we see a valid link, or has already run, and we see NULL.(CVE-2026-74609)\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\nsctp: clear control chunk transport if it is being removed\n\nsctp_make_heartbeat_ack() caches the destination transport in\nchunk->transport without taking a reference. When src_out_of_asoc_ok is\nenabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead\nof being transmitted immediately.\n\nIf the peer transport is removed while the chunk is still queued,\nsctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing,\nbut only clears cached transport pointers in out_chunk_list.  The queued\ncontrol chunk therefore retains a dangling transport pointer.\n\nOnce an ASCONF_ACK clears the suppression and the queued control chunk is\ntransmitted, SCTP dereferences the stale transport pointer, leading to a\nuse-after-free.\n\nFix this by also clearing chunk->transport for queued control chunks in\ncontrol_chunk_list when removing the transport.(CVE-2026-74688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio_ccw: Implement a crw lock\n\nUnlike the channel_program struct, which covers synchronous I/O\nsubmissions and asynchronous interrupts, the CRW region relies\nexclusively on asynchronous events coming from hardware.\n\nImplement a lock to manage the list of those payloads, to ensure\nthey are read cohesively.(CVE-2026-80547)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio_ccw: Selectively expand io_mutex\n\nThe io_mutex was defined to serialize the io_regions, but then has\nalso sort of been associated with the I/O themselves because of\nthe close relationship they share.\n\nWith the handful of races that are possible, the choices are either to:\n A) expand the scope of io_mutex to close these remaining windows, or\n B) reduce the scope of io_mutex to just io_region, and introduce a new\n    lock mechanism for the remaining I/O resources\n\nThis patch implements A, since B brings with it a lot more interactions\nthat would need to be tracked and kept in a correct hierarchy. It also\ntakes advantage of the workqueue element for cp_free() that now gets\ncalled out of fsm_notoper(), which could be invoked out of an interrupt\ncontext and thus cannot acquire a mutex itself.(CVE-2026-80548)\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\ns390/vfio_ccw: Limit the number of channel program segments\n\nThe processing of channel programs, and the CCWs within them, is done\nrecursively. As such, there is an arbitrary (but not architectural)\nlimit to the number of CCWs that can exist in a single channel program.\n\nThe vfio-ccw logic breaks these channel programs into segments whenever\nit encounters a Transfer-In-Channel (TIC) CCW, and the combined number\nof segments count towards the global limit. Impose an equivalent limit\nto the number of segments until such logic can be made non-recursive.(CVE-2026-80554)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - fix F55 transmitter electrode count typo\n\nDuring F55 sensor detection, the transmitter (TX) electrode count was\nincorrectly assigned the value of the receiver (RX) electrode count\ndue to copy-paste typos.\n\nThis incorrect value was then propagated to the driver data and used\nby F54 to determine the diagnostics report size. On devices with more\nRX than TX electrodes, this inflated the perceived TX count, leading\nto incorrect report size calculations and potential out-of-bounds\nbuffer accesses.\n\nFix the typos by correctly assigning the TX electrode counts.(CVE-2026-80754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: validate attr entry pointer before field access\n\nxfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen,\nvaluelen) before checking if the entry pointer itself is within bounds.\nIf nameidx is crafted to point near the end of the buffer, these field\naccesses can read out-of-bounds before the bounds check at\nname_end > buf_end is performed.\n\nAdd explicit bounds checks for entry pointers before accessing their\nfields. Use offsetof() to check that the start of the flexible array\nmember (nameval/name) is within bounds, which ensures all preceding\nfields are safe to access.(CVE-2026-80805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don't enable DAX on new encrypted files\n\nCurrently, when a new encrypted regular file is created, the call to\next4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made\nbefore EXT4_INODE_ENCRYPT is set.  As a result, it can set S_DAX if the\nfilesystem is mounted with "-o dax=always".\n\nEXT4_INODE_ENCRYPT then actually gets set a bit later in\n__ext4_new_inode(), when it calls fscrypt_set_context() which calls\next4_set_context().  ext4_set_context() sets EXT4_INODE_ENCRYPT and\ncalls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too.\n\nThis was intended to clear S_DAX as well.  However, this was broken by\ncommit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load").  This\ncauses data written to the file to bypass encryption, also causing\nxfstests failures such as generic/548 (when "-o dax=always" is used).\n\nFix this by simplifying the flow by making __ext4_new_inode() set\nEXT4_INODE_ENCRYPT earlier.  This makes it take effect in\next4_set_inode_flags(inode, init=true), making S_DAX never be set.\n\nSimilarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first\nplace on new encrypted inodes.  Then it doesn't need to be cleared.\n\nAs a result of these simplifications, ext4_set_context() no longer needs\nto change inode flags or state when 'handle != NULL'.  Remove that too.(CVE-2026-80806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: keep port count until LUN teardown completes\n\ntcm_usbg_drop_nexus() permits session removal once tpg_port_count\nreaches zero. However, usbg_port_unlink() currently decrements that\ncount from the fabric_pre_unlink() callback, before core_dev_del_lun()\nwaits for active se_lun references to drain.\n\nIf removal of the last LUN races a nexus removal, the latter can observe\na zero port count and call target_remove_session(). This frees\nsess_cmd_map while an in-flight struct usbg_cmd, including its work item,\ncan still be accessed.\n\nOverlapping the last-LUN unlink with nexus removal reproduces this\nlifetime violation as a DEBUG_OBJECTS "free active" warning for\nusbg_cmd_work, followed by a target-core BUG/Oops.\n\nThe generic target-core unlink path has no callback after\ncore_dev_del_lun() completes. Add an optional fabric_post_unlink()\ncallback and use it for the f_tcm port count. The count now remains\nnonzero until core_dev_del_lun() has finished draining active LUN\nreferences, preventing nexus removal from freeing the session during\ncommand completion.(CVE-2026-80854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: vsie: zero stale crypto bits\n\nWhen shadowing crypto access bits from a format0 apcb (crycb 0 or 1),\nthe bits 64..255 are unchanged from whatever is in the vsie page in the\ncrycb and thus in the apcb. This gives a nested guest potential access\nto a device no longer available. Zero out the remaining bits.(CVE-2026-80921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: do not dereference an unset send buffer on the SMC-D teardown path\n\nsmc_close_stream_wait() calls smc_tx_prepared_sends() from inside its\nsk_wait_event() condition, and sk_wait_event() evaluates that condition\nonce with the socket lock released. smcd_buf_detach() clears\nconn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group\nterminating while a socket waits there leaves the helper dereferencing\nNULL, faulting out of close(). SIOCOUTQ reads the field by hand, and\nsmc_close_cancel_work() drops the lock across two cancel_*_sync() calls.\n\nSample the pointer once in the helper, report nothing prepared while it is\nunset, and bound the ioctl the same way. The receive tasklet dereferences\nthe field directly in smc_cdc_msg_recv_action(), not through this helper;\n1/2 is what keeps it from running that late.(CVE-2026-80984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Mark the connection down when bringing it up fails\n\nEvery failure path in tbnet_connected_work() undoes its own work and\nreturns without clearing login_sent, so the connection still looks\nestablished. The next tbnet_tear_down() therefore takes its main branch\nand repeats a teardown that already happened: it stops rings that are\nalready stopped, which is a dev_WARN() and fatal under panic_on_warn,\nand it releases net->remote_transmit_path even on the HopID mismatch\npath, where this connection never owned that id, silently freeing one\nthat someone else is still using.\n\nClear login_sent on those paths. That is enough for tbnet_tear_down() to\nleave the unwound state alone, and login_received has to stay set: it\nrecords that the peer has logged in and carries the transmit path it gave\nus, which nothing on this side can make the peer send again. Two things\nchange beyond keeping the teardown out of the way: the logout request in\nthat block is no longer sent, and the peer's next login request now\nre-queues our login work rather than connected_work, giving the\nconnection a fresh login instead of a retry on stale state.(CVE-2026-80989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix flow mask use-after-free on flow deletion\n\nThe commit in the Fixes tag below made so flow->mask free is scheduled\nvia RCU right after it is removed from the flow table.  The pointer\nstays in the flow structure and it can be accessible while in the same\nRCU critical section.  This is done to avoid requiring ovs_mutex for\nthe ovs_flow_free().\n\nHowever, while removing the flow during processing of CMD_DEL, we do\nnot take RCU read lock before the removal, and ovs_flow_cmd_fill_info()\nuses the flow->mask pointer afterwards.  The RCU read lock is taken,\nbut it's already late at that point.  The comment on that line\nacknowledges that the lock is cosmetic and doesn't serve a real purpose.\n\nThis leads to use-after-free if the RCU grace period passes between\nremoval and the filling.  It is a short race window, but it is there\nand can lead to a real crash in case memory allocation for the info\ntakes a bit longer:\n\n BUG: KASAN: slab-use-after-free in __ovs_nla_put_key\n             net/openvswitch/flow_netlink.c:1996\n BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30\n             net/openvswitch/flow_netlink.c:2250\n Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487\n\n Call Trace:\n  <TASK>\n  __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996\n  ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250\n  ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930\n  ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467\n  ...\n  netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556\n  </TASK>\n\n Allocated by task 9487:\n  mask_alloc net/openvswitch/flow_table.c:967\n  flow_mask_insert net/openvswitch/flow_table.c:1012\n  ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084\n  ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086\n  ...\n  netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556\n\n Freed by task 9485:\n  rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978\n  rcu_do_batch kernel/rcu/tree.c:2645\n  rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897\n  handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622\n  ...\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062\n\novs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info()\nto avoid this race.  This also helps with cleaning up the forced cast\nand the cosmetic RCU read lock.  Before the commit in the Fixes tag the\norder did not matter as long as the flow object itself was not freed.\n\nA wider RCU critical section could be another option, but we have a\nGFP_KERNEL allocation in the way.\n\nReported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.(CVE-2026-80994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: via-sdmmc: stop card-detect handling on probe failure\n\nrequest_irq() registers the SD card-detect interrupt and the probe enables\nit before mmc_add_host() runs. If mmc_add_host() fails, the error path only\nunmaps the registers and returns: the interrupt stays registered, so the\nhandler keeps running against the host once it is freed. via_sdc_isr()\ndereferences sdhost and its MMIO base and schedules carddet_work, which\nvia_sdc_card_detect() also runs against freed memory through its\ncontainer_of() dereference.\n\nAdd a probe-error path that disables and frees the interrupt and cancels\ncarddet_work before unmapping. carddet_work can re-enable the device\ninterrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it\nagain after cancelling the work.\n\nThis issue was found by an in-house static analysis tool and confirmed by\nmanual code review.(CVE-2026-89440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix NULL deref on untransmitted RECONF completion\n\nsctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and\nsctp_process_strreset_resp() complete a pending stream reconfiguration\nrequest by stopping the reconf timer on the transport it was sent on:\n\n\tt = asoc->strreset_chunk->transport;\n\tif (timer_delete(&t->reconf_timer))\n\t\tsctp_transport_put(t);\n\nchunk->transport is assigned by __sctp_packet_append_chunk() when the\nchunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms\nthe reconf timer at that same point. A request already published in\nasoc->strreset_chunk but not yet transmitted has neither, so completing\nit dereferences NULL.\n\nTwo ways to get there. sctp_send_asconf_del_ip() sets\nasoc->src_out_of_asoc_ok without sending anything when the address being\nremoved is the association's last one, and sctp_outq_flush_ctrl() then\nleaves every non-ASCONF control chunk queued; as only\nsctp_process_asconf_ack() clears that flag, it persists. An unprivileged\nprocess that removes such an address and then asks for a stream reset\npanics the kernel from softirq. A peer needs neither ASCONF nor local\nhelp: sctp_cmd_interpreter() uncorks the outqueue only once the whole\npacket has been processed, so a reply built while walking a RECONF chunk\nstays untransmitted for the rest of that walk, and one RECONF chunk\ncarrying [Incoming SSN Reset Request, Outgoing SSN Reset Request,\nResponse] -- or two RECONF chunks in one packet -- reaches the same\ndereference.\n\n  KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef]\n  RIP: 0010:timer_delete+0x67/0x110\n  Call Trace:\n   <IRQ>\n   sctp_process_strreset_addstrm_out (net/sctp/stream.c:832)\n   sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212)\n   sctp_do_sm (net/sctp/sm_sideeffect.c:1172)\n   sctp_assoc_bh_rcv (net/sctp/associola.c:1044)\n   sctp_rcv (net/sctp/input.c:243)\n   ip_local_deliver (net/ipv4/ip_input.c:262)\n   process_backlog (net/core/dev.c:6680)\n   </IRQ>\n\nA response can only acknowledge a request that was actually sent, so do\nnot match asoc->strreset_chunk while chunk->transport is NULL. Guarding\nthe lookup covers all three completion sites.(CVE-2026-89477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: reject a read that transferred too few bytes\n\nnvme_tcp_recv_data() completes a request once the current C2HData PDU\nhas been consumed. Nothing compares the total bytes received against\nthe length the command asked for: struct nvme_tcp_request has no\nreceive-side counter, queue->data_remaining is per queue, and\nblk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally\nwith no residual concept anywhere above.\n\nA controller can therefore answer a 4096-byte read with 512 bytes and\nhave it reported as a complete read; user space then gets 4096 bytes of\nwhich 3584 are whatever was already in the page. I reproduced that with\na test target.\n\nCount the bytes received and refuse to complete a successful read whose\ncount does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in\nnvme_tcp_process_nvme_cqe(). The success test shifts req->status right\nby one, because the driver keeps the wire value there and shifts it on\ncompletion, so the check must see what the completion path will see.\nOnly REQ_OP_READ is checked, because there the length comes from the\nsectors the request covers; a passthrough command is built by its\nsubmitter, which picks both command and buffer, so the kernel has\nnothing to compare against.(CVE-2026-89480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix host memory disclosure on R2T for a read command\n\nnvme_tcp_handle_r2t() does not check the direction of the request the\nR2T refers to. A malicious controller can send an R2T for a READ and\nthe host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the\nH2CData header and nvme_tcp_try_send_data() sends the request's data\nbuffer. That buffer is the READ destination, so its contents go to the\ncontroller.\n\nThe command then completes normally and nothing is logged.\n\nAgainst a test controller that answers every READ with an R2T, a 4096\nbyte buffered read returned all 4096 bytes, split over two R2Ts. The\npages contained stale kernel data, including an array of struct page\npointers.\n\nReject an R2T for a request that is not a write.(CVE-2026-89481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlockd: pin next file across nlm_inspect_file lock-drop\n\nnlm_traverse_files() pins the current file with f_count++ across\na mutex_unlock for nlm_inspect_file(), but nothing pins the saved\nnext pointer.  A concurrent nlm_release_file() can kfree the next\nfile during the unlock window, and the iterator dereferences freed\nmemory on the next loop step.\n\nPin both current and next before the lock-drop.  Advance by\nswapping the pinned cursors at the end of each iteration so next\nis always held alive across the unlock.\n\nAlways call nlm_file_release() after dropping the iteration pin,\nregardless of whether the file matched the predicate.  Use\nnlm_file_inuse(), which does a live walk of the inode lock list,\nrather than the cached f_locks field, so skipped files that never\nran nlm_inspect_file() are evaluated correctly.\n\nBecause every file in a hash bucket is now pinned and released,\nfiles skipped by the is_failover_file predicate that have no\nlocks, blocks, shares, or external references are deleted during\ntraversal.  The old code never evaluated skipped files for\ncleanup.  The new behavior is intentional: such files are stale\nand should not persist in the table.(CVE-2026-89485)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: only skb_tx_error() a packet we are about to drop\n\nqueue_userspace_packet() borrows the packet skb -- it only copies it into\na private netlink message (user_skb) and does not own it; on return\ndo_execute_actions() keeps forwarding it through the flow's remaining\nactions. Its error path nevertheless calls skb_tx_error(skb), which via\nskb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY,\nstripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc\nsays "skb must be freed afterwards").\n\nFor a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is\nwhat makes esp_input() skb_cow_data() before in-place AEAD; once it is\nstripped a later local ESP-in-UDP delivery decrypts in place over pages\nthe sender does not own -- an unprivileged page-cache write (the\n"Fragnesia" primitive).\ndo_execute_actions() ignores output_userspace()'s return value, so any\naction after a failed USERSPACE upcall inherits the stripped skb.\n\nMove the skb_tx_error() to the flow-miss drop path - the "default"\nbranch of ovs_dp_process_packet()'s switch(error), before kfree_skb().\n\nThe call has been here since commit 36d5fe6a0007 ("core, nfqueue,\nopenvswitch: Orphan frags in skb_zerocopy and handle errors") but was\nharmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate\nin-place decrypt; only then did stripping it on a still-forwarded skb\nbecome a page-cache write primitive.(CVE-2026-89487)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate directory-index entry counts when reading metadata\n\nocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and\nsignature of an indexed-directory block before it reaches higher-level\ncallers, but neither validator bounds the ocfs2_dx_entry_list counts\nagainst the capacity of the block that holds them.\n\nocfs2_dx_dir_search() then walks\n\n\tfor (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++)\n\t\tdx_entry = &entry_list->de_entries[i];\n\nover de_num_used entries with no bounds check.  entry_list is either\ndx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root,\ndx_root->dr_entries.  A crafted on-disk image can set de_num_used (and\nde_count, which is the __counted_by_le() bound of de_entries) to 0xffff\nand make the walk read far past the end of the 4KB metadata block, giving\na slab out-of-bounds read reachable from any path lookup, stat() or open()\non an indexed directory once the image is mounted.\n\nCommit 775c17386a6f ("ocfs2: validate dx_root extent list fields during\nblock read") already bounds dr_list for the non-inline dx_root, but left\nthe inline dr_entries path and the dx_leaf dl_list unchecked.  Add the\nsame read-time validation for both entry lists: de_count must equal the\ncapacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and\nde_num_used must not exceed de_count, rejecting corrupted metadata with\n-EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry\narray.\n\nde_count is always written as exactly the block capacity when a leaf or\ninline root is formatted, so the equality check does not reject any valid\nimage.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-89492)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: Fix NULL pointer dereference in TPA fragment processing\n\nUnder memory pressure, the qede driver encounters NULL pointer\ndereferences when processing TPA continuation fragments.\n\nCommit 8a8633978b84 ("qede: Add build_skb() support.") accidentally\ndropped the assignment of tpa_info->buffer.data in qede_tpa_start().\n\nWhen memory pressure causes an SKB allocation failure in qede_tpa_start(),\nthe driver sets tpa_start_fail = true and attempts to recycle the physical\npage later in qede_tpa_end() via qede_reuse_page(). However, because\nbuffer.data was left uninitialized (NULL), qede_reuse_page() pushes a\n"ghost" BD (valid DMA mapping but NULL data pointer) back into the\nactive Rx ring.\n\nThe next time the hardware uses this ring slot, it passes a NULL page\nto qede_fill_frag_skb(), causing a kernel panic.\n\nExample crash from production system:\n BUG: unable to handle kernel NULL pointer dereference at 0x8\n RIP: qede_fill_frag_skb+0x96/0x430 [qede]\n Call Trace:\n   qede_rx_int+0xb06/0x1de0\n   qede_poll+0x2f4/0x6c0\n   __napi_poll+0x2d/0x130\n\nFix the root cause by restoring the tpa_info->buffer.data assignment\nin qede_tpa_start(), ensuring valid pages are correctly tracked and\nrecycled. Additionally, update the stale comment for\nstruct qede_agg_info::buffer to reflect its current usage.(CVE-2026-89511)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naudit: avoid dropping live tree ref on fsnotify rule autoremove\n\naudit_del_rule() is used for both netlink deletion templates and internal\nfsnotify autoremove.  The former passes a parsed template which owns a\ntemporary tree reference; the latter passes the installed entry itself.\n\nThe unconditional audit_put_tree() at the end of audit_del_rule() assumes\nthe template case.  For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify\nautoremove event therefore drops the installed rule's live tree reference.\nRepeating this across rules sharing the same tree can free the tree while\nanother rule still references it, and a later autoremove dereferences the\nfreed pathname while comparing rules.\n\nMove the temporary-tree put to audit_rule_change(), the caller that owns\ndeletion templates.  Keep it in the AUDIT_DEL_RULE cleanup so both\nsuccessful deletion and -ENOENT still release the parser-owned tree.\n\n[PM: dropped unnecessary comment for line length reasons](CVE-2026-89643)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: revoke copy-notify stateids before dropping their reference\n\nCopy-notify stateids live in the s2s_cp_stateids IDR and on their parent\nstid's sc_cp_list, pinned by a single membership reference.\n_free_cpntf_state_locked() only unlinks an entry once its refcount reaches\nzero, so any revoke path that runs while a concurrent\nfind_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops\nthe reference without unlinking, leaving the entry discoverable with its\nmembership reference already consumed. A second revoke or a laundromat tick\nthen frees it while the reader still holds the pointer -- a\nKASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state().\n\nThis affected all three revoke paths:\n\n  - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called\n    _free_cpntf_state_locked() on the first list entry; a holder that had\n    bumped cs_count made it return early, so the next iteration\n    re-decremented and burned the holder's reference.\n\n  - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise\n    used _free_cpntf_state_locked() and could drop 2->1 without unlinking.\n\nAdd revoke_cpntf_state_locked(), which unhashes the entry from the IDR and\nsc_cp_list first (deferring the final free to any holder), and use it from\nall three revoke paths. The drain now walks with list_for_each_entry_safe()\nand revokes each entry unconditionally, so it terminates in one pass per\nentry regardless of cs_count. The unhash is gated on\n!list_empty(&cps->cp_list); the idr_remove() gate matters because\nidr_alloc_cyclic() may have recycled the so_id by then. Keep\n_free_cpntf_state_locked() for the reference-holder put path only, where a\nconcurrent revoke may already have unlinked the entry (its list_del_init()\nthen a no-op).(CVE-2026-89663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: gate nfs2 setacl by argp->mask\n\nThe NFSACL v2 SETACL path shares the decoder convention used by its\nv3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access\nonly when NFS_ACL is set in the request mask and argp->acl_default\nonly when NFS_DFACL is set, leaving the other pointer NULL because\nthe argument buffer is zeroed up to pc_argzero before decode.\n\nnfsacld_proc_setacl() then hands both pointers to set_posix_acl()\nunconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS\n"remove this ACL type" operation, so an omitted arm is\nindistinguishable from an explicit request to delete that ACL. A\nSETACL carrying only NFS_ACL silently strips the directory's default\nACL; mask=0 strips both.\n\nThis is the same defect just fixed in nfsd3_proc_setacl(); apply the\nsame remedy. Gate each set_posix_acl() call on its mask bit and\ninitialize error to 0 so that a request with neither bit set leaves\nthe on-disk ACLs untouched and returns success. The out_drop_lock\npath and the unconditional posix_acl_release() in\nnfsaclsvc_release_setacl() already tolerate the skipped arms.(CVE-2026-89672)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix stale s2s_cp_stateids IDR entry for async COPY\n\nFor an async COPY, nfsd4_copy() called nfs4_init_copy_state() before\ndup_copy_fields(), so the s2s_cp_stateids IDR was pointed at\n&u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is\nreused by the next request. dup_copy_fields() copies only the value into\nasync_copy, so the IDR slot dangled at the transient buffer for the whole\nbackground copy. Any IDR walker then dereferences reused request memory:\nthe laundromat reads cs_type from it and, if the bytes look like an\nexpired NFS4_COPYNOTIFY_STID, follows into\nrefcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has\nthe same exposure via idr_find().\n\nDuplicate the fields first, then register the stateid on the stable\nasync_copy. result->cb_stateid is unchanged.(CVE-2026-89676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: validate symlink target length in NFSv4 CREATE\n\nnfsd4_decode_create() accepts an unbounded cr_datalen from the wire for\nNF4LNK symlink targets, allowing a client to force a kmalloc of up to\nthe maximum RPC payload size (several MiB) per COMPOUND op that persists\nuntil compound teardown.  The VFS rejects oversized targets with\nENAMETOOLONG, but the allocation has already occurred.\n\nReject cr_datalen == 0 early with nfserr_inval and cr_datalen greater\nthan NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the\nallocation.(CVE-2026-89699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check\n\nThe header for commit e75b23f9e323 ("nfsd: check d_can_lookup in\nfh_verify of directories") details the assumption that justified\nadding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is\ninvalid (in the case of NFS reexport).\n\nWhen NFSD exports an NFS filesystem it is very possible for\nnfsd_mode_check() to encounter a @dentry that doesn't have\ni_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and\nNFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()).\n\nSo remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir\nreturn on that branch must stay. It guards the subsequent\nlookup_one_unlocked() -> __lookup_slow() path, which calls\ninode->i_op->lookup() with no NULL check, so returning nfserr_notdir\nis what keeps a client LOOKUP into such a @dentry from dereferencing\na NULL method pointer.(CVE-2026-89711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: check truncate permission under inode lock\n\nnfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC\nbefore it takes inode_lock(). The comparison uses the file size sampled\nby that unlocked read, but the actual ATTR_SIZE update is applied later\nunder inode_lock() by notify_change().\n\nThis leaves a TOCTOU window for append-only files. If a client sends a\nSETATTR that does not shrink the file at the time of the unlocked\nsample, a concurrent append can extend the file before nfsd_setattr()\ntakes inode_lock(). notify_change() then applies a real truncation\nwithout the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS\ntruncate syscall paths perform their own append-only checks before\ncalling notify_change(), so NFSD must make this decision against the\nlocked size it is about to change.\n\nSplit the write-count acquisition from the truncation permission check.\nKeep get_write_access() before the locked setattr work, then recheck\nwhether the requested size is below i_size_read(inode) after inode_lock()\nhas been acquired and before notify_change(ATTR_SIZE). This also avoids\nthe plain unlocked inode->i_size load.(CVE-2026-89713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature\n\nsensor_hub_get_feature() clamps its return value to the caller's buffer\nsize, but the copy loop still copies field->report_size / 8 bytes for\neach report value. A malicious HID descriptor can advertise a large\nfeature field size while an IIO caller supplies a small stack buffer,\nsuch as a single s32, causing an out-of-bounds write.\n\nHID core stores parsed report values in __s32 slots and clamps extracted\nvalues to 32 bits. Reject feature fields that require more than one slot\nper value, guard the total byte count calculation, and clamp each\nper-value copy to the remaining caller buffer.(CVE-2026-89729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: fix user path of nested backing files\n\nbacking_file_open() derives the path to be stored in the new backing\nfile from user_file->f_path.  This is incorrect when user_file itself\nis a backing file, which is the case for nested stacking filesystems,\ne.g. overlayfs mounts where the lowerdir of one overlayfs is the merged\ndirectory of another.  Since commit def3ae83da02 ("fs: store real path\ninstead of fake path in backing file f_path") the f_path of a backing\nfile holds the real path of the intermediate layer, not the path that\nthe user opened.\n\nCommit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this\nfor such configurations by passing file_user_path() from\novl_open_realfile().  However, commit 6af36aeb147a ("lsm: add\nbacking_file LSM hooks") changed the first argument of\nbacking_file_open() from the user path back to the user file and\nderived the path from user_file->f_path again, silently re-introducing\nthe problem.\n\nAs a result, files mapped through a nested overlayfs show the wrong\npath in /proc/<pid>/maps and in perf/ftrace mmap records.  For example,\nwith two nested overlayfs mounts:\n\n  mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested\n  echo hello > /ovl/lower/foo\n  mount -t overlay overlay \\\n\t-o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \\\n\t/ovl/merged\n  # at least two lowerdirs are needed when upperdir is nonexistent\n  mount -t overlay overlay \\\n\t-o lowerdir=/ovl/merged:/ovl/lower /ovl/nested\n\nmapping /ovl/nested/foo shows a disconnected path instead of the user\npath:\n\n  # readlink /proc/self/fd/3\n  /ovl/nested/foo\n  # grep foo /proc/self/maps\n  7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo\n\nThe bogus path is derived from the f_path of the intermediate backing\nfile, whose mount is a private clone that d_path() cannot resolve.\n\nFix this by using file_user_path(), which returns the outermost\nuser-visible path for backing files and falls back to\n&user_file->f_path for regular files.  This restores the behavior of\ncommit 924577e4f6ca ("ovl: Fix nested backing file paths") for\noverlayfs and also fixes the same problem for the other\nbacking_file_open() callers, fuse passthrough and erofs ishare, when\ntheir user file is itself a backing file.\n\nbacking_tmpfile_open() has the same pattern but is not affected: it is\nonly called by ovl_create_tmpfile() for the upper layer, and another\noverlayfs is rejected as upperdir by the DCACHE_OP_REAL check in\novl_mount_dir_check(), so its user_file can never be a backing file.(CVE-2026-89768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: fix out-of-bounds page array access on empty zisofs block\n\nzisofs_uncompress_block()'s empty-block fast path returns\npcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the\ndecompression path which returns bytes produced relative to poffset.\nzisofs_fill_pages() uses that return to advance its page cursor, so when\nthe zisofs block size is below PAGE_SIZE and a sub-page block leaves\npoffset partway into a page, a following empty block over-counts and\nadvances pages[] one element past its end, after which\n"if (poffset && *pages)" reads pages[1] out of bounds.  rock.c only\nrejects a block-size shift > 17, so a crafted "ZF" Rock Ridge record can\nset it below PAGE_SHIFT; the bug is reached by an ordinary read() of a\ncompressed file on such a mounted ISO9660 image.\n\nReturn the byte count relative to poffset and zero only\n[poffset, PAGE_SIZE) of the first page, matching the decompression path.\nThe page-aligned case (poffset == 0) is unaffected.\n\n  BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290)\n  Read of size 8 at addr ffff88800f5eac48 by task exploit/142\n   zisofs_read_folio (fs/isofs/compress.c:290)\n   read_pages (mm/readahead.c:184)\n   ...\n   filemap_read (mm/filemap.c:2814)\n   vfs_read (fs/read_write.c:574)\n   __x64_sys_pread64 (fs/read_write.c:769)\n   do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)\n  The buggy address is located 0 bytes to the right of the\n  allocated 8-byte region in the kmalloc-8 cache(CVE-2026-89778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: fix race between partial drm_dev_register() failure and ioctl\n\nIf drm_dev_register() fails after registering a minor (e.g. render minor\nregistered, primary minor fails), userspace could have opened the first\nminor and entered a drm_dev_enter() critical section. Since the\nunplugged flag was never set, the ioctl proceeds while the error path\ntears down device resources.\n\nFix this by introducing drm_dev_synchronize_unplug(), which sets the\nunplugged flag and waits for the SRCU barrier, ensuring all in-flight\ndrm_dev_enter() critical sections complete before cleanup proceeds; call\nit on the error path of drm_dev_register().(CVE-2026-89823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix cs84xx use-after-free on host teardown\n\nqla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via\n__qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran\nbefore scsi_remove_host(), which is what removes the 84xx_fw_version host\nsysfs attribute. A concurrent read of that attribute in the window between\nthe two calls executes qla24xx_84xx_fw_version_show(), which dereferences\nthe freed ha->cs84xx, resulting in a use-after-free.\n\nMove qla84xx_put_chip() to after scsi_remove_host() in both\nqla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once\nscsi_remove_host() returns, the sysfs attribute is gone and kernfs has\ndrained any in-flight show(), so no reader can touch cs84xx; the put still\nruns before the host and ha are freed.(CVE-2026-89854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation\n\nha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and\nha->max_qpairs are u8. Deriving the queue count as\n"ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board\n(or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X\nvectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X\ncount of 1 zeroes it as well, and in target mode the subsequent\n"ha->max_req_queues--" then underflows 0 to 255.\n\nWhen the count is 0, qla2x00_alloc_queues() calls\nkzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is\nnot NULL, so the allocation check passes and the following\n"ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory\nor crashing the kernel.\n\nAdd qla_calc_queue_count() to clamp the derived value into\n[1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and\nuse it at all three derivation sites (qla25xx_iospace_config(),\nqla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the\ntarget-mode decrement so it cannot reintroduce a zero (which would in\nturn underflow max_qpairs).(CVE-2026-89856)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()\n\nIn the format 1 path, the virtual port is located on ha->vp_list while\nholding vport_slock, but the lock is dropped before vp is used:\nqla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/\nREGISTER_FDMI_NEEDED are set on vp. No reference is taken across that\nwindow, so a concurrent qla24xx_deallocate_vp_id() can tear the vport\ndown and free it, leading to a use-after-free.\n\nTake a vport reference (vref_count) under vport_slock when the matching\nvp is found, and drop it after the last use of\nvp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before\nunlinking and freeing the vport, so the pointer stays valid. This\nmatches the reference idiom already used by the other ha->vp_list\ntraversals.(CVE-2026-89861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: Fix memory corruption by not reinjecting CK machine checks\n\nChannel-subsystem damage machine checks are for the host channel\nsubsystem. The guest channel subsystem is emulated in the userspace VMM.\nThere is no point in forwarding such machine checks into the guest.\n\nThis also simplifies the machine check reinjection and avoids kfree of a\nstack variable as reported by sashiko.  There might be still machine\nchecks that have the ck bit set with another bit (like instruction\ndamage), mask out the CK bit in s390_backup_mcck_info(), like the CP and\nED bits already are.(CVE-2026-89920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: hyper-v: Clamp stimer deadline to avoid livelock\n\nFix an issue where userspace or the guest can program an Hyper-V\nsynthetic timer to have a deadline in the past via integer overflow,\npreventing the CPU from making progress and triggering an RCU stall.\n\nHyper-V's SynIC exposes 4 per-vCPU synthetic timers to the\nguest, which are emulated by KVM. Each is programmed through the\nHV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending\non CONFIG, COUNT represents either the absolute expiration time or the\nperiod of a periodic timer, both expressed in 100ns ticks. These timers\nmay be set both by the guest (WRMSR) and the host (KVM_SET_MSRS).\n\nWhen the timer is enabled, stimer_start() translates COUNT to an\nabsolute monotonic deadline and arms an hrtimer. If COUNT is set to a\nvalue close to U64_MAX, the deadline calculation can overflow.\n\n    ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))\n\nThis can result in a CPU livelock. stimer_start() arms the timer\nvia hrtimer_start() with a deadline in the past, which causes it to\nimmediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with\nthe intention of causing KVM to deliver a synthetic interrupt on the\nnext vCPU guest enter.\n\nThen, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the\nrequest, calling kvm_hv_process_stimers(). This would normally disable\nthe timer via stimer_expiration() once the deadline is in the past.\nHowever, the deadline comparison is done between the KVM reference\ncounter and stime->exp_time, which is a big value close to U64_MAX, so\nthis never happens for a few thousand years.\n\nkvm_hv_process_timers() then re-arms the timer via stimer_start(), since\nit was not disabled, which again fires immediately. Before entering\nthe guest, kvm_vcpu_exit_request() checks kvm_request_pending(),\nwhich returns true due to the newly raised KVM_REQ_HV_STIMER. Then\nvcpu_enter_guest() aborts the guest entry, returning early into\nvcpu_run(), which loops back again into vcpu_enter_guest(), restarting\nthe cycle.\n\nSince there are no manual yields in this loop, a task with SCHED_FIFO\nmay starve RCU grace-period kthreads, which exposes the stalls found\nby syzcaller:\n\n    rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n    rcu:    (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2)\n    rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0\n    rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0\n    rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.\n        ( ... )\n    Call Trace:\n     <IRQ>\n     __run_hrtimer kernel/time/hrtimer.c:1773 [inline]\n     __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841\n     hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903\n     local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline]\n     __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062\n     instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]\n     sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056\n     </IRQ>\n     <TASK>\n     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697\n    RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline]\n    RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194\n    Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 <e8> 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36\n    RSP: 0018:ffffc900040a7320 EFLAGS: 00000206\n    RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900\n    RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001\n    RBP: ffffc900040a73b0 R08: ffffffff8fc3d0\n---truncated---(CVE-2026-89927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVMX: Always flush vpid02 on first use\n\nMake sure vpid02 is always flushed on first use by setting last_vpid=0\nwhen allocating vpid02.  nested_vmx_transition_tlb_flush() will always\ndetect a VPID change on first VM-Enter after VMXON, because VPID=0 in\nvmcs12 is not allowed if L1 enables VPID.\n\nThis avoids using stale TLB entries from a previous lifetime of the\nVPID, that might have been associated with a different vCPU (or a\ncompletely different VM).\n\nNote that last_vpid is already being initialized as 0 when the vCPU is\ncreated, but it is not reset when vpid02 is freed on VMXOFF. Hence, the\nproblem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM\nhappens to reuse a VPID that has TLB entries on the physical CPU.(CVE-2026-89932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/btt: reject an arena whose nfree is below the lane count\n\nThe BTT info block's nfree field, the number of reserve free blocks, is\nread from the medium without validation.  btt_freelist_init() and\nbtt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree,\nbut the I/O path indexes them by the lane from nd_region_acquire_lane(),\nwhich is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree.\nA crafted or foreign arena whose nfree is below the lane count makes\nfreelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write.\n\nbtt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the\ncode does not currently honor: num_lanes is ND_MAX_LANES regardless of\nnfree.  Reject an arena whose nfree is below num_lanes at discovery,\nbefore the per-lane arrays are allocated, enforcing that invariant.(CVE-2026-89965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: check the data direction of a C2HData PDU\n\nnvme_tcp_handle_c2h_data() finds the request by command id and checks\nthat it has a payload, but it does not check that the command asked for\ndata to be read.  A controller that answers a write command with C2HData\ntherefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits\nWARN_ON_ONCE(i->data_source) and returns 0.  The receive path turns that\ninto -EFAULT and resets the controller.\n\nNo data is copied, so this is not memory corruption.  What a controller\ngets is a kernel warning it can raise at will, which is fatal on a host\nbooted with panic_on_warn.\n\nThe send path already knows the direction - it consults rq_data_dir()\nwhen it builds a command - and nvme_tcp_handle_r2t() checks the length\nand the offset of the request it names.  The C2HData path does not check\nthe direction at all.\n\nReject a C2HData PDU whose command is not a read.  Rejecting it fails\nthe command and resets the controller, as the neighbouring check in this\nfunction does; what goes away is the warning.\n\n  [    6.885580] ------------[ cut here ]------------\n  [    6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71\n  [    6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy)\n  [    6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work\n  [    6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330\n  [    6.903739] Call Trace:\n  [    6.904085]  <TASK>\n  [    6.909254]  __skb_datagram_iter+0x433/0x820\n  [    6.911026]  skb_copy_datagram_iter+0x37/0x120\n  [    6.911622]  nvme_tcp_recv_skb+0xa07/0x4320\n  [    6.913378]  __tcp_read_sock+0x1ab/0x810\n  [    6.915788]  nvme_tcp_try_recv+0x152/0x1e0\n  [    6.918222]  nvme_tcp_io_work+0x1e4/0x6c0\n  [    6.926906]  </TASK>\n  [    6.927226] ---[ end trace 0000000000000000 ]---\n  [    6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data\n  [    6.928709] nvme nvme0: receive failed:  -14(CVE-2026-89973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-direct: return struct page from dma_direct_alloc_from_pool()\n\nCommit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool\nhelper") changed dma_direct_alloc_from_pool() to return the CPU address\nfrom dma_alloc_from_pool(). That fits dma_direct_alloc(), but\ndma_direct_alloc_pages() also uses the helper and expects a struct page *.\n\nFix this by making dma_direct_alloc_from_pool() return the struct page *\nagain, and pass the CPU address back through an out-parameter for the\ndma_direct_alloc() caller.(CVE-2026-89995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix OOB altmode array index\n\nThe UCSI displayport driver indexes the connector's port altmode array\nwith the GET_CURRENT_CAM response after checking it is not 0xff. The\nport altmode array is UCSI_MAX_ALTMODES elements long. If the PPM\nreturns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and\nnot equal to 0xff, the kernel may crash with an array index OOB error.\n\nUpdate the UCSI displayport driver to verify the current cam is less\nthan UCSI_MAX_ALTMODES before accessing the port altmode array.(CVE-2026-90025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pnfs: key the data server cache on the NFS version\n\nnfs4_pnfs_ds_add() keys the per-net data server cache on the multipath\naddress set alone, and struct nfs4_pnfs_ds records no version. That\nsuffices for the files layout driver, which always connects with version\n4, but flexfiles takes its version tuple from GETDEVICEINFO per device,\nand one address can legitimately serve both NFSv3 and NFSv4.\n\nTwo deviceids on one address with different ds_versions[0].version\ntherefore share a single nfs4_pnfs_ds, and whichever mirror connects\nfirst pins ds_clp to its own version. The other one is handed that\nclient anyway, so it selects rpc_call_ops for a version the connection\ndoes not speak, and the mismatched sequence-slot handling dereferences\nNULL.\n\nAdd the version to the cache key so the two cannot alias, giving each\nversion its own nfs4_pnfs_ds and connection while both mirrors stay\nusable. Only the major version is compared, since that is what selects\nrpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files\nlayout driver passes the 4 it already hardcodes at connect time.(CVE-2026-90102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Return a delegation the client fails to record\n\nWhen an NFS server grants a delegation in an OPEN reply,\nnfs_inode_set_delegation() records it on the client. However, three\nof its error flows return without sending DELEGRETURN.\n\nA delegation can be relinquished only by DELEGRETURN (RFC 8881\nSection 20.2.4), so dropping one silently leaves the server believing\nthe client still holds it. If the server happens to recall that\ndelegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE\nbecause it has no record of the stateid. The server revokes the\ndelegation and moves it onto its cl_revoked list, because the client\nnever sends the FREE_STATEID that would drain it. Every subsequent\nSEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED,\nand the client's state manager loops issuing TEST_STATEID across its\ndelegations without ever clearing the condition.\n\nThe window is easy to reach now that a server offers a write\ndelegation on any write OPEN: a delegation recalled for one opener\nraces a re-open that the server answers with a fresh write\ndelegation.\n\nInstead of dropping it, hand the delegation back during these error\nflows.(CVE-2026-90234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/omap: dsi: Do not copy isr table\n\nTo be able to unregister stuff from isrs, the corresponding table was\ncopied.  Nobody seems to unregister stuff that way, so it does not help.\nBut there are stack-allocated objects passed to these isrs giving chances\nof UAF of these objects if irqs are unregistered while they are handled,\nso better do not copy that table.(CVE-2026-90316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: synchronize input before cleaning up a failed probe\n\nhid_device_io_start() allows reports to run concurrently with probe. If\nthe probe subsequently fails, __hid_device_probe() releases driver\nresources and clears hdev->driver without first excluding those report\ncallbacks.\n\nFor example, a report may enter hidraw_report_event() while the failure\npath frees the associated hidraw object, leading to a use-after-free when\nthe report takes the object's list lock.\n\nStop input before performing failed-probe cleanup. This reacquires\ndriver_input_lock and waits for any report callback already in progress.(CVE-2026-90329)","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-337.0.0.238.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","perf-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-337.0.0.238.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-337.0.0.238.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","perf-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-337.0.0.238.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4357"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53041"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53329"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63808"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63835"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63934"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64190"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64567"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68091"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68192"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68245"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72005"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74417"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74586"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74594"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74609"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74688"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80547"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80548"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80551"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80554"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80754"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80806"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89440"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89480"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89481"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89485"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89487"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89492"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89511"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89643"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89663"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89672"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89699"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89711"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89713"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89729"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89768"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89778"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89856"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89927"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90102"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90316"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90329"}],"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"}}