{"schema_version":"1.7.2","id":"OESA-2026-3156","modified":"2026-07-24T03:28:28Z","published":"2026-07-24T03:28:28Z","upstream":["CVE-2025-38708","CVE-2025-39891","CVE-2026-23076","CVE-2026-31642","CVE-2026-45956","CVE-2026-45965","CVE-2026-45993","CVE-2026-46137","CVE-2026-46169","CVE-2026-46303","CVE-2026-52981","CVE-2026-53004","CVE-2026-53009","CVE-2026-53036","CVE-2026-53040","CVE-2026-53135","CVE-2026-53176"],"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\ndrbd: add missing kref_get in handle_write_conflicts\n\nWith `two-primaries` enabled, DRBD tries to detect "concurrent" writes\nand handle write conflicts, so that even if you write to the same sector\nsimultaneously on both nodes, they end up with the identical data once\nthe writes are completed.\n\nIn handling "superseeded" writes, we forgot a kref_get,\nresulting in a premature drbd_destroy_device and use after free,\nand further to kernel crashes with symptoms.\n\nRelevance: No one should use DRBD as a random data generator, and apparently\nall users of "two-primaries" handle concurrent writes correctly on layer up.\nThat is cluster file systems use some distributed lock manager,\nand live migration in virtualization environments stops writes on one node\nbefore starting writes on the other node.\n\nWhich means that other than for "test cases",\nthis code path is never taken in real life.\n\nFYI, in DRBD 9, things are handled differently nowadays.  We still detect\n"write conflicts", but no longer try to be smart about them.\nWe decided to disconnect hard instead: upper layers must not submit concurrent\nwrites. If they do, that's their fault.(CVE-2025-38708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Initialize the chan_stats array to zero\n\nThe adapter->chan_stats[] array is initialized in\nmwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out\nmemory.  The array is filled in mwifiex_update_chan_statistics()\nand then the user can query the data in mwifiex_cfg80211_dump_survey().\n\nThere are two potential issues here.  What if the user calls\nmwifiex_cfg80211_dump_survey() before the data has been filled in.\nAlso the mwifiex_update_chan_statistics() function doesn't necessarily\ninitialize the whole array.  Since the array was not initialized at\nthe start that could result in an information leak.\n\nAlso this array is pretty small.  It's a maximum of 900 bytes so it's\nmore appropriate to use kcalloc() instead vmalloc().(CVE-2025-39891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Fix potential OOB access in audio mixer handling\n\nIn the audio mixer handling code of ctxfi driver, the conf field is\nused as a kind of loop index, and it's referred in the index callbacks\n(amixer_index() and sum_index()).\n\nAs spotted recently by fuzzers, the current code causes OOB access at\nthose functions.\n| UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48\n| index 8 is out of range for type 'unsigned char [8]'\n\nAfter the analysis, the cause was found to be the lack of the proper\n(re-)initialization of conj field.\n\nThis patch addresses those OOB accesses by adding the proper\ninitializations of the loop indices.(CVE-2026-23076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix call removal to use RCU safe deletion\n\nFix rxrpc call removal from the rxnet->calls list to use list_del_rcu()\nrather than list_del_init() to prevent stuffing up reading\n/proc/net/rxrpc/calls from potentially getting into an infinite loop.\n\nThis, however, means that list_empty() no longer works on an entry that's\nbeen deleted from the list, making it harder to detect prior deletion.  Fix\nthis by:\n\nFirstly, make rxrpc_destroy_all_calls() only dump the first ten calls that\nare unexpectedly still on the list.  Limiting the number of steps means\nthere's no need to call cond_resched() or to remove calls from the list\nhere, thereby eliminating the need for rxrpc_put_call() to check for that.\n\nrxrpc_put_call() can then be fixed to unconditionally delete the call from\nthe list as it is the only place that the deletion occurs.(CVE-2026-31642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()\n\nvidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to\nobtain a struct vidi_context pointer. However, drm_dev->dev is the\nexynos-drm master device, and the driver_data contained therein is not\nthe vidi component device, but a completely different device.\n\nThis can lead to various bugs, ranging from null pointer dereferences and\ngarbage value accesses to, in unlucky cases, out-of-bounds errors,\nuse-after-free errors, and more.\n\nTo resolve this issue, we need to store/delete the vidi device pointer in\nexynos_drm_private->vidi_dev during bind/unbind, and then read this\nexynos_drm_private->vidi_dev within ioctl() to obtain the correct\nstruct vidi_context pointer.(CVE-2026-45956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix invalid deref of rawdata when export_binary is unset\n\nIf the export_binary parameter is disabled on runtime, profiles that\nwere loaded before that will still have their rawdata stored in\napparmorfs, with a symbolic link to the rawdata on the policy\ndirectory. When one of those profiles are replaced, the rawdata is set\nto NULL, but when trying to resolve the symbolic links to rawdata for\nthat profile, it will try to dereference profile->rawdata->name when\nprofile->rawdata is now NULL causing an oops. Fix it by checking if\nrawdata is set.\n\n[  168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088\n[  168.657420] #PF: supervisor read access in kernel mode\n[  168.660619] #PF: error_code(0x0000) - not-present page\n[  168.663613] PGD 0 P4D 0\n[  168.665450] Oops: Oops: 0000 [#1] SMP NOPTI\n[  168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)\n[  168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330\n[  168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8\n[  168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282\n[  168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158\n[  168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80\n[  168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000\n[  168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80\n[  168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0\n[  168.697637] FS:  0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000\n[  168.699227] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0\n[  168.701696] Call Trace:\n[  168.702325]  <TASK>\n[  168.702995]  rawdata_get_link_data+0x1c/0x30\n[  168.704145]  vfs_readlink+0xd4/0x160\n[  168.705152]  do_readlinkat+0x114/0x180\n[  168.706214]  __x64_sys_readlink+0x1e/0x30\n[  168.708653]  x64_sys_call+0x1d77/0x26b0\n[  168.709525]  do_syscall_64+0x81/0x500\n[  168.710348]  ? do_statx+0x72/0xb0\n[  168.711109]  ? putname+0x3e/0x80\n[  168.711845]  ? __x64_sys_statx+0xb7/0x100\n[  168.712711]  ? x64_sys_call+0x10fc/0x26b0\n[  168.713577]  ? do_syscall_64+0xbf/0x500\n[  168.714412]  ? do_user_addr_fault+0x1d2/0x8d0\n[  168.715404]  ? irqentry_exit+0xb2/0x740\n[  168.716359]  ? exc_page_fault+0x90/0x1b0\n[  168.717307]  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2026-45965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add spectre boundry for syscall dispatch table\n\nThe LoongArch syscall number is directly controlled by userspace, but\ndoes not have a array_index_nospec() boundry to prevent access past the\nsyscall function pointer tables.(CVE-2026-45993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: ADD_ADDR rtx: fix potential data-race\n\nThis mptcp_pm_add_timer() helper is executed as a timer callback in\nsoftirq context. To avoid any data races, the socket lock needs to be\nheld with bh_lock_sock().\n\nIf the socket is in use, retry again soon after, similar to what is done\nwith the keepalive timer.(CVE-2026-46137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix uninit-value by validating catalog record size\n\nSyzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The\nroot cause is that hfs_brec_read() doesn't validate that the on-disk\nrecord size matches the expected size for the record type being read.\n\nWhen mounting a corrupted filesystem, hfs_brec_read() may read less data\nthan expected. For example, when reading a catalog thread record, the\ndebug output showed:\n\n  HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26\n  HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ!\n\nhfs_brec_read() only validates that entrylength is not greater than the\nbuffer size, but doesn't check if it's less than expected. It successfully\nreads 26 bytes into a 520-byte structure and returns success, leaving 494\nbytes uninitialized.\n\nThis uninitialized data in tmp.thread.nodeName then gets copied by\nhfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering\nthe KMSAN warning when the uninitialized bytes are used as array indices\nin case_fold().\n\nFix by introducing hfsplus_brec_read_cat() wrapper that:\n1. Calls hfs_brec_read() to read the data\n2. Validates the record size based on the type field:\n   - Fixed size for folder and file records\n   - Variable size for thread records (depends on string length)\n3. Returns -EIO if size doesn't match expected\n\nFor thread records, check against HFSPLUS_MIN_THREAD_SZ before reading\nnodeName.length to avoid reading uninitialized data at call sites that\ndon't zero-initialize the entry structure.\n\nAlso initialize the tmp variable in hfsplus_find_cat() as defensive\nprogramming to ensure no uninitialized data even if validation is\nbypassed.(CVE-2026-46169)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: validate Rock Ridge CE continuation extent against volume size\n\nrock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE\nrecord and passes it to sb_bread() without checking that the block\nnumber is within the mounted ISO 9660 volume.  commit e595447e177b\n("[PATCH] rock.c: handle corrupted directories") added cont_offset\nand cont_size rejection for the CE continuation but did not validate\nthe extent block number itself.  commit f54e18f1b831 ("isofs: Fix\ninfinite looping over CE entries") later capped the CE chain length\nat RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.\n\nWith a crafted ISO mounted via udisks2 (desktop optical auto-mount)\nor via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at\nan out-of-range block or at blocks belonging to an adjacent\nfilesystem on the same block device.  sb_bread() on an out-of-range\nblock returns NULL cleanly via the block layer EIO path, so there\nis no memory-safety violation.  For in-range reads of adjacent-\nfilesystem data, the CE buffer is parsed as Rock Ridge records and\nonly the text of SL sub-records reaches userspace through\nreadlink(), which makes the info-leak channel narrow and difficult\nto exploit; still, rejecting the malformed CE outright matches the\nrejection shape already present in the same function for\ncont_offset and cont_size.\n\nAdd an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next\nto the existing offset/size rejection, printing the same\ncorrupted-directory-entry notice.(CVE-2026-46303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nneigh: let neigh_xmit take skb ownership\n\nneigh_xmit always releases the skb, except when no neighbour table is\nfound. But even the first added user of neigh_xmit (mpls) relied on\nneigh_xmit to release the skb (or queue it for tx).\n\nsashiko reported:\n If neigh_xmit() is called with an uninitialized neighbor table (for\n example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT\n and bypasses its internal out_kfree_skb error path.  Because the return\n value of neigh_xmit() is ignored here, does this leak the SKB?\n\nAssume full ownership and remove the last code path that doesn't\nxmit or free skb.(CVE-2026-52981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks\n\nsctp_getsockopt_peer_auth_chunks() checks that the caller's optval\nbuffer is large enough for the peer AUTH chunk list with\n\n    if (len < num_chunks)\n            return -EINVAL;\n\nbut then writes num_chunks bytes to p->gauth_chunks, which lives\nat offset offsetof(struct sctp_authchunks, gauth_chunks) == 8\ninside optval.  The check is missing the sizeof(struct\nsctp_authchunks) = 8-byte header.  When the caller supplies\nlen == num_chunks (for any num_chunks > 0) the test passes but\ncopy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes\npast the declared buffer.\n\nThe sibling function sctp_getsockopt_local_auth_chunks() at the\nnext line already has the correct check:\n\n    if (len < sizeof(struct sctp_authchunks) + num_chunks)\n            return -EINVAL;\n\nAlign the peer variant with its sibling.\n\nReproducer confirms on v7.0-13-generic: an unprivileged userspace\ncaller that opens a loopback SCTP association with AUTH enabled,\nqueries num_chunks with a short optval, then issues the real\ngetsockopt with len == num_chunks and sentinel bytes painted past\nthe buffer observes those sentinel bytes overwritten with the\npeer's AUTH chunk type.  The bytes written are under the peer's\ncontrol but land in the caller's own userspace; this is not a\nkernel memory corruption, but it is a kernel-side contract\nviolation that can silently corrupt adjacent userspace data.(CVE-2026-53004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix double-free of tx_buf skb\n\nIf ice_tso() or ice_tx_csum() fail, the error path in\nice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points\nto it and is marked as valid (ICE_TX_BUF_SKB).\n'next_to_use' remains unchanged, so the potential problem will\nlikely fix itself when the next packet is transmitted and the tx_buf\ngets overwritten. But if there is no next packet and the interface is\nbrought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf()\nwill find the tx_buf and free the skb for the second time.\n\nThe fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error\npath, so that ice_unmap_and_free_tx_buf().\nMove the initialization of 'first' up, to ensure it's already valid in\ncase we hit the linearization error path.\n\nThe bug was spotted by AI while I had it looking for something else.\nIt also proposed an initial version of the patch.\n\nI reproduced the bug and tested the fix by adding code to inject\nfailures, on a build with KASAN.\n\nI looked for similar bugs in related Intel drivers and did not find any.(CVE-2026-53009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Fix off-by-one in check_imm signed range check\n\ncheck_imm(bits, imm) is used in the arm64 BPF JIT to verify that\na branch displacement (in arm64 instruction units) fits into the\nsigned N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding\nbefore it is handed to the encoder. The macro currently tests for\n(imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits\nvalues in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A\nsigned N-bit field only holds [-2^(N-1), 2^(N-1)), so the check\nadmits one extra bit of range on each side.\n\nIn particular, for check_imm19(), values in [2^18, 2^19) slip past\nthe check but do not fit into the 19-bit signed imm19 field of\nB.cond. aarch64_insn_encode_immediate() then masks the raw value\ninto the 19-bit field, setting bit 18 (the sign bit) and flipping\na forward branch into a backward one. Same class of issue exists\nfor check_imm26() and the B/BL encoding. Shift by (bits - 1)\ninstead of bits so the actual signed N-bit range is enforced.(CVE-2026-53036)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate bg_bits during freefrag scan\n\n[BUG]\nA crafted filesystem can trigger an out-of-bounds bitmap walk when\nOCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.\n\nBUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]\nBUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\nBUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline]\nBUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]\nBUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]\nBUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]\nBUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754\nRead of size 8 at addr ffff888031bce000 by task syz.0.636/1435\nCall Trace:\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xd1/0x650 mm/kasan/report.c:482\n kasan_report+0xfb/0x140 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:186 [inline]\n kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200\n __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n instrument_atomic_read include/linux/instrumented.h:68 [inline]\n _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n test_bit_le include/asm-generic/bitops/le.h:21 [inline]\n ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]\n ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]\n ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]\n ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754\n ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828\n ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583\n ...\n\n[CAUSE]\nocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the\nbitmap scan limit. The coherent path reads group descriptors through\nocfs2_read_group_descriptor(), which validates the descriptor before\nuse. The non-coherent path uses ocfs2_read_blocks_sync() instead and\nskips that validation, so an impossible bg_bits value can drive the\nbitmap walk past the end of the block.\n\n[FIX]\nCompute the bitmap capacity from the filesystem format with\nocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds\nthat limit, and clamp the scan to the computed capacity. This keeps the\nfreefrag report going while avoiding reads beyond the buffer.(CVE-2026-53040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs\n\n[Why & How]\ndp_sdp_message_debugfs_write() dereferences connector->base.state->crtc\nwithout checking for NULL. A connector can be connected but not bound to\nany CRTC (e.g. after hot-plug before the next atomic commit), causing a\nkernel crash when writing to the sdp_message debugfs node.\n\nThe function also ignores the user-provided size argument and always\npasses 36 bytes to copy_from_user(), reading past the user buffer when\nsize < 36.\n\nFix both issues by:\n- Returning -ENODEV when connector->base.state or state->crtc is NULL\n- Clamping write_size to min(size, sizeof(data))\n\n(cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)(CVE-2026-53135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\n\nIn drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done()\ncomputes the login request payload length as wc->byte_len minus\nISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int.\nA remote iSER initiator can post a login Send work request carrying\nfewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows\nand login_req_len becomes negative.\n\nisert_rx_login_req() then reads that negative length back into a signed\nint, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the\nmin() is signed it keeps the negative value; the value is then passed as\nthe memcpy() length and sign-extended to a multi-gigabyte size_t. The\ncopy into the 8192-byte login->req_buf runs far out of bounds and\nfaults, crashing the target node. The login phase precedes iSCSI\nauthentication, so no credentials are required to reach this path.\n\nReject any login PDU shorter than ISER_HEADERS_LEN before the\nsubtraction, mirroring the existing early return on a failed work\ncompletion, so login_req_len can never go negative. The upper bound was\nalready safe: a posted login buffer cannot deliver more than\nISER_RX_PAYLOAD_SIZE, so the difference stays at or below\nMAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing\nlower bound needs to be added.(CVE-2026-53176)","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-325.0.0.226.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","perf-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-325.0.0.226.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-325.0.0.226.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","perf-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-325.0.0.226.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38708"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46137"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46169"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46303"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53036"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53040"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53176"}],"database_specific":{"severity":"Critical"}}