{"schema_version":"1.7.2","id":"OESA-2026-2492","modified":"2026-05-29T13:34:20Z","published":"2026-05-29T13:34:20Z","upstream":["CVE-2022-50442","CVE-2022-50762","CVE-2023-54237","CVE-2025-40273","CVE-2025-68301","CVE-2026-31668","CVE-2026-31729","CVE-2026-43030","CVE-2026-43040","CVE-2026-43053","CVE-2026-43117","CVE-2026-43134","CVE-2026-43289","CVE-2026-43407","CVE-2026-43493"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate buffer length while parsing index\n\nindx_read is called when we have some NTFS directory operations that\nneed more information from the index buffers. This adds a sanity check\nto make sure the returned index buffer length is legit, or we may have\nsome out-of-bound memory accesses.\n\n[  560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320\n[  560.898321] Read of size 2 at addr ffff888009497238 by task exp/245\n[  560.898760]\n[  560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37\n[  560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[  560.900170] Call Trace:\n[  560.900407]  <TASK>\n[  560.900732]  dump_stack_lvl+0x49/0x63\n[  560.901108]  print_report.cold+0xf5/0x689\n[  560.901395]  ? hdr_find_e.isra.0+0x10c/0x320\n[  560.901716]  kasan_report+0xa7/0x130\n[  560.901950]  ? hdr_find_e.isra.0+0x10c/0x320\n[  560.902208]  __asan_load2+0x68/0x90\n[  560.902427]  hdr_find_e.isra.0+0x10c/0x320\n[  560.902846]  ? cmp_uints+0xe0/0xe0\n[  560.903363]  ? cmp_sdh+0x90/0x90\n[  560.903883]  ? ntfs_bread_run+0x190/0x190\n[  560.904196]  ? rwsem_down_read_slowpath+0x750/0x750\n[  560.904969]  ? ntfs_fix_post_read+0xe0/0x130\n[  560.905259]  ? __kasan_check_write+0x14/0x20\n[  560.905599]  ? up_read+0x1a/0x90\n[  560.905853]  ? indx_read+0x22c/0x380\n[  560.906096]  indx_find+0x2ef/0x470\n[  560.906352]  ? indx_find_buffer+0x2d0/0x2d0\n[  560.906692]  ? __kasan_kmalloc+0x88/0xb0\n[  560.906977]  dir_search_u+0x196/0x2f0\n[  560.907220]  ? ntfs_nls_to_utf16+0x450/0x450\n[  560.907464]  ? __kasan_check_write+0x14/0x20\n[  560.907747]  ? mutex_lock+0x8f/0xe0\n[  560.907970]  ? __mutex_lock_slowpath+0x20/0x20\n[  560.908214]  ? kmem_cache_alloc+0x143/0x4b0\n[  560.908459]  ntfs_lookup+0xe0/0x100\n[  560.908788]  __lookup_slow+0x116/0x220\n[  560.909050]  ? lookup_fast+0x1b0/0x1b0\n[  560.909309]  ? lookup_fast+0x13f/0x1b0\n[  560.909601]  walk_component+0x187/0x230\n[  560.909944]  link_path_walk.part.0+0x3f0/0x660\n[  560.910285]  ? handle_lookup_down+0x90/0x90\n[  560.910618]  ? path_init+0x642/0x6e0\n[  560.911084]  ? percpu_counter_add_batch+0x6e/0xf0\n[  560.912559]  ? __alloc_file+0x114/0x170\n[  560.913008]  path_openat+0x19c/0x1d10\n[  560.913419]  ? getname_flags+0x73/0x2b0\n[  560.913815]  ? kasan_save_stack+0x3a/0x50\n[  560.914125]  ? kasan_save_stack+0x26/0x50\n[  560.914542]  ? __kasan_slab_alloc+0x6d/0x90\n[  560.914924]  ? kmem_cache_alloc+0x143/0x4b0\n[  560.915339]  ? getname_flags+0x73/0x2b0\n[  560.915647]  ? getname+0x12/0x20\n[  560.916114]  ? __x64_sys_open+0x4c/0x60\n[  560.916460]  ? path_lookupat.isra.0+0x230/0x230\n[  560.916867]  ? __isolate_free_page+0x2e0/0x2e0\n[  560.917194]  do_filp_open+0x15c/0x1f0\n[  560.917448]  ? may_open_dev+0x60/0x60\n[  560.917696]  ? expand_files+0xa4/0x3a0\n[  560.917923]  ? __kasan_check_write+0x14/0x20\n[  560.918185]  ? _raw_spin_lock+0x88/0xdb\n[  560.918409]  ? _raw_spin_lock_irqsave+0x100/0x100\n[  560.918783]  ? _find_next_bit+0x4a/0x130\n[  560.919026]  ? _raw_spin_unlock+0x19/0x40\n[  560.919276]  ? alloc_fd+0x14b/0x2d0\n[  560.919635]  do_sys_openat2+0x32a/0x4b0\n[  560.920035]  ? file_open_root+0x230/0x230\n[  560.920336]  ? __rcu_read_unlock+0x5b/0x280\n[  560.920813]  do_sys_open+0x99/0xf0\n[  560.921208]  ? filp_open+0x60/0x60\n[  560.921482]  ? exit_to_user_mode_prepare+0x49/0x180\n[  560.921867]  __x64_sys_open+0x4c/0x60\n[  560.922128]  do_syscall_64+0x3b/0x90\n[  560.922369]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  560.923030] RIP: 0033:0x7f7dff2e4469\n[  560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088\n[  560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002\n[  560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469\n[  560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI:\n---truncated---(CVE-2022-50442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Avoid UBSAN error on true_sectors_per_clst()\n\nsyzbot reported UBSAN error as below:\n\n[   76.901829][ T6677] ================================================================================\n[   76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13\n[   76.905363][ T6677] shift exponent -247 is negative\n\nThis patch avoid this error.(CVE-2022-50762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()\n\nThere is a certain chance to trigger the following panic:\n\nPID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"\n #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7\n #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a\n #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60\n #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7\n #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715\n #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654\n #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62\n    [exception RIP: ib_alloc_mr+19]\n    RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202\n    RAX: 0000000000000000  RBX: 0000000000000002  RCX: 0000000000000004\n    RDX: 0000000000000010  RSI: 0000000000000000  RDI: 0000000000000000\n    RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20\n    R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000\n    R13: 0000000000000010  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]\n #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]\n #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]\n\nThe reason here is that when the server tries to create a second link,\nsmc_llc_srv_add_link() has no protection and may add a new link to\nlink group. This breaks the security environment protected by\nllc_conf_mutex.(CVE-2023-54237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: free copynotify stateid in nfs4_free_ol_stateid()\n\nTypically copynotify stateid is freed either when parent's stateid\nis being close/freed or in nfsd4_laundromat if the stateid hasn't\nbeen used in a lease period.\n\nHowever, in case when the server got an OPEN (which created\na parent stateid), followed by a COPY_NOTIFY using that stateid,\nfollowed by a client reboot. New client instance while doing\nCREATE_SESSION would force expire previous state of this client.\nIt leads to the open state being freed thru release_openowner->\nnfs4_free_ol_stateid() and it finds that it still has copynotify\nstateid associated with it. We currently print a warning and is\ntriggerred\n\nWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]\n\nThis patch, instead, frees the associated copynotify stateid here.\n\nIf the parent stateid is freed (without freeing the copynotify\nstateids associated with it), it leads to the list corruption\nwhen laundromat ends up freeing the copynotify state later.\n\n[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink\n[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G    B   W           6.17.0-rc7+ #22 PREEMPT(voluntary)\n[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]\n[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.861182] sp : ffff8000881d7a40\n[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200\n[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20\n[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8\n[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000\n[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065\n[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3\n[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000\n[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001\n[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000\n[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d\n[ 1626.868167] Call trace:\n[ 1626.868382]  __list_del_entry_valid_or_report+0x148/0x200 (P)\n[ 1626.868876]  _free_cpntf_state_locked+0xd0/0x268 [nfsd]\n[ 1626.869368]  nfs4_laundromat+0x6f8/0x1058 [nfsd]\n[ 1626.869813]  laundromat_main+0x24/0x60 [nfsd]\n[ 1626.870231]  process_one_work+0x584/0x1050\n[ 1626.870595]  worker_thread+0x4c4/0xc60\n[ 1626.870893]  kthread+0x2f8/0x398\n[ 1626.871146]  ret_from_fork+0x10/0x20\n[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)\n[ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atlantic: fix fragment overflow handling in RX path\n\nThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)\nfragments when handling large multi-descriptor packets. This causes an\nout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.\n\nThe issue occurs because the driver doesn't check the total number of\nfragments before calling skb_add_rx_frag(). When a packet requires more\nthan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.\n\nFix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,\nthen all fragments are accounted for. And reusing the existing check to\nprevent the overflow earlier in the code path.\n\nThis crash occurred in production with an Aquantia AQC113 10G NIC.\n\nStack trace from production environment:\n```\nRIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0\nCode: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89\nca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90\nc8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48\n89 fa 83\nRSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287\nRAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:\nfffffffe0a0c8000\nRDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:\n0000000000037a40\nRBP: 0000000000000024 R08: 0000000000000000 R09:\n0000000000000021\nR10: 0000000000000848 R11: 0000000000000000 R12:\nffffa9bec02a8e24\nR13: ffff925ad8615570 R14: 0000000000000000 R15:\nffff925b22e80a00\nFS: 0000000000000000(0000)\nGS:ffff925e47880000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:\n0000000000f72ef0\nPKRU: 55555554\nCall Trace:\n<IRQ>\naq_ring_rx_clean+0x175/0xe60 [atlantic]\n? aq_ring_rx_clean+0x14d/0xe60 [atlantic]\n? aq_ring_tx_clean+0xdf/0x190 [atlantic]\n? kmem_cache_free+0x348/0x450\n? aq_vec_poll+0x81/0x1d0 [atlantic]\n? __napi_poll+0x28/0x1c0\n? net_rx_action+0x337/0x420\n```\n\nChanges in v4:\n- Add Fixes: tag to satisfy patch validation requirements.\n\nChanges in v3:\n- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,\n  then all fragments are accounted for.(CVE-2025-68301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: separate dst_cache for input and output paths in seg6 lwtunnel\n\nThe seg6 lwtunnel uses a single dst_cache per encap route, shared\nbetween seg6_input_core() and seg6_output_core(). These two paths\ncan perform the post-encap SID lookup in different routing contexts\n(e.g., ip rules matching on the ingress interface, or VRF table\nseparation). Whichever path runs first populates the cache, and the\nother reuses it blindly, bypassing its own lookup.\n\nFix this by splitting the cache into cache_input and cache_output,\nso each path maintains its own cached dst independently.(CVE-2026-31668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: validate connector number in ucsi_notify_common()\n\nThe connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a\n7-bit field (0-127) that is used to index into the connector array in\nucsi_connector_change(). However, the array is only allocated for the\nnumber of connectors reported by the device (typically 2-4 entries).\n\nA malicious or malfunctioning device could report an out-of-range\nconnector number in the CCI, causing an out-of-bounds array access in\nucsi_connector_change().\n\nAdd a bounds check in ucsi_notify_common(), the central point where CCI\nis parsed after arriving from hardware, so that bogus connector numbers\nare rejected before they propagate further.(CVE-2026-31729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix regsafe() for pointers to packet\n\nIn case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N\nregsafe() may return true which may lead to current state with\nvalid packet range not being explored. Fix the bug.(CVE-2026-43030)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak\n\nWhen processing Router Advertisements with user options the kernel\nbuilds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct\nhas three padding fields that are never zeroed and can leak kernel data\n\nThe fix is simple, just zeroes the padding fields.(CVE-2026-43040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: close crash window in attr dabtree inactivation\n\nWhen inactivating an inode with node-format extended attributes,\nxfs_attr3_node_inactive() invalidates all child leaf/node blocks via\nxfs_trans_binval(), but intentionally does not remove the corresponding\nentries from their parent node blocks.  The implicit assumption is that\nxfs_attr_inactive() will truncate the entire attr fork to zero extents\nafterwards, so log recovery will never reach the root node and follow\nthose stale pointers.\n\nHowever, if a log shutdown occurs after the leaf/node block cancellations\ncommit but before the attr bmap truncation commits, this assumption\nbreaks.  Recovery replays the attr bmap intact (the inode still has\nattr fork extents), but suppresses replay of all cancelled leaf/node\nblocks, maybe leaving them as stale data on disk.  On the next mount,\nxlog_recover_process_iunlinks() retries inactivation and attempts to\nread the root node via the attr bmap. If the root node was not replayed,\nreading the unreplayed root block triggers a metadata verification\nfailure immediately; if it was replayed, following its child pointers\nto unreplayed child blocks triggers the same failure:\n\n XFS (pmem0): Metadata corruption detected at\n xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78\n XFS (pmem0): Unmount and run xfs_repair\n XFS (pmem0): First 128 bytes of corrupted metadata buffer:\n 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117\n\nFix this in two places:\n\nIn xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a\nchild block, immediately remove the entry that references it from the\nparent node in the same transaction.  This eliminates the window where\nthe parent holds a pointer to a cancelled block.  Once all children are\nremoved, the now-empty root node is converted to a leaf block within the\nsame transaction. This node-to-leaf conversion is necessary for crash\nsafety. If the system shutdown after the empty node is written to the\nlog but before the second-phase bmap truncation commits, log recovery\nwill attempt to verify the root block on disk. xfs_da3_node_verify()\ndoes not permit a node block with count == 0; such a block will fail\nverification and trigger a metadata corruption shutdown. on the other\nhand, leaf blocks are allowed to have this transient state.\n\nIn xfs_attr_inactive(), split the attr fork truncation into two explicit\nphases.  First, truncate all extents beyond the root block (the child\nextents whose parent references have already been removed above).\nSecond, invalidate the root block and truncate the attr bmap to zero in\na single transaction.  The two operations in the second phase must be\natomic: as long as the attr bmap has any non-zero length, recovery can\nfollow it to the root block, so the root block invalidation must commit\ntogether with the bmap-to-zero truncation.(CVE-2026-43053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()\n\nIf overlay is used on top of btrfs, dentry->d_sb translates to overlay's\nsuper block and fsid assignment will lead to a crash.\n\nUse file_inode(file)->i_sb to always get btrfs_sb.(CVE-2026-43117)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ\n\nThis adds a check for encryption key size upon receiving\nL2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which\nexpects L2CAP_CR_LE_BAD_KEY_SIZE.(CVE-2026-43134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkexec: derive purgatory entry from symbol\n\nkexec_load_purgatory() derives image->start by locating e_entry inside an\nSHF_EXECINSTR section.  If the purgatory object contains multiple\nexecutable sections with overlapping sh_addr, the entrypoint check can\nmatch more than once and trigger a WARN.\n\nDerive the entry section from the purgatory_start symbol when present and\ncompute image->start from its final placement.  Keep the existing e_entry\nfallback for purgatories that do not expose the symbol.\n\nWARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784\nCall Trace:\n <TASK>\n bzImage64_load+0x133/0xa00\n __do_sys_kexec_file_load+0x2b3/0x5c0\n do_syscall_64+0x81/0x610\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[(CVE-2026-43289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()\n\nThis patch fixes an out-of-bounds access in ceph_handle_auth_reply()\nthat can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In\nceph_handle_auth_reply(), the value of the payload_len field of such a\nmessage is stored in a variable of type int. A value greater than\nINT_MAX leads to an integer overflow and is interpreted as a negative\nvalue. This leads to decrementing the pointer address by this value and\nsubsequently accessing it because ceph_decode_need() only checks that\nthe memory access does not exceed the end address of the allocation.\n\nThis patch fixes the issue by changing the data type of payload_len to\nu32. Additionally, the data type of result_msg_len is changed to u32,\nas it is also a variable holding a non-negative length.\n\nAlso, an additional layer of sanity checks is introduced, ensuring that\ndirectly after reading it from the message, payload_len and\nresult_msg_len are not greater than the overall segment length.\n\nBUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]\nRead of size 4 at addr ffff88811404df14 by task kworker/20:1/262\n\nCPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nWorkqueue: ceph-msgr ceph_con_workfn [libceph]\nCall Trace:\n <TASK>\n dump_stack_lvl+0x76/0xa0\n print_report+0xd1/0x620\n ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n ? kasan_complete_mode_report_info+0x72/0x210\n kasan_report+0xe7/0x130\n ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]\n ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]\n __asan_report_load_n_noabort+0xf/0x20\n ceph_handle_auth_reply+0x642/0x7a0 [libceph]\n mon_dispatch+0x973/0x23d0 [libceph]\n ? apparmor_socket_recvmsg+0x6b/0xa0\n ? __pfx_mon_dispatch+0x10/0x10 [libceph]\n ? __kasan_check_write+0x14/0x30i\n ? mutex_unlock+0x7f/0xd0\n ? __pfx_mutex_unlock+0x10/0x10\n ? __pfx_do_recvmsg+0x10/0x10 [libceph]\n ceph_con_process_message+0x1f1/0x650 [libceph]\n process_message+0x1e/0x450 [libceph]\n ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]\n ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph]\n ? save_fpregs_to_fpstate+0xb0/0x230\n ? raw_spin_rq_unlock+0x17/0xa0\n ? finish_task_switch.isra.0+0x13b/0x760\n ? __switch_to+0x385/0xda0\n ? __kasan_check_write+0x14/0x30\n ? mutex_lock+0x8d/0xe0\n ? __pfx_mutex_lock+0x10/0x10\n ceph_con_workfn+0x248/0x10c0 [libceph]\n process_one_work+0x629/0xf80\n ? __kasan_check_write+0x14/0x30\n worker_thread+0x87f/0x1570\n ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n ? __pfx_try_to_wake_up+0x10/0x10\n ? kasan_print_address_stack_frame+0x1f7/0x280\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x396/0x830\n ? __pfx__raw_spin_lock_irq+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ? __kasan_check_write+0x14/0x30\n ? recalc_sigpending+0x180/0x210\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x3f7/0x610\n ? __pfx_ret_from_fork+0x10/0x10\n ? __switch_to+0x385/0xda0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\n[ idryomov: replace if statements with ceph_decode_need() for\n  payload_len and result_msg_len ](CVE-2026-43407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Fix handling of MAY_BACKLOG requests\n\nMAY_BACKLOG requests can return EBUSY.  Handle them by checking\nfor that value and filtering out EINPROGRESS notifications.(CVE-2026-43493)","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-316.0.0.219.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","perf-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-316.0.0.219.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","perf-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2492"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50442"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50762"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40273"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68301"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31729"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43030"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43040"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43117"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43493"}],"database_specific":{"severity":"Critical"}}