{"schema_version":"1.7.2","id":"OESA-2026-4039","modified":"2026-09-25T01:27:35Z","published":"2026-09-25T01:27:35Z","upstream":["CVE-2024-56531","CVE-2024-56614","CVE-2025-40269","CVE-2026-31548","CVE-2026-43303","CVE-2026-46004","CVE-2026-52929","CVE-2026-52954","CVE-2026-52969","CVE-2026-52982","CVE-2026-53242","CVE-2026-63870","CVE-2026-63916","CVE-2026-64048","CVE-2026-64449","CVE-2026-64458","CVE-2026-64582","CVE-2026-68108","CVE-2026-68320","CVE-2026-68404","CVE-2026-68470","CVE-2026-72102","CVE-2026-72106","CVE-2026-72108","CVE-2026-72200","CVE-2026-72225","CVE-2026-72397","CVE-2026-74330","CVE-2026-74359","CVE-2026-74374","CVE-2026-74437","CVE-2026-74443","CVE-2026-74444","CVE-2026-74549","CVE-2026-74730","CVE-2026-74752","CVE-2026-80540","CVE-2026-80541","CVE-2026-80569","CVE-2026-80570","CVE-2026-80694","CVE-2026-80707","CVE-2026-80717","CVE-2026-80726","CVE-2026-80737","CVE-2026-89557","CVE-2026-89586","CVE-2026-89608","CVE-2026-89631","CVE-2026-89633","CVE-2026-89637","CVE-2026-89649","CVE-2026-89650","CVE-2026-89652","CVE-2026-89655","CVE-2026-89846","CVE-2026-89847","CVE-2026-89859","CVE-2026-90013"],"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:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting.  OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long.  It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed().  This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.(CVE-2024-56531)\n\nIn the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says: In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries)  return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write if (old_xs)  xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption. It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331]  <TASK>[76613.048468]  ? __die+0x20/0x60[76613.051581]  ? page_fault_oops+0x15a/0x450[76613.055747]  ? search_extable+0x22/0x30[76613.059649]  ? search_bpf_extables+0x5f/0x80[76613.063988]  ? exc_page_fault+0xa9/0x140[76613.067975]  ? asm_exc_page_fault+0x22/0x30[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60[76613.076573]  ? xsk_map_delete_elem+0x23/0x60[76613.080914]  __sys_bpf+0x19b7/0x23c0[76613.084555]  __x64_sys_bpf+0x1a/0x20[76613.088194]  do_syscall_64+0x37/0xb0[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---(CVE-2024-56614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix potential overflow of PCM transfer buffer\n\nThe PCM stream data in USB-audio driver is transferred over USB URB\npacket buffers, and each packet size is determined dynamically.  The\npacket sizes are limited by some factors such as wMaxPacketSize USB\ndescriptor.  OTOH, in the current code, the actually used packet sizes\nare determined only by the rate and the PPS, which may be bigger than\nthe size limit above.  This results in a buffer overflow, as reported\nby syzbot.\n\nBasically when the limit is smaller than the calculated packet size,\nit implies that something is wrong, most likely a weird USB\ndescriptor.  So the best option would be just to return an error at\nthe parameter setup time before doing any further operations.\n\nThis patch introduces such a sanity check, and returns -EINVAL when\nthe packet size is greater than maxpacksize.  The comparison with\nep->packsize[1] alone should suffice since it's always equal or\ngreater than ep->packsize[0].(CVE-2025-40269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down\n\nWhen the nl80211 socket that originated a PMSR request is\nclosed, cfg80211_release_pmsr() sets the request's nl_portid\nto zero and schedules pmsr_free_wk to process the abort\nasynchronously. If the interface is concurrently torn down\nbefore that work runs, cfg80211_pmsr_wdev_down() calls\ncfg80211_pmsr_process_abort() directly. However, the already-\nscheduled pmsr_free_wk work item remains pending and may run\nafter the interface has been removed from the driver. This\ncould cause the driver's abort_pmsr callback to operate on a\ntorn-down interface, leading to undefined behavior and\npotential crashes.\n\nCancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down()\nbefore calling cfg80211_pmsr_process_abort(). This ensures any\npending or in-progress work is drained before interface teardown\nproceeds, preventing the work from invoking the driver abort\ncallback after the interface is gone.(CVE-2026-31548)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page->private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page->private but don't\nclear it before freeing pages.  When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage->private values.\n\nThis causes a use-after-free in the swap subsystem.  The swap code uses\npage->private to track swap count continuations, assuming freshly\nallocated pages have page->private == 0.  When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page->lru containing LIST_POISON values,\ncausing a crash:\n\n  KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n  RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page->private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Handle probe errors properly\n\nThe probe procedure of setup_card() in caiaq driver doesn't treat the\nerror cases gracefully, e.g. the error from snd_card_register() calls\nsnd_card_free() but continues.  This would lead to a UAF for the\nfurther calls like snd_usb_caiaq_control_init(), as Berk suggested in\nanother patch in the link below.\n\nHowever, the problem is not only that; in general, this function drops\nthe all error handlings (as it's a void function) although its caller\ncan propagate an error to snd_probe(), which eventually calls\nsnd_card_free() as a proper error path.  That said, we should treat\neach error case in setup_card(), and just return the error code\npromptly, which is then handled later as a fatal error in snd_probe().\n\nThis patch achieves it by changing the setup_card() to return an error\ncode.  Also, the superfluous snd_card_free() call is removed, too.\n\nNote that card->private_free can be set still safely at returning an\nerror.  All called functions in card_free() have checks of the\nunassigned resources or NULL checks.(CVE-2026-46004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: stream: fully roll back denied add-stream state\n\nWhen ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and\nthen lowers outcnt. That leaves removed stream metadata behind, so a\nlater re-add can reuse a stale ext and hit a null-pointer dereference in\nthe scheduler get path.\n\nFix the rollback by tearing down the removed stream state the same way\nother stream resizes do. Unschedule the current scheduler state, drop\nthe removed stream ext state with sctp_stream_outq_migrate(), and then\nreschedule the remaining streams.\n\nThis keeps scheduler-private RR/FC/PRIO lists consistent while fully\nrolling back denied outgoing stream additions.(CVE-2026-52929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: handle rbtree insertion error in decode_choose_args()\n\nA message of type CEPH_MSG_OSD_MAP contains an OSD map that itself\ncontains a CRUSH map. The received CRUSH map may optionally contain\nchoose_args that get decoded in decode_choose_args(). In this function,\nnum_choose_arg_maps is read from the message, and a corresponding number\nof crush_choose_arg_maps gets decoded afterwards. Each\ncrush_choose_arg_map has a choose_args_index, which serves as the key\nwhen inserting it into the choose_args rbtree of the decoded crush_map.\nIf a (potentially corrupted) message contains two crush_choose_arg_maps\nwith the same index, the assertion in insert_choose_arg_map() triggers a\nkernel BUG when trying to insert the second crush_choose_arg_map.\n\nThis patch fixes the issue by switching to the non-asserting rbtree\ninsertion function and rejecting the message if the insertion fails.\n\n[ idryomov: changelog ](CVE-2026-52954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Reject wrapped offset in kvm_reset_dirty_gfn()\n\nkvm_reset_dirty_gfn() guards the gfn range with\n\n\tif (!memslot || (offset + __fls(mask)) >= memslot->npages)\n\t\treturn;\n\nbut offset is u64 and the addition is unchecked.  The check can be\nsilently bypassed by a u64 wrap.\n\nThe dirty ring backing those entries is MAP_SHARED at\nKVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the\nslot and offset fields of any entry between when the kernel pushes\nthem and when KVM_RESET_DIRTY_RINGS consumes them.  On reset,\nkvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds\nthem straight back into this check; only the flags handshake is\ntreated as the handover, the slot/offset payload is taken on trust.\n\nCrafting two entries\n\n\tentry[i].offset   = 0xffffffffffffffc1\n\tentry[i+1].offset = 0\n\nmakes the coalescing loop in kvm_dirty_ring_reset() compute\n\n\tdelta = (s64)(0 - 0xffffffffffffffc1) = 63\n\nwhich falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the\nexisting mask by setting bit 63.  The trailing kvm_reset_dirty_gfn()\ncall then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;\nthe sum is 0 in u64 and the bounds check passes.\n\nThat offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()\nunchanged.  On the legacy MMU path -- kvm_memslots_have_rmaps() ==\ntrue, i.e. shadow paging, any VM that has allocated shadow roots, or\na write-tracked slot -- it reaches gfn_to_rmap(), which indexes\nslot->arch.rmap[0][] with a near-U64_MAX gfn.  That is an\nout-of-bounds load of a kvm_rmap_head, followed by a conditional\nclear of PT_WRITABLE_MASK in whatever the loaded pointer points at.\nThe path is reachable from any process holding /dev/kvm.\n\nRange-check offset on its own first, so the addition cannot wrap.\nmemslot->npages is bounded well below U64_MAX, so once offset <\nnpages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG)\nstays in range.(CVE-2026-52969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()\n\nsyzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()\nwhen accessing skb->len for tx statistics after usb_submit_urb() has\nbeen called:\n\n  BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760\n    drivers/net/usb/rtl8150.c:712\n  Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226\n\nThe URB completion handler write_bulk_callback() frees the skb via\ndev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU\nin softirq context before usb_submit_urb() returns in the submitter,\nso by the time the submitter reads skb->len the skb has already been\nqueued to the per-CPU completion_queue and freed by net_tx_action():\n\n  CPU A (xmit)                      CPU B (USB completion softirq)\n  ------------                      ------------------------------\n  dev->tx_skb = skb;\n  usb_submit_urb()      --+\n                          |-------> write_bulk_callback()\n                          |           dev_kfree_skb_irq(dev->tx_skb)\n                          |         net_tx_action()\n                          |           napi_skb_cache_put()   <-- free\n  netdev->stats.tx_bytes  |\n    += skb->len;          <-- UAF read\n\nFix it by caching skb->len before submitting the URB and using the\ncached value when updating the tx_bytes counter.\n\nThe pre-existing tx_bytes semantics are preserved: the counter tracks\nthe original frame length (skb->len), not the ETH_ZLEN/USB-alignment\npadded "count" value that is handed to the device.  Changing that\nwould be a user-visible accounting change and is out of scope for\nthis UAF fix.(CVE-2026-52982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams\n\nsnd_pcm_drain() uses init_waitqueue_entry which does not clear\nentry.prev/next, and add_wait_queue with a conditional\nremove_wait_queue that is skipped when to_check is no longer\nin the group after concurrent UNLINK.  The orphaned wait entry\nremains on the unlinked substream sleep queue.  On the next\ndrain iteration, add_wait_queue adds the entry to a new queue\nwhile still linked on the old one, corrupting both lists.  A\nsubsequent wake_up dereferences NULL at the func pointer\n(mapped from the spinlock at offset 0 of the misinterpreted\nwait_queue_head_t), causing a kernel panic.\n\nReplace init_waitqueue_entry/add_wait_queue/conditional\nremove_wait_queue with init_wait_entry/prepare_to_wait/\nfinish_wait.  init_wait_entry clears prev/next via\nINIT_LIST_HEAD on each iteration and sets\nautoremove_wake_function which auto-removes the entry on\nwake-up.  finish_wait safely handles both the already-removed\nand still-queued cases.(CVE-2026-53242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()\n\nThe aoe driver (or similar) generates a non-IPv6 packet\n(e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit()\non a 6LoWPAN interface (configured by the user or test case).\n\nSince the packet is not IPv6, the 6LoWPAN header_ops->create function\n(lowpan_header_create or header_create) returns early without initializing\nthe lowpan_addr_info structure in the skb headroom.\n\nIn the transmit function (lowpan_xmit), the driver calls lowpan_header\n(or setup_header) which unconditionally copies and uses the lowpan_addr_info\nfrom the headroom, which contains uninitialized data.\n\nFix this by dropping non IPv6 packets.\n\nA similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().(CVE-2026-63870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: wacom: Fix OOB write in wacom_hid_set_device_mode()\n\nwacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE\nusage is always located in the first field (field[0]) of the feature report.\nHowever, a device can specify HID_DG_INPUTMODE in a different field.\n\nIf HID_DG_INPUTMODE is in a field other than the first one and the first\nfield has a report_count smaller than the usage_index of HID_DG_INPUTMODE,\nthis leads to an out-of-bounds write to r->field[0]->value.\n\nFix this by storing the field index of HID_DG_INPUTMODE in 'struct\nhid_data' during feature mapping.  In wacom_hid_set_device_mode(), use\nthis stored field index to access the correct field and add bounds\nchecks to ensure both the field index and the value index are within\nvalid ranges before writing.(CVE-2026-63916)\n\nIn the Linux kernel, the following vulnerability has been resolved: net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot. On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ism_selected becomes 0, and the subsequent ism_dev[0]->lgr_lock dereference in smc_conn_create() causes a NULL pointer dereference. Require ism_dev[i] to be non-NULL before accepting a CHID match.(CVE-2026-64048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: vme_user: bound slave read/write to the kern_buf size\n\nThe SLAVE-path helpers buffer_to_user() and buffer_from_user() copy\n'count' bytes into/out of the fixed-size kern_buf (size_buf ==\nPCI_BUF_SIZE == 0x20000, 128 KiB) using *ppos as the offset, without\nbounding *ppos + count against size_buf.\n\nvme_user_write()/vme_user_read() only clamp count to the VME window size\n(image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the\nuser-supplied slave.size -- validated against the VME address space (up\nto VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE.  When the window\nexceeds 128 KiB, a write()/read() copies past the kern_buf allocation.\n\nClamp count against size_buf in both helpers, with an early return when\n*ppos is already at/after the buffer end.  *ppos is >= 0 here (the caller\nrejects negative offsets), so size_buf - *ppos cannot wrap.  This mirrors\nthe existing clamp in the MASTER-path helpers resource_to_user() /\nresource_from_user(), and matches the read()/write() convention of a\nshort transfer at end-of-buffer.\n\nFound by static analysis (CodeQL taint tracking + CBMC bounded model\nchecking) and confirmed dynamically under KASAN with the vme_fake bridge:\n\n  BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80\n  Write of size 262144 at addr ffff888004100000 by task trigger/68\n    _copy_from_user+0x2d/0x80\n    vme_user_write+0x13e/0x240 [vme_user]\n    vfs_write+0x1b8/0x7a0\n    ksys_write+0xb8/0x150(CVE-2026-64449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/ops-common: handle extreme intervals in damon_hot_score()\n\nFix three issues in damon_hot_score() that comes from wrong handling of\nextreme (zero or too high) monitoring intervals user setup.\n\nWhen the user sets sampling interval zero, damon_max_nr_accesses(), which\nis called from damon_hot_score(), causes a divide-by-zero.  Needless to\nsay, it is a problem.\n\nWhen the user sets the aggregation interval zero, the function returns\nzero.  It is wrong, since the real maximum nr_acceses in the setup should\nbe one.  Worse yet, it can cause another divide-by-zero from its caller,\ndamon_hot_score(), since it uses damon_max_nr_accesses() return value as a\ndenominator.\n\nWhen the user sets the aggregation interval very high, damon_hot_score()\ncould return a value out of [0, DAMOS_MAX_SCORE] range.  Since the return\nvalue is used as an index to the regions_score_histogram array, which is\nDAMOS_MAX_SCORE+1 size, it causes out of bounds array access.\n\nThe issues can be relatively easily reproduced like below.  The sysfs\nwrite permission is required, though.\n\n    # ./damo start --damos_action lru_prio --damos_quota_space 100M \\\n            --damos_quota_interval 1s\n    # cd /sys/kernel/mm/damon/admin/kdamonds/0\n    # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us\n    # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us\n    # echo commit > state\n    # dmesg\n    [...]\n    [  131.329762] Oops: divide error: 0000 [#1] SMP NOPTI\n    [...]\n    [  131.336089] RIP: 0010:damon_hot_score+0x27/0xd0\n    [...]\n\nFix the divide-by-zero intervals problems by explicitly handling the zero\nintervals in damon_max_nr_accesses().  Fix the out-of-bound array access\nby applying [0, DAMOS_MAX_SCORE] bounds before returning from\ndamon_hot_score().\n\nThe issue was discovered [1] by Sashiko.(CVE-2026-64458)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix a use-after-free problem in rxe_mmap\n\nrxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list\nand releases pending_lock while the struct's kref is still at 1:\n\n   list_del_init(&ip->pending_mmaps);\n   spin_unlock_bh(&rxe->pending_lock);   /* ref == 1, no lock held */\n   ret = remap_vmalloc_range(vma, ip->obj, 0);  /* walks PTEs */\n   [...]\n   rxe_vma_open(vma);                    /* kref_get, ref → 2 */\n   remap_vmalloc_range_partial() walks PTEs without any lock.\n\nA concurrent DESTROY_CQ ioctl on another CPU calls:\n\n    kref_put(&q->ip->ref, rxe_mmap_release)   /* ref 1→0 */\n    vfree(ip->obj)   /* clears vmalloc PTEs mid-walk */\n    kfree(ip)        /* frees rxe_mmap_info */\n\nThis yields:\n\n   1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the\n   per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert\n\n   2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears\n   it. User VMA holds a PTE to a free'd page which might eventually get\n   reallocated later by vmalloc which allows the attacker to get a clean\n   page-level UAF.\n\n   It is worth noting that even though a page-level UAF is possible given\n   the strong primitive, it is statistically very difficult to achieve\n   given the very short time window (after the last insert_page and before\n   the kref_get).\n\nThe call trace are as below:\n\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n  CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:validate_page_before_insert+0x32/0x300\n  Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5\n  RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202\n  RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\n  RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008\n  RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00\n  R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20\n  FS:  00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0\n  Call Trace:\n   <TASK>\n   insert_page+0x8f/0x190\n   ? __pfx_insert_page+0x10/0x10\n   ? kasan_save_alloc_info+0x38/0x60\n   vm_insert_page+0x2e7/0x400\n   remap_vmalloc_range_partial+0x212/0x3e0\n   remap_vmalloc_range+0x6e/0xb0\n   ? __kasan_check_write+0x14/0x30\n   rxe_mmap+0x2e9/0x5d0\n   ib_uverbs_mmap+0x1ad/0x2c0\n   __mmap_region+0x12c2/0x2ad0\n   ? __pfx___mmap_region+0x10/0x10\n   ? __sanitizer_cov_trace_switch+0x58/0xb0\n   ? mas_prev_slot+0x360/0x39c0\n   ? __sanitizer_cov_trace_switch+0x58/0xb0\n   ? mas_next_slot+0x1e5b/0x2f40\n   ? __sanitizer_cov_trace_cmp8+0x18/0x30\n   ? unmapped_area_topdown+0x4dd/0x610\n   ? kfree+0x1b1/0x440\n   ? free_cpumask_var+0x16/0x30\n   ? __kasan_slab_free+0x7d/0xa0\n   ? __sanitizer_cov_trace_cmp8+0x18/0x30\n   mmap_region+0x2e6/0x3c0\n   do_mmap+0xa3e/0x12a0\n   ? __pfx_do_mmap+0x10/0x10\n   ? __kasan_check_write+0x14/0x30\n   ? down_write_killable+0xba/0x160\n   ? __pfx_down_write_killable+0x10/0x10\n   ? __sanitizer_cov_trace_cmp4+0x16/0x30\n   vm_mmap_pgoff+0x2d4/0x4a0\n   ? __pfx_vm_mmap_pgoff+0x10/0x10\n   ? fget+0x1bf/0x270\n   ksys_mmap_pgoff+0x40c/0x690\n   ? __sanitizer_cov_trace_const_cmp4+0x16/0x30\n   ? __pfx_ksys_mmap_pgoff+0x10/0x10\n   ? __kasan_check_write+0x14/0x30\n   ? _raw_spin_trylock+0xbb/0x130\n   ? __pfx__raw_spin_trylock+0x10/0x10\n   __x64_sys_mmap+0x135/0x1e0\n   x64_sys_c\n---truncated---(CVE-2026-64582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vce: fix integer overflow in image size\n\nFix a security vulnerability where malicious VCE command streams\nwith oversized dimensions (e.g. 65536×65536) cause 32-bit integer\noverflow, wrapping the calculated buffer size to 0. This bypasses\nvalidation and allows GPU firmware to perform out-of-bound memory\naccess.\n\nThe fix uses 64-bit arithmetic to detect overflow and rejects\ninvalid dimensions before they reach the hardware.\n\nV2: remove redundant check\nV3: modify max height value\nV4: remove size64\n\n(cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)(CVE-2026-68108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid\n\nsctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the\ncapacity limit for ep->auth_chunk_list, allowing it to hold up to\n20 chunk entries (param_hdr.length up to 24). However, the copy\ndestination asoc->c.auth_chunks in struct sctp_cookie is only\nSCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16\nchunks are added, sctp_association_init() memcpy overflows the\ndestination by up to 4 bytes.\n\nFix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching\nthe destination capacity.(CVE-2026-68320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: use wiphy work for socket owner autodisconnect\n\nnl80211_netlink_notify() walks the cfg80211 wireless device list when a\nNETLINK_GENERIC socket is released. If the socket owns a connection, the\nnotifier queues the embedded wdev->disconnect_wk work item.\n\nThat work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a\nNETLINK_URELEASE notifier that already observed conn_owner_nlportid can\nqueue it after that cancel returns. _cfg80211_unregister_wdev() then\nremoves the wdev from the list and waits for RCU readers, but\nsynchronize_net() does not drain work queued by such a reader.\n\nMake the autodisconnect work a wiphy_work instead. The callback already\nneeds the wiphy mutex, and wiphy_work runs under that mutex. This lets\nteardown cancel pending autodisconnect work while holding the mutex,\nwithout a cancel_work_sync() vs. worker locking concern.\n\nAlso cancel the wiphy work after list_del_rcu() and synchronize_net(). Any\nNETLINK_URELEASE notifier that had already reached the wdev list has then\neither queued the work and it is removed, or can no longer find the wdev.(CVE-2026-68404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: validate extension-frame layout before RX\n\nExtension frames only have the extension header at the regular 802.11\nheader offset. The generic RX path can still reach helpers and interface\ndispatch code that read regular header address fields before unsupported\nextension subtypes are dropped.\n\nmac80211 currently only handles S1G beacon extension frames. Drop other\nextension subtypes before they can reach regular-header RX processing.\nFor S1G beacons, linearize the SKB with the management-frame path and\nrequire the fixed S1G beacon header, including optional fixed fields\nindicated by frame control, before generic RX dispatch.\n\nRoute S1G beacons through the station/default-link RX path without\nregular-header station lookup. Avoid regular-header address reads in the\nmac80211 RX paths that process S1G extension beacons, including\naccept-frame, duplicate-detection, address-copy, and MLO\naddress-translation paths.\n\nAlso make ieee80211_get_bssid() length-safe before returning the S1G\nsource-address pointer.(CVE-2026-68470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm_early_create: fix freeing used table on dm_resume failure\n\nIf dm_resume fails, the kernel attempts to free table with\ndm_table_destroy, but the table was already instantiated with\ndm_swap_table. This commit skips the call to dm_table_destroy in this\ncase.(CVE-2026-72102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-ioctl: fix a possible overflow in list_version_get_info\n\nsizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the\noutput buffer - info->vers->version[0], info->vers->version[1],\ninfo->vers->version[2] and info->vers->next. This can cause buffer\noverflow.\n\nFix this buffer overflow by replacing "sizeof(tt->version)" with\n"sizeof(struct dm_target_versions)".(CVE-2026-72106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm thin metadata: fix metadata snapshot consistency on commit failure\n\n__reserve_metadata_snap() and __release_metadata_snap() modify the\nsuperblock's held_root directly in the block_manager's buffer. If the\nsubsequent metadata commit fails, the held_root gets flushed to disk\nthrough the abort_transaction path, resulting in inconsistent metadata.\n\nReproducer 1: __reserve_metadata_snap()\n\n1. Create a 2 MiB metadata device and make the region after the 14th\n   block inaccessible, to trigger metadata commit failure in the\n   subsequent reserve_metadata_snap operation. The 14th block will be\n   the shadow destination for the index block.\n\ndmsetup create tmeta --table "0 112 linear /dev/sdc 0\n112 3984 error"\n\n2. Create a 16 MiB thin-pool\n\ndmsetup create tdata --table "0 32768 zero"\ndd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1\ndmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \\\n/dev/mapper/tdata 128 0 1 skip_block_zeroing"\n\n3. Take a metadata snapshot to trigger metadata commit failure and\n   transaction abort. However, the held_root is written to disk,\n   breaking metadata consistency.\n\ndmsetup message tpool 0 "reserve_metadata_snap"\n\nthin_check v1.2.2 result:\n\nBad reference count for metadata block 6.  Expected 2, but space map contains 1.\nBad reference count for metadata block 7.  Expected 2, but space map contains 1.\nBad reference count for metadata block 13.  Expected 1, but space map contains 0.\n\nReproducer 2: __release_metadata_snap()\n\n1. Create a 2 MiB metadata device and make the region after the 16th\n   block inaccessible, to trigger metadata commit failure in the\n   subsequent release_metadata_snap operation. The 16th block will be\n   the shadow destination for the index block.\n\ndmsetup create tmeta --table "0 128 linear /dev/sdc 0\n128 3968 error"\n\n2. Create a 16 MiB thin-pool\n\ndmsetup create tdata --table "0 32768 zero"\ndd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1\ndmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \\\n/dev/mapper/tdata 128 0 1 skip_block_zeroing"\n\n3. Reserve then release the metadata snapshot, to trigger metadata\n   commit failure and transaction abort. The held_root gets removed\n   from the on-disk superblock, causing inconsistent metadata.\n\ndmsetup message tpool 0 "reserve_metadata_snap"\ndmsetup message tpool 0 "release_metadata_snap"\n\nthin_check v1.2.2 result:\n\nBad reference count for metadata block 6.  Expected 1, but space map contains 2.\nBad reference count for metadata block 7.  Expected 1, but space map contains 2.\n1 metadata blocks have leaked.\n\nFix by deferring the held_root update to commit time.\n\nAdditionally, move the existing-snapshot check in __reserve_metadata_snap\nbefore the shadow operation to avoid unnecessary work. In\n__release_metadata_snap, clear pmd->held_root before btree deletion so\npartial failure leaks blocks rather than leaving a stale reference, and\nunlock the snapshot block before decrementing its refcount.(CVE-2026-72108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: detect mapping-pairs LCN accumulator overflow\n\nThe NTFS mapping-pairs parser accumulates relative LCN deltas in a\nsigned integer.  A corrupted attribute can drive that addition past\nthe representable range.\n\nOne corrupt runlist shape sets the accumulated LCN to S64_MAX and\nthen adds a delta of 1 in the next mapping-pairs entry.\n\nSigned overflow is undefined and can turn an invalid runlist into a\ndifferent set of physical clusters.\n\nCheck the LCN addition for overflow before storing the next run.(CVE-2026-72200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()\n\njbd2_journal_initialize_fast_commit() validates journal capacity by\nchecking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS).\nBoth j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds\nj_last the subtraction wraps to a large value, bypassing the bounds\ncheck.\n\nThe resulting underflow corrupts j_last, j_fc_first, and j_free,\nleading to journal abort.\n\nFix by checking num_fc_blks against j_last before the subtraction,\nreturning -EFSCORRUPTED.(CVE-2026-72225)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()\n\npmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the\nvrm_version configured by the driver, while pmbus_reg2data_vid()\nalready switched on it. Any driver that selects a non-VR11 VID mode\nand exposes a regulator (or hwmon vout setter) sent dangerously\nwrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked\nfor 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the\nchip interprets as 1080 mV.\n\nMirror pmbus_reg2data_vid() so writes round-trip with reads.(CVE-2026-72397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs: fix lockless traversals of ->s_children\n\nHaving the parent directory locked protects entries from removal\nby another thread, but it does *not* protect cursors from being\nmoved around by lseek() - or freed, for that matter.(CVE-2026-74330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs_lookup(): don't leave ->s_dentry dangling on failure\n\nNormally ->s_dentry is cleared when dentry it's pointing to becomes\nnegative (on eviction, realistically).  However, that only happens\nif dentry gets to be positive in the first place; in case of inode\nallocation failure dentry never becomes positive, so ->d_iput()\nis not called at all.\n\nWe do part of what normally would've been done by configfs_d_iput()\n(dropping the reference to configfs_dirent) manually, but we do\nnot clear ->s_dentry there.  Sloppy as it is, it does not matter in\ncase of configfs_create_{dir,link}() - there configfs_dirent does\nnot survive dropping the sole reference to it.\n\nHowever, for configfs_lookup() it *does* survive, with a dangling\npointer to soon to be freed dentry sitting it its ->s_dentry.\n\nSubsequent getdents(2) in that directory will end up dereferencing\nthat pointer in order to pick the inode number.  Use after free...\n\nThis is the minimal fix; the right approach is to set the linkage\nbetween dentry and configfs_dirent only after we know that we have\nan inode, but that takes more surgery and the bug had been there\nsince 2006, so...(CVE-2026-74359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: fix error-path detection with md_cloned_bio()\n\nDetect the error path using md_cloned_bio() instead of relying\non r1_bio in raid1 or r10_bio->read_slot in raid10, which may be\nNULL or -1 after splitting and resubmitting a failed bio.\n\nAs a result, the error path may not be recognized and memory\nallocations can incorrectly use GFP_NOIO instead of\n(GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under\nmemory pressure.(CVE-2026-74374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work\n\nIf a UVC camera has an asynchronous control, uvc_status_stop may be\ncalled from async_ctrl.work:\n\nuvc_ctrl_status_event_work()\n    uvc_ctrl_status_event()\n        uvc_ctrl_clear_handle()\n\t    uvc_pm_put()\n\t        uvc_status_put()\n\t\t    uvc_status_stop()\n\t\t        cancel_work_sync()\n\nThis will cause a deadlock, since cancel_work_sync will wait for\nuvc_ctrl_status_event_work to complete before returning.\n\nFix this by returning early from uvc_status_stop if we are currently in\nthe work function. flush_status now remains false until uvc_status_start\nis called again, ensuring that uvc_ctrl_status_event_work won't resubmit\nthe URB.(CVE-2026-74437)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: bound DMA command body size against suffix pointer\n\nvmw_cmd_dma() locates the DMA suffix at\n\n\t(unsigned long) &cmd->body + header->size - sizeof(*suffix)\n\nwithout checking that header->size is large enough to contain both\ncmd->body and the suffix.  An undersized header makes the suffix\npointer underflow back into the previous command in the bounce\nbuffer.  The verifier later writes suffix->maximumOffset, clobbering\nverified fields of an already-relocated earlier command -- a TOCTOU\non the device-visible command stream that lets one command rewrite\nanother's GMR id, surface id, or other authenticated fields.\n\nReject the command if the body is too small for the suffix to fit.(CVE-2026-74443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: validate DRAW_PRIMITIVES header size before division\n\nvmw_cmd_draw() computes\n\n\tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl);\n\nwhere header->size is u32 and is taken straight from the user-supplied\ncommand stream.  When header->size is less than sizeof(cmd->body) the\nunsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum.\nAny user-controlled cmd->body.numVertexDecls then passes the bound and\nthe loop dereferences decl[i] far past the end of the kernel command\nbounce buffer, producing an out-of-bounds read of kernel memory.\n\nReject undersized headers up front.(CVE-2026-74444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (nct6775-core) Prevent access to unsupported weight registers\n\nSashiko reports:\n\nDuring initialization of the nct6116 chip, the driver sets data->pwm_num\nto 5. However, it assigns several NCT6106 register arrays (such as\nNCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and\nNCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP.\nThese arrays only contain 3 elements.\n\nIn nct6775_update_pwm(), the driver iterates up to data->pwm_num. If\ndata->has_pwm has bits 3 or 4 set (which is structurally possible for\nnct6116), the loop attempts to read elements at index 3 and 4 from these\n3-element arrays. This results in a global out-of-bounds read, which can\nbe caught by KASAN.\n\nFurthermore, the driver uses these garbage out-of-bounds values as\nhardware register addresses for subsequent read and write operations. This\nleads to invalid hardware register access, potentially causing hardware\nmisconfiguration or system crashes.\n\nThe underlying problem is that the chip does support up to five fan\ncontrol channels, but only the first three support weight control.\nFix the problem by extending the affected weight register arrays with\nzeroed fields. The driver uses zeroed register addresses to determine\nif a register is supported or not, and skips accesses for unsupported\nregisters.(CVE-2026-74549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Pin the 'struct nfs_server' during a FREE_STATEID call\n\nDan Aloni reports that he was able to hit a use-after-free bug if a\nFREE_STATEID operation gets delayed for whatever reason. Fix this by\nbumping the refcount of the 'struct nfs_server' object for the duration\nof the FREE_STATEID so it doesn't get cleaned up from underneath us\nwhile operations are still in flight.(CVE-2026-74730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cookie AUTH state before use\n\nWhen cookie authentication is disabled, COOKIE_ECHO restores fixed-size\nAUTH fields directly from peer-controlled cookie bytes.  A forged RANDOM\nlength, HMAC list, or CHUNKS list can then reach association consumers\nwith lengths or identifiers that were never validated against the local\nbacking arrays.\n\nA forged RANDOM length can cause out-of-bounds reads during key-vector\nconstruction.  A forged HMAC identifier also caused a 32-byte write past\na zero-length AUTH chunk, providing a primitive for a local privilege\nescalation chain.\n\nValidate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie\ntrust boundary before copying them into the association.  Reject invalid\ntypes, malformed lengths, unsupported HMAC identifiers, HMAC lists\nwithout SHA1, and forbidden chunk ids.(CVE-2026-74752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix UVD decode image min size calculation\n\nThis needs to use pitch instead of width. Also reject pitch\nover 4096 to avoid overflow.\n\n(cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)(CVE-2026-80540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: validate GEM_CREATE domain combinations\n\nAMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK,\nbut did not validate domain combinations. Userspace could combine\nCPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making\namdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and\nhit BUG_ON().\n\nAllow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/\nVRAM domains to be specified one at a time. Return -EINVAL for invalid\ncombinations in amdgpu_gem_create_ioctl().\n\nv2: Rename helper from amdgpu_gem_domain_valid() to\n    amdgpu_gem_are_domains_valid() (Christian)\n\n(cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)(CVE-2026-80541)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F54 report size to the allocated buffer\n\nrmi_f54_work() reads a diagnostics report from the device into\nf54->report_data, sizing the transfer with rmi_f54_get_report_size():\n\n\treport_size = rmi_f54_get_report_size(f54);\n\t...\n\tfor (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {\n\t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i);\n\t\t...\n\t\trmi_read_block(.., f54->report_data + i, size);\n\t}\n\nreport_data is allocated once at probe from F54's own electrode counts\n(array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))),\nbut rmi_f54_get_report_size() computes the size from\ndrv_data->num_*_electrodes when those are set, i.e. from the F55\nfunction's electrode counts. Both counts come straight from device\nqueries (F54 and F55 each report up to 255 electrodes) and nothing\nconstrains the F55 counts to the F54 ones.\n\nA malicious or malfunctioning RMI4 device that reports larger F55\nelectrode counts than its F54 counts makes report_size exceed the\nallocation, so the read loop writes past report_data (and the V4L2\ndequeue memcpy() then reads past it). On conforming hardware the F55\nconfigured electrodes are a subset of the F54 physical electrodes, so\nreport_size never exceeds the buffer and well-behaved devices are\nunaffected.\n\nRecord the allocation size and reject a report that does not fit,\nmirroring the existing zero-size check.(CVE-2026-80569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - zero report size on F54 work error\n\nIn rmi_f54_work(), if an error occurs during report request or command\nverification, the code jumped directly to the 'error' label, bypassing\nthe 'abort' label where f54->report_size was normally zeroed out.\n\nThis left f54->report_size containing its previous successful payload\nsize. If a user then altered the V4L2 format to a smaller size, and a\nsubsequent run failed, rmi_f54_buffer_queue() would copy the stale,\nlarger payload size into the shrunken V4L2 buffer, causing a heap\nbuffer overflow.\n\nFix this by merging the 'abort' and 'error' labels into a single 'out'\nexit path, and ensuring that f54->report_size is always set to 0 on\nfailure by checking for error and zeroing the local report_size first.(CVE-2026-80570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller\n\nmtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq\ncookie), but mtk_poll_controller incorrectly passed the net_device *.\nCalling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled\nwould then crash.(CVE-2026-80694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: transport: j1939_session_fresh_new(): initialize receive buffer\n\nZero the allocated buffer in j1939_session_fresh_new() to ensure it\ncontains no residual data.\n\nWhile there is a potential performance impact if users allocate maximum\nsized ETP buffers, most real-world use cases are not noticeably affected\nsince the maximum known buffer size is typically around 65K.\n\n[mkl: add Message-ID](CVE-2026-80707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate Adaptation Indication parameter length\n\nThe Adaptation Layer Indication parameter contains a fixed 32-bit\nAdaptation Code Point after its parameter header. However,\nsctp_verify_param() accepts a header-only parameter because the generic\nparameter walker only requires the header to be present.\n\nsctp_process_param() then reads adaptation_ind beyond the declared\nparameter. When the malformed parameter is last in an INIT, the read\nstarts at the receive skb tail, and the value is copied into the state\ncookie returned in the INIT ACK. This may disclose four receive-buffer\ntail bytes.\n\nRequire the declared parameter length to match the fixed structure size\nand abort the association through the existing invalid parameter length\npath otherwise.(CVE-2026-80717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page\n\nExplicitly clear role.invalid when deriving a child shadow page's role from\nits parent to harden against bugs elsewhere in KVM, as violating KVM's\ninvariant that invalid pages are NOT on the list of active MMU pages leads\nto use-after-free due to __kvm_mmu_prepare_zap_page() using list_add()\ninstead of list_move() when processing an invalid shadow page, i.e. makes a\nbad situation far worse.\n\nYell loudly if the parent is invalid, as it means KVM has missed a validity\ncheck, i.e. KVM is attempting to map memory using an invalid/obsolete root,\nbut continue on as the child is otherwise still a valid shadow page.\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]\n  Write of size 8 at addr ff11000153dd1368 by task repro/853\n\n  CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x4b/0x70\n   print_report+0x153/0x49c\n   kasan_report+0xbc/0xf0\n   __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]\n   mmu_alloc_root+0x141/0x320 [kvm]\n   kvm_mmu_load+0x612/0x20f0 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm]\n   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n   __x64_sys_ioctl+0x131/0x1b0\n   do_syscall_64+0x67/0x5f0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n\n  Allocated by task 853:\n   kasan_save_stack+0x20/0x40\n   kasan_save_track+0x14/0x30\n   __kasan_slab_alloc+0x5f/0x70\n   kmem_cache_alloc_noprof+0xfe/0x2e0\n   __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm]\n   paging64_page_fault+0x318/0x1e30 [kvm]\n   kvm_mmu_do_page_fault+0x21d/0x630 [kvm]\n   kvm_mmu_page_fault+0x18c/0x17b0 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm]\n   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n   __x64_sys_ioctl+0x131/0x1b0\n   do_syscall_64+0x67/0x5f0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n  Freed by task 853:\n   kasan_save_stack+0x20/0x40\n   kasan_save_track+0x14/0x30\n   kasan_save_free_info+0x3b/0x60\n   __kasan_slab_free+0x43/0x70\n   kmem_cache_free+0xe2/0x400\n   kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm]\n   kvm_mmu_free_roots+0x283/0x560 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm]\n   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n   __x64_sys_ioctl+0x131/0x1b0\n   do_syscall_64+0x67/0x5f0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2026-80726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: amba-pl011: synchronize DMA teardown\n\ndmaengine_terminate_all() does not wait for a running callback, so the TX\ncallback can still touch the TX buffer after it is freed. The RX poll\ntimer reads the RX buffers without the port lock.\n\nSwitch to dmaengine_terminate_sync() and delete the RX timer before\nfreeing the buffers.(CVE-2026-80737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: do overflow check for sb->bblog_shift in super_1_load()\n\nIn super_1_load(), sb->bblog_shift is an __u8 type value loaded from on-\ndisk superblock. It is used for badblocks API badblocks_set() by the\nfollowing sequence,\n\n 1930   rdev->badblocks.shift = sb->bblog_shift;\n 1931   for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) {\n 1932           u64 bb = le64_to_cpu(*bbp);\n 1933           int count = bb & (0x3ff);\n 1934           u64 sector = bb >> 10;\n 1935           sector <<= sb->bblog_shift;\n 1936           count <<= sb->bblog_shift;\n 1937           if (bb + 1 == 0)\n 1938                   break;\n 1939           if (!badblocks_set(&rdev->badblocks, sector, count, 1))\n 1940                   return -EINVAL;\n 1941   }\n\nbb->bblog_shit is in range of 0-255, variable sector is 64bit width, for\nan invalid bb->bblog_shit, it is possible to make sector be overflowed\nby the following calculation,\n 1935           sector <<= sb->bblog_shift;\nThen in turn when call badblocks_set() at line 1939 with the invalid\nrdev->badblocks.shift set at line 1930, may result an overflow inside\n_badblocks_clear() in block/badblocks.c.\n\nAlthough there are many places to call badblocks APIs, the non-zero\nshift value is only used in super_1_load(), other places always use 0 as\nthe shift value. Therefore it is unnecessary to do a general shift value\noverflow check inside badblock API, and just check here as the caller.\n\nThis may avoid unnecessary check, make the badblocks API code more simple\nand elegant.(CVE-2026-89557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes\n\nata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the\nUNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command.  The TRIM\ndescriptor is built by ata_format_dsm_trim_descr() into the 2048-byte\nata_scsi_rbuf staging buffer, and the number of bytes copied is compared\nagainst the logical sector size by the caller:\n\n\tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block);\n\tif (size != len)\t\t/* len == sdp->sector_size */\n\t\tgoto invalid_param_len;\n\nata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE\n(2048).  On a device whose logical sector size exceeds that (e.g. a 4Kn\ndevice, where sector_size == 4096) the function can never return more than\n2048, while the caller expects it to return sector_size.  The comparison\ntherefore always fails, so every TRIM is rejected with "Parameter list\nlength error" and WARN_ON() splats on each attempt.  TRIM / discard is\nthus completely broken on such devices.\n\nThe descriptor was incorrectly sized from the logical sector size.  A DSM\nTRIM payload is a list of 512-byte pages, each holding up to\nATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical\nsector size.  The Block Limits VPD page already advertises a single such\npage as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical\nblocks), so the block layer never sends a request that needs more than one\npage.\n\nEmit exactly one 512-byte page, independent of the logical sector size,\nand transfer only that page (COUNT == 1).  For a 512-byte-sector device\nthis is unchanged; devices with larger logical sectors now work instead of\nfailing every TRIM.(CVE-2026-89586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\necryptfs: pass packet set buffer size to parser\n\necryptfs_parse_packet_set() receives a pointer into the file header, but\nit calculates the remaining packet buffer size from PAGE_SIZE - 8.  For\nversion 1 headers the packet set starts later in the header, so this can\noverstate the available buffer.\n\nPass the actual packet set buffer length from the caller and calculate\nper-packet limits from the remaining bytes in that buffer.  Recompute the\nremaining length after consuming a tag 3 packet before parsing the\nfollowing tag 11 packet.(CVE-2026-89608)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: reject a tree connect response whose byte count is too small\n\nCIFSTCon() bounds its strnlen() over the byte area with the server's\nByteCount minus two, which for ByteCount 0 or 1 goes negative as an int\nand converts to a huge size_t.  The later subtraction wraps the __u16\nbytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of\nup to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the\nslab object, and the bytes reach userspace through tcon->nativeFileSystem\nin /proc/fs/cifs/DebugData.\n\nReject a byte area too small for what the parser consumes.  Two bytes is\nthe least it can consume, and no conformant response carries fewer.  The\nnew trace point is the 129th smb_eio_trace entry, which __mode(byte)\ncannot represent, so the attribute goes with it.(CVE-2026-89631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2()\n\ncoalesce_t2() computes data pointers directly from server-supplied\nDataOffset fields with no validation against buffer bounds:\n\n  data_area_of_tgt = (char *)&pSMBt->hdr.Protocol +\n                     get_unaligned_le16(&pSMBt->t2_rsp.DataOffset);\n  data_area_of_src = (char *)&pSMBs->hdr.Protocol +\n                     get_unaligned_le16(&pSMBs->t2_rsp.DataOffset);\n  data_area_of_tgt += total_in_tgt;\n  ...\n  memcpy(data_area_of_tgt, data_area_of_src, total_in_src);\n\nA small DataOffset can push a pointer below the actual byte area,\noverwriting header fields; a large one can push it past the buffer\nend, causing out-of-bounds heap reads (source) or writes (target).\nThe BCC overflow guard does not prevent this: BCC reflects how much\ndata is present, while DataOffset controls where in the buffer it\nstarts.\n\nThe "validate target area" comment present since the function was\nfirst written in 2005 was a placeholder that was never implemented.\n\nAdd lower- and upper-bound checks for both data pointers before the\nmemcpy, and before any target header fields are modified.(CVE-2026-89633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2\n\nWhen a valid primary TRANSACT2 response has been received (mid->resp_buf\nset, mid->multiRsp true) and a subsequent secondary response causes\ncifs_check_trans2() to return false -- either because the SMB header is\ninvalid (malformed != 0) or because check2ndT2() rejects the PDU --\nhandle_mid() overwrites mid->resp_buf with the new buffer (leaking the\nprimary buffer) and, because mid->multiRsp is set, skips the\nserver->smallbuf/bigbuf NULL-out.  When the user thread frees\nmid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the\ndemux thread reuses it for the next packet, resulting in a use-after-free.\n\nCombine both early-exit conditions and, when mid->multiRsp is already\nset, abort the pending transaction inline: set multiEnd, call\ndequeue_mid() with malformed=true, and return true so handle_mid() exits\nwithout touching mid->resp_buf or the server buffer pointers.(CVE-2026-89637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound xattr value length in __build_xattrs()\n\n__build_xattrs() decodes the MDS-supplied xattr blob one attribute at a\ntime. For each attribute it reads a 32-bit name length, advances past the\nname bytes, reads a 32-bit value length, records the value pointer, and\nadvances past the value bytes. The two length fields are read with\nceph_decode_32_safe(), but the value bytes themselves are advanced over\nwith a bare "p += len" and no ceph_decode_need() check that "len" bytes\nremain in the blob.\n\nFor every attribute except the last, the next iteration's\nceph_decode_32_safe() on the following name length implicitly verifies\nthat the previous value did not run past the blob end. The final\nattribute has no successor, so its decoded value length is never checked\nagainst the blob bounds. A malicious or compromised metadata server can\nset the last attribute's value length larger than the bytes actually\npresent in the blob.\n\nThe blob is a dedicated kvmalloc() allocation sized to the wire length\n(ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the\noversized length in xattr->val_len verbatim, and a later getxattr(2) runs\nmemcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer,\ncopying bytes past the end of the allocation back to user space.\n\nImpact: a malicious metadata server discloses adjacent kernel heap bytes\nto a local user via getxattr(2) on a CephFS file. Add the missing\nceph_decode_need() so an out-of-bounds value length on the final\nattribute fails the decode and returns -EIO instead of being stored.(CVE-2026-89649)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound num_export_targets array for mds info v2/v3\n\nceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from\neach per-mds info record and advances the decode cursor by\nnum_export_targets * sizeof(u32) without first checking that many bytes\nremain. The only upper-bound check that catches a runaway cursor\n(*p > info_end) is gated on info_v >= 4, because info_end is left NULL\nfor info_v 2 and 3. When the monitor sends an MDS map whose per-mds\ninfo version is 2 or 3 with an oversized num_export_targets, the cursor\nmoves past the message front buffer and the later export-targets loop\ncalls the unchecked ceph_decode_32() on out-of-bounds memory.\n\nA kernel client processes CEPH_MSG_MDS_MAP from its monitor session\n(net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to\nceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and\ncalls ceph_mdsmap_decode()). A malicious or compromised monitor, or an\non-path attacker on an unsigned/unencrypted messenger session, can\ntherefore drive an out-of-bounds read in the client kernel; on x86_64\nwith KASAN it is reported as a slab-out-of-bounds read in\nceph_mdsmap_decode(). The decoded values land in the internal\ninfo->export_targets[] array, so the consequence is a kernel\nout-of-bounds read, not an information leak to the attacker.\n\nImpact: a malicious or compromised Ceph monitor sending an MDS map with\na per-mds info version of 2 or 3 and an oversized num_export_targets\nfield triggers an out-of-bounds read in the CephFS client kernel.\n\nAdd a ceph_decode_need() for the export-targets array before advancing\nthe cursor, so the bound is enforced for every info_v >= 2, not only\ninfo_v >= 4. This mirrors the count-then-need idiom already used for\nm_data_pg_pools later in the same function.\n\nCompute the export-targets byte count with size_mul() and reuse that\nchecked length when advancing the cursor, so the attacker-controlled\nnum_export_targets multiplication fails closed on overflow rather than\nrelying on the later kcalloc() guard.(CVE-2026-89650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound copied dentry name length in NFS export get_name\n\nceph_get_name() copies the MDS-supplied name into the caller's\nNAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len)\nand then writes name[rinfo->dname_len] = 0, without checking dname_len\nagainst NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply\nwith dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies\nrde->name / rde->name_len the same unchecked way.\n\nImpact: a malicious or compromised Ceph MDS overflows the NAME_MAX name\nbuffer in a client's NFS-export get_name path, a slab out-of-bounds write\nreported by KASAN. Reachable when a CephFS mount is re-exported over NFS.\n\nAdd ceph_export_copy_name(), which rejects lengths above NAME_MAX with\n-ENAMETOOLONG before the copy, and use it in both ceph_get_name() and\n__get_snap_name().(CVE-2026-89652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock\n\nlist_for_each_entry() iterates ci->i_cap_flush_list but drops\ni_ceph_lock to send cap messages.  During the unlock window,\nhandle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries\nwith tid <= flush_tid from the list, release i_ceph_lock, and free\nthem via ceph_free_cap_flush() outside any lock.  When the original\nthread reacquires i_ceph_lock and the for-loop macro advances via\ncf = list_next_entry(cf, i_list), it dereferences cf->i_list.next\non freed memory.\n\nThe race timeline:\n\n  __kick_flushing_caps()              handle_cap_flush_ack()\n  -----------------------             -----------------------\n  holds i_ceph_lock        <---\n  iterates to cf (tid=10)\n  prepares FLUSH message\n  drops i_ceph_lock        <---\n  __send_cap() ── FLUSH(tid=10)\n\t                              MDS sends FLUSH_ACK(tid=10)\n                           --->       acquires i_ceph_lock\n                                      cf->tid(10) <= flush_tid(10),\n                                      detaches cf from i_cap_flush_list\n                                      drops i_ceph_lock\n                                      ceph_free_cap_flush(cf) <- frees it!\n  acquires i_ceph_lock     <---\n  for-loop advances:\n    cf = list_next_entry(cf, i_list)\n      -- UAF on freed cf->i_list.next\n\nThe cf was just sent by __kick_flushing_caps itself via __send_cap().\nThe MDS may respond with FLUSH_ACK quickly enough that\nhandle_cap_flush_ack() frees cf before __kick_flushing_caps can\nfinish the iteration.\n\nFix by converting to a manual while loop: save the next pointer\nunder i_ceph_lock before dropping it, then use the saved pointer\nafter reacquiring, so the potentially-freed cf is never accessed again.(CVE-2026-89655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read\n\nIn qla2x00_status_entry(), the FWI2 status path advances sense_data and\nshrinks par_sense_len by rsp_info_len:\n\n\tif (IS_FWI2_CAPABLE(ha)) {\n\t\tsense_data += rsp_info_len;\n\t\tpar_sense_len -= rsp_info_len;\n\t}\n\nrsp_info_len is a 32-bit value taken directly from the target's FCP\nresponse (sf.rsp_data_len), while par_sense_len is the IOCB data area\nsize (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target\nreporting an rsp_info_len larger than par_sense_len makes the unsigned\nsubtraction underflow to a huge value and advances sense_data out of\nbounds.\n\nThe underflowed par_sense_len then defeats the cap in\nqla2x00_handle_sense():\n\n\tif (sense_len > par_sense_len)\n\t\tsense_len = par_sense_len;\n\tmemcpy(cp->sense_buffer, sense_data, sense_len);\n\nso the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the\nout-of-bounds sense_data pointer, leaking adjacent response-ring/heap\nmemory into the command's sense buffer.\n\nClamp rsp_info_len to par_sense_len before the subtraction so\npar_sense_len can never underflow and sense_data stays within the IOCB\ndata area. The fix sits before the comp_status switch, covering both\nqla2x00_handle_sense() call sites.(CVE-2026-89846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Avoid double completion in async IOCB timeout\n\nqla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When\nqla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the\nSRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then\ncall sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking\nwhether the SRB was actually found and removed.\n\nIf the response ISR completes the same handle first, it removes the SRB\nunder qp_lock_ptr and runs sp->done() -> complete(sp->comp). The\nsubmitter qla24xx_control_vp() wakes from wait_for_completion(), clears\nsp->comp, drops its reference and returns, reclaiming the on-stack\ncompletion. The timer reference keeps the SRB alive across the timeout\nhandler, but not the submitter's stack. The timeout then issues a second\nsp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp)\ncomplete(sp->comp)"; with the pointer loaded before the submitter's NULL\nstore, complete() writes into the freed stack frame, a use-after-free.\n\nTrack whether this path removed the SRB from outstanding_cmds and only\ncall sp->done() when it did, so the command is completed exactly once by\nwhichever path owns it. This mirrors the sp_found guard already used in\nqla24xx_abort_iocb_timeout().(CVE-2026-89847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak\n\nqla2x00_do_dport_diagnostics() allocates the qla_dport_diag response\nbuffer with kmalloc_obj() (non-zeroing) and, on success, copies the full\nsizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound\nsg_copy_to_buffer() only fills as many bytes as the user request payload\nprovides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The\noptions and unused[] fields are therefore copied out uninitialized,\nleaking kernel heap contents to user space.\n\nAllocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().(CVE-2026-89859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Take trace_array reference when opening options file\n\nThe options files do not take the trace_array reference for the options\nthey represent. This could cause a use-after-free kernel crash if one of\nthese files is opened by one task and another task removes the instance\nthat the option is for. Because it doesn't take a reference upon opening,\nit will not stop the removal which will free the options descriptor that\nis being used.\n\nAs the options are somewhat dynamic in their creation at boot up, each\nfile represents a flag in the trace_array. The trace_array has an array of\nindexes to represent each of these flags that is stored in the\ntrace_flags_index array. The address of the index array element is used to\npass to the inode->i_private pointer. Then that element is read which\nholds the index (which represents the flag) and then the index is used to\ncalculate the trace_array descriptor from its trace_flags_index array.\n\nOne issue is that the index element can not be referenced until the\ntrace_array's reference is taken. To handle this, create a new helper\nfunction called: trace_array_options_get() that will iterate all the\nexisting trace_arrays in the ftrace_trace_arrays list (under the\ntrace_types_lock), and compare the passed in address of the index element\nwith the entire array of the trace_array's trace_flags_index array.\nIf it matches, then up the corresponding trace_array's reference and\nreturn.(CVE-2026-90013)","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-334.0.0.235.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","perf-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-334.0.0.235.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","perf-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4039"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56531"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56614"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31548"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43303"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52929"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52954"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53242"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63916"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64048"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64449"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64458"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64582"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68108"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68320"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68404"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68470"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72102"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72106"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72108"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72200"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72225"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74330"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74359"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74437"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74443"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74444"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74549"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74730"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80540"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80541"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80569"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80570"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80694"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80707"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80717"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89557"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89586"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89608"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89631"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89633"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89649"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89650"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89846"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90013"}],"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"}}