{"schema_version":"1.7.2","id":"OESA-2026-3453","modified":"2026-08-20T09:59:07Z","published":"2026-08-20T09:59:07Z","upstream":["CVE-2026-23336","CVE-2026-43062","CVE-2026-45893","CVE-2026-46070","CVE-2026-46113","CVE-2026-53392","CVE-2026-53402","CVE-2026-63800","CVE-2026-63860","CVE-2026-63899","CVE-2026-63901","CVE-2026-63924","CVE-2026-63947","CVE-2026-63984","CVE-2026-63992","CVE-2026-63994","CVE-2026-64002","CVE-2026-64276","CVE-2026-64279","CVE-2026-64296","CVE-2026-64304","CVE-2026-64333","CVE-2026-64340","CVE-2026-64371","CVE-2026-64388","CVE-2026-64406","CVE-2026-64550","CVE-2026-64564","CVE-2026-68130","CVE-2026-68159"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: cancel rfkill_block work in wiphy_unregister()\n\nThere is a use-after-free error in cfg80211_shutdown_all_interfaces found\nby syzkaller:\n\nBUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220\nRead of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326\nCPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: events cfg80211_rfkill_block_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x116/0x1f0\n print_report+0xcd/0x630\n kasan_report+0xe0/0x110\n cfg80211_shutdown_all_interfaces+0x213/0x220\n cfg80211_rfkill_block_work+0x1e/0x30\n process_one_work+0x9cf/0x1b70\n worker_thread+0x6c8/0xf10\n kthread+0x3c5/0x780\n ret_from_fork+0x56d/0x700\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nThe problem arises due to the rfkill_block work is not cancelled when wiphy\nis being unregistered. In order to fix the issue cancel the corresponding\nwork in wiphy_unregister().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2026-23336)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()\n\nl2cap_ecred_reconf_rsp() casts the incoming data to struct\nl2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with\nresult at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes\nwith result at offset 0).\n\nThis causes two problems:\n\n - The sizeof(*rsp) length check requires 8 bytes instead of the\n   correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected\n   with -EPROTO.\n\n - rsp->result reads from offset 6 instead of offset 0, returning\n   wrong data when the packet is large enough to pass the check.\n\nFix by using the correct type.  Also pass the already byte-swapped\nresult variable to BT_DBG instead of the raw __le16 field.(CVE-2026-43062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix & Optimize table creation from possibly unaligned memory\n\nSource blob may come from userspace and might be unaligned.\nTry to optize the copying process by avoiding unaligned memory accesses.\n\n- Added Fixes tag\n- Added "Fix &" to description as this doesn't just optimize but fixes\n        a potential unaligned memory access\n[jj: remove duplicate word "convert" in comment trigger checkpatch warning](CVE-2026-45893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: validate payload size before accessing journal metadata\n\nr5c_recovery_analyze_meta_block() and\nr5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a\njournal metadata block using on-disk payload size fields without\nvalidating them against the remaining space in the metadata block.\n\nA corrupted journal contains payload sizes extending beyond the PAGE_SIZE\nboundary can cause out-of-bounds reads when accessing payload fields or\ncomputing offsets.\n\nAdd bounds validation for each payload type to ensure the full payload\nfits within meta_size before processing.(CVE-2026-46070)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix shadow paging use-after-free due to unexpected GFN\n\nThe shadow MMU computes GFNs for direct shadow pages using sp->gfn plus\nthe SPTE index. This assumption breaks for shadow paging if the guest\npage tables are modified between VM entries (similar to commit\naad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even\nwhen creating an MMIO SPTE", 2026-03-27).  The flow is as follows:\n\n- a PDE is installed for a 2MB mapping, and a page in that area is\n  accessed.  KVM creates a kvm_mmu_page consisting of 512 4KB pages;\n  the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because\n  the guest's mapping is a huge page (and thus contiguous).\n\n- the PDE mapping is changed from outside the guest.\n\n- the guest accesses another page in the same 2MB area.  KVM installs\n  a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN\n  (i.e. based on the new mapping, as changed in the previous step) but\n  that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore\n  the rmap entry cannot be found and removed when the kvm_mmu_page\n  is zapped.\n\n- the memslot that covers the first 2MB mapping is deleted, and the\n  kvm_mmu_page for the now-invalid GPA is zapped.  However, rmap_remove()\n  only looks at the [sp->gfn, sp->gfn + 511] range established in step 1,\n  and fails to find the rmap entry that was recorded by step 3.\n\n- any operation that causes an rmap walk for the same page accessed\n  by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page.\n  This includes dirty logging or MMU notifier invalidations (e.g., from\n  MADV_DONTNEED).\n\nThe underlying issue is that KVM's walking of shadow PTEs assumes that\nif a SPTE is present when KVM wants to install a non-leaf SPTE, then the\nexisting kvm_mmu_page must be for the correct gfn.  Because the only way\nfor the gfn to be wrong is if KVM messed up and failed to zap a SPTE...\nwhich shouldn't happen, but *actually* only happens in response to a\nguest write.\n\nThat bug dates back literally forever, as even the first version of KVM\nassumes that the GFN matches and walks into the "wrong" shadow page.\nHowever, that was only an imprecision until 2032a93d66fa ("KVM: MMU:\nDon't allocate gfns page for direct mmu pages") came along.\n\nFix it by checking for a target gfn mismatch and zapping the existing\nSPTE.  That way the old SP and rmap entries are gone, KVM installs\nthe rmap in the right location, and everyone is happy.(CVE-2026-46113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/flexfiles: reject zero filehandle version count\n\nff_layout_alloc_lseg() decodes the filehandle-version array count\nfrom the flexfiles layout body. The value is used as the count for\nkzalloc_objs(), and the current code only rejects NULL.\n\nA zero count yields ZERO_SIZE_PTR, which can be stored in\ndss_info->fh_versions even though later flexfiles paths assume that at\nleast one filehandle version exists.\n\nReject fh_count == 0 before the allocation, matching the existing zero\nversion_count validation in the flexfiles GETDEVICEINFO parser.\n\nA QEMU/KASAN run with a malformed flexfiles layout hit:\n\n  KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n  RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750\n  ff_layout_encode_layoutreturn+0x683/0x970\n  nfs4_xdr_enc_layoutreturn+0x278/0x3a0\n  Kernel panic - not syncing: Fatal exception\n\nThe patched kernel rejects the malformed layout without KASAN/oops/panic,\nand a valid fh_count=1 regression still opens, reads, and unmounts cleanly.(CVE-2026-53392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()\n\nWhen fbcon_do_set_font() fails (e.g., due to a memory allocation failure\ninside vc_resize() under heavy memory pressure), it jumps to the `err_out`\nlabel to roll back the console state. However, the current rollback logic\nforgets to restore the `hi_font` state, leading to a severe state machine\ncorruption.\n\nEarlier in the function, `set_vc_hi_font()` might be called to change\n`vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`\nsubsequently fails, the `err_out` path restores `vc_font.charcount`\nbut entirely skips rolling back the `vc_hi_font_mask` and the screen\nbuffer.\n\nThis mismatch leaves the terminal in a desynchronized state. Because\n`vc_hi_font_mask` remains set, the VT subsystem will still accept\ncharacter indices greater than 255 from userspace and write them to the\nscreen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will\nthen use these inflated indices to access the reverted, 256-character\nfont array, leading to a deterministic out-of-bounds read and potential\nkernel memory disclosure.\n\nFix this by adding the missing rollback logic for the `hi_font` mask\nand screen buffer in the error path.(CVE-2026-53402)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix use-after-free in pnfs_update_layout()\n\nWhen hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(),\nthe code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds,\npnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(),\nwhich still references 'lo'. This results in a use-after-free when the\ntracepoint accesses lo's fields.\n\nFix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).(CVE-2026-63800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Prefer NLA_NUL_STRING\n\nThese attributes are evaluated as c-string (passed to strcmp), but\nNLA_STRING doesn't check for the presence of a \\0 terminator.\n\nEither this needs to switch to nla_strcmp() and needs to adjust printf fmt\nspecifier to not use plain %s, or this needs to use NLA_NUL_STRING.\n\nAs the code has been this way for long time, it seems to me that userspace\ndoes include the terminating nul, even tough its not enforced so far, and\nthus NLA_NUL_STRING use is the simpler solution.(CVE-2026-63860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mxuport: fix memory corruption with small endpoint\n\nMake sure that the bulk-out endpoint max packet size is at least eight\nbytes to avoid user-controlled slab corruption should a malicious device\nreport a smaller size.(CVE-2026-63899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: digi_acceleport: fix memory corruption with small endpoints\n\nAdd the missing bulk-out buffer size sanity checks to avoid\nout-of-bounds memory accesses or slab corruption should a malicious\ndevice report smaller buffers than expected.(CVE-2026-63901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()\n\nipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers.\nLet's recompute nh pointer to make sure any change won't mess things up.(CVE-2026-63924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: fix missing length checks in hidp_input_report()\n\nhidp_input_report() reads keyboard and mouse payload data from an skb\nwithout first verifying that skb->len contains enough data.\n\nhidp_recv_intr_frame() pulls the 1-byte HIDP header before dispatching\nto hidp_input_report(). If a paired device sends a truncated packet,\nthe handler reads beyond the valid skb data, resulting in an\nout-of-bounds read of skb data. The OOB bytes may be interpreted as\nphantom key presses or spurious mouse movement.\n\nReplace the open-coded length tracking and pointer arithmetic with\nskb_pull_data() calls. skb_pull_data() returns NULL if the requested\nbytes are not present, eliminating the need for a manual size variable\nand the separate skb->len guard.(CVE-2026-63947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()\n\nipv6_rpl_srh_decompress() computes:\n\n    outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);\n\nhdrlen is __u8. For n >= 127 the result exceeds 255 and silently\ntruncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):\n\n    (128 * 16) >> 3 = 256, truncated to 0 as __u8\n\nThe caller in ipv6_rpl_srh_rcv() then places the compressed header\nat buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8,\nbut the decompressed region occupies buf[0..2055] (8-byte header\nplus 128 full addresses). The compressed header overlaps the\ndecompressed data, and ipv6_rpl_srh_compress() writes into this\noverlap, corrupting the routing header of the forwarded packet.\n\nThe existing guard at exthdrs.c:546 checks (n + 1) > 255, which\nprevents n+1 from overflowing unsigned char (the segments_left\nfield), but does not prevent the computed hdrlen from overflowing\n__u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not\nfit.\n\nTighten the bound to (n + 1) > 127. This caps n at 126, giving\nhdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed\nheader then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly\npast the decompressed region (buf[0..2039]). No overlap. 127\nsegments is well beyond any realistic RPL deployment.(CVE-2026-63984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: do not assume transport header in iptunnel_pmtud_check_icmp()\n\nIn some cases, iptunnel_pmtud_check_icmp() can be called while\nskb transport header is not set.\n\nThis triggers an out-of-bound access, because\n(typeof(skb->transport_header))~0U is 65535.\n\nAccess the icmp header based on IPv4 network header,\nafter making sure icmp->type is present in skb linear part.\n\nNote that iptunnel_pmtud_check_icmpv6()) is fine.(CVE-2026-63992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]()\n\nSashiko found that iptunnel_pmtud_build_icmp() and\niptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr()\nbefore an skb_cow() call which can reallocate skb->head.\n\nFix this possible UAF by initializing the local variables\nafter the skb_cow() call.\n\nRemove skb_reset_network_header() calls which were not needed.(CVE-2026-63994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()\n\nipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports\ntoo soon.\n\nOnly after unregister_net_sysctl_table() we can be sure no threads can possibly\nuse the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.(CVE-2026-64002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count\n\nrmi_f30_map_gpios() allocates gpioled_key_map with\nmin(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but\nrmi_f30_attention() iterates the full f30->gpioled_count (device query\nregister, range 0..31) and dereferences gpioled_key_map[i], and\ninput->keycodemax is set to the full gpioled_count while input->keycode\npoints at the 6-entry allocation.\n\nA device that reports gpioled_count > 6 with GPIO support enabled\ntherefore causes an out-of-bounds read on the attention interrupt and\nout-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls,\nwhich bound the index only against keycodemax. This is the same defect\nas the F3A handler, which was copied from F30.\n\nSize the keymap for the full gpioled_count; the mapping loop still\nassigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.(CVE-2026-64276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: core: fix adapter deregistration race\n\nAdapters can be looked up by their id using i2c_get_adapter() which\ntakes a reference to the embedded struct device.\n\nRemove the adapter from the IDR before tearing it down during\nderegistration (and on registration failure) to make sure its resources\nare not accessed after having been freed (e.g. the device name).(CVE-2026-64279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: bound uniname advance in exfat_find_dir_entry()\n\nIn exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the\noutput pointer by a fixed amount while the loop guard only tracks the\naccumulated name length:\n\n\tif (++order == 2)\n\t\tuniname = p_uniname->name;\n\telse\n\t\tuniname += EXFAT_FILE_NAME_LEN;\n\tlen = exfat_extract_uni_name(ep, entry_uniname);\n\tname_len += len;\n\tunichar = *(uniname+len);\n\t*(uniname+len) = 0x0;\n\nuniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len\ngrows only by the actual extracted length, which is shorter when a name\nfragment contains an early NUL.  The only guard is\n`name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short\nname fragments lets uniname run far past the\np_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small,\ncausing an out-of-bounds read and write at *(uniname+len).\n\nThe sibling extractor exfat_get_uniname_from_ext_entry() already stops\non a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard\nadded in commit d42334578eba ("exfat: check if filename entries exceeds\nmax filename length")); exfat_find_dir_entry() never got the\nequivalent.  Track the per-entry write offset as a count and reject a\nfragment once the offset, or the offset plus the extracted length, would\nexceed MAX_NAME_LENGTH, before forming the output pointer.(CVE-2026-64296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - validate RSA CRT component lengths\n\nThe generic RSA key parser (rsa_helper.c) bounds each CRT component (p,\nq, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()\nallocates half-size DMA buffers (key_sz / 2) and right-aligns each\ncomponent with:\n\n    memcpy(dst + half_key_sz - len, src, len)\n\nWhen a CRT component is larger than half_key_sz the subtraction\nunderflows and memcpy writes past the DMA buffer, causing memory\ncorruption.\n\nAdd a len > half_key_sz check next to the existing !len check for each\nof the five CRT components so the driver falls back to the non-CRT path\ninstead of writing out of bounds.(CVE-2026-64304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: digi_acceleport: fix write buffer corruption\n\nThe digi_write_inb_command() is supposed to wait for the write urb to\nbecome available or return an error, but instead it updates the transfer\nbuffer and tries to resubmit the urb on timeout.\n\nTo make things worse, for commands like break control where no timeout\nis used, the driver would corrupt the urb immediately due to a broken\njiffies comparison (on 32-bit machines this takes five minutes of uptime\nto trigger due to INITIAL_JIFFIES).\n\nFix this by adding the missing return on timeout and waiting\nindefinitely when no timeout has been specified as intended.\n\nThis issue was (sort of) flagged by Sashiko when reviewing an unrelated\nchange to the driver.(CVE-2026-64333)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: legousbtower: fix use-after-free on disconnect race\n\nmutex_unlock() may access the mutex structure after releasing the lock\nand therefore cannot be used to manage lifetime of objects directly\n(unlike spinlocks and refcounts). [1][2]\n\nUse a kref to release the driver data to avoid use-after-free in\nmutex_unlock() when release() races with disconnect().\n\n[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is\n                   non-atomic")\n[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most\n                   other sleeping locks, can still use the lock object\n                   after it's unlocked")(CVE-2026-64340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: protect ptrace_may_access() with exec_update_lock (part 1)\n\nFix the easy cases where procfs currently calls ptrace_may_access() without\nexec_update_lock protection, where the fix is to simply add the extra lock\nor use mm_access():\n\n - do_task_stat(): grab exec_update_lock\n - proc_pid_wchan(): grab exec_update_lock\n - proc_map_files_lookup(): use mm_access() instead of get_task_mm()\n - proc_map_files_readdir(): use mm_access() instead of get_task_mm()\n - proc_ns_get_link(): grab exec_update_lock\n - proc_ns_readlink(): grab exec_update_lock(CVE-2026-64371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: fix chown/chgrp with SMB3 POSIX Extensions\n\nOwnership (chown) and group (chgrp) modifications were being ignored when\nmounting with SMB3 POSIX Extensions unless CIFS_MOUNT_CIFS_ACL or\nCIFS_MOUNT_MODE_FROM_SID were also explicitly set.\n\nFix this by checking for posix_extensions in cifs_setattr_nounix() when\nupdating UID and GID, ensuring that id_mode_to_cifs_acl() is called to map\nand set the ownership/group information on the server.(CVE-2026-64388)\n\nIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in bt_accept_dequeue(). bt_accept_get() takes a temporary reference before dropping the accept queue lock. bt_accept_dequeue() currently drops that reference before bt_accept_unlink(), leaving only the queue reference. bt_accept_unlink() drops the queue reference. The subsequent sock_hold() therefore accesses freed memory if it was the final reference, as observed by KASAN during listening L2CAP socket cleanup. Retain the temporary queue-walk reference through unlink and hand it to the caller on success. Drop it explicitly on the closed and not-yet-connected paths.(CVE-2026-64406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qualcomm: rmnet: validate MAP frame length before ingress parsing\n\nWhen ingress deaggregation is disabled, rmnet_map_ingress_handler() passes\nthe skb straight to __rmnet_map_ingress_handler(), skipping the length\nvalidation that rmnet_map_deaggregate() performs on the aggregated path.\nThe parser then dereferences the MAP header and csum header/trailer based on\nthe on-wire pkt_len without checking skb->len, so a short frame is read out\nof bounds:\n\n  BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet\n  Read of size 1 at addr ffff88801118ed00 by task exploit/147\n  Call Trace:\n   ...\n   rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413)\n   __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96)\n   rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129)\n   __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089)\n   netif_receive_skb (net/core/dev.c:6460)\n   tun_get_user (drivers/net/tun.c:1955)\n   tun_chr_write_iter (drivers/net/tun.c:2001)\n   vfs_write (fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)\n   do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n   ...\n\nFactor that validation out of rmnet_map_deaggregate() into\nrmnet_map_validate_packet_len() and run it on the no-aggregation path too.\nThe MAP header is bounds-checked first, since this path can receive a frame\nshorter than the header.(CVE-2026-64550)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the SCTP ASCONF processing. sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport. For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address, but nothing protects asconf->transport. A single ASCONF can carry [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source, causing the freed transport to be dereferenced, potentially leading to system crash or code execution.(CVE-2026-64564)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: defer destroy_previous_session() until after NTLM authentication\n\nIn ntlm_authenticate(), destroy_previous_session() is called using a\nuser pointer resolved from the client-supplied NTLM blob username field\nbefore the NTLMv2 response is validated. An authenticated attacker can\nset the NTLM blob username to match a victim account and set\nPreviousSessionId to the victim's session ID; destroy_previous_session()\ndestroys the victim's session while ksmbd_decode_ntlmssp_auth_blob()\nsubsequently rejects the request with -EPERM.\n\nMove destroy_previous_session() and the prev_id assignment to after\nksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user\nrather than the pre-authentication lookup result. This matches the\nordering already used by krb5_authenticate(), where\ndestroy_previous_session() is called only after\nksmbd_krb5_authenticate() returns success.(CVE-2026-68130)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE\n\n__decode_pg_temp() decodes an user-controlled length but only rejects\nvalues large enough to overflow the allocation; it does not bound it to\nCEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and\napply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size\non-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends\nan OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack\nout-of-bounds write.\n\nAn OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer\nentries at decode time. The bound is well below the old overflow threshold, so\nit also covers the allocation-size overflow the previous check guarded against.\n\n  BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds\n  Write of size 4 ... by task exploit\n   kasan_report (mm/kasan/report.c:595)\n   ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833)\n   calc_target (net/ceph/osd_client.c:1638)\n   __submit_request (net/ceph/osd_client.c:2394)\n   ceph_osdc_start_request (net/ceph/osd_client.c:2490)\n   ceph_osdc_call (net/ceph/osd_client.c:5164)\n   rbd_dev_image_probe (drivers/block/rbd.c:6899)\n   do_rbd_add (drivers/block/rbd.c:7138)\n   ...\n  kernel BUG at net/ceph/osdmap.c:2670!\n\n[ idryomov: do the same in __decode_pg_upmap_items() ](CVE-2026-68159)","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-329.0.0.230.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","perf-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-329.0.0.230.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-329.0.0.230.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","perf-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-329.0.0.230.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3453"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23336"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46070"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53392"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53402"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63800"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63860"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64276"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64279"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64304"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64333"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64340"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64371"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64406"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64550"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64564"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68130"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68159"}],"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"}}