OESA-2026-3156 (CVE-2025-38708)
Vulnerability from osv_openeuler – Published: 2026-07-24 11:12 – Updated: 2026-08-06 11:12 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
drbd: add missing kref_get in handle_write_conflicts
With two-primaries enabled, DRBD tries to detect "concurrent" writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.
In handling "superseeded" writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use after free, and further to kernel crashes with symptoms.
Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.
Which means that other than for "test cases", this code path is never taken in real life.
FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.(CVE-2025-38708)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Initialize the chan_stats array to zero
The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey().
There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak.
Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().(CVE-2025-39891)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ctxfi: Fix potential OOB access in audio mixer handling
In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()).
As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]'
After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field.
This patch addresses those OOB accesses by adding the proper initializations of the loop indices.(CVE-2026-23076)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix call removal to use RCU safe deletion
Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop.
This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by:
Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that.
rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.(CVE-2026-31642)
In the Linux kernel, the following vulnerability has been resolved:
drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device.
This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more.
To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.(CVE-2026-45956)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix invalid deref of rawdata when export_binary is unset
If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set.
[ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 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 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] <TASK> [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2026-45965)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Add spectre boundry for syscall dispatch table
The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.(CVE-2026-45993)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: ADD_ADDR rtx: fix potential data-race
This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock().
If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.(CVE-2026-46137)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value by validating catalog record size
Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read.
When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed:
HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ!
hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized.
This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold().
Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected
For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure.
Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.(CVE-2026-46169)
In the Linux kernel, the following vulnerability has been resolved:
isofs: validate Rock Ridge CE continuation extent against volume size
rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.
With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size.
Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.(CVE-2026-46303)
In the Linux kernel, the following vulnerability has been resolved:
neigh: let neigh_xmit take skb ownership
neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx).
sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB?
Assume full ownership and remove the last code path that doesn't xmit or free skb.(CVE-2026-52981)
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with
if (len < num_chunks)
return -EINVAL;
but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer.
The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check:
if (len < sizeof(struct sctp_authchunks) + num_chunks)
return -EINVAL;
Align the peer variant with its sibling.
Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data.(CVE-2026-53004)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix double-free of tx_buf skb
If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time.
The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path.
The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch.
I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN.
I looked for similar bugs in related Intel drivers and did not find any.(CVE-2026-53009)
In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: Fix off-by-one in check_imm signed range check
check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side.
In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.(CVE-2026-53036)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate bg_bits during freefrag scan
[BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.
BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ...
[CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block.
[FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer.(CVE-2026-53040)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs
[Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node.
The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36.
Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data))
(cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)(CVE-2026-53135)
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative.
isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path.
Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.(CVE-2026-53176)
{
"affected": [
{
"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"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-325.0.0.226.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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 \u0026quot;concurrent\u0026quot; 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 \u0026quot;superseeded\u0026quot; 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 \u0026quot;two-primaries\u0026quot; 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 \u0026quot;test cases\u0026quot;,\nthis code path is never taken in real life.\n\nFYI, in DRBD 9, things are handled differently nowadays. We still detect\n\u0026quot;write conflicts\u0026quot;, 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\u0026apos;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-\u0026gt;chan_stats[] array is initialized in\nmwifiex_init_channel_scan_gap() with vmalloc(), which doesn\u0026apos;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\u0026apos;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\u0026apos;s a maximum of 900 bytes so it\u0026apos;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\u0026apos;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 \u0026apos;unsigned char [8]\u0026apos;\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-\u0026gt;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\u0026apos;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\u0026apos;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-\u0026gt;vidi_dev for ctx lookup in vidi_connection_ioctl()\n\nvidi_connection_ioctl() retrieves the driver_data from drm_dev-\u0026gt;dev to\nobtain a struct vidi_context pointer. However, drm_dev-\u0026gt;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-\u0026gt;vidi_dev during bind/unbind, and then read this\nexynos_drm_private-\u0026gt;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-\u0026gt;rawdata-\u0026gt;name when\nprofile-\u0026gt;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 \u0026lt;48\u0026gt; 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] \u0026lt;TASK\u0026gt;\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\u0026apos;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-\u0026gt;entrylength=26\n HFSPLUS_BREC_READ: WARNING - entrylength (26) \u0026lt; rec_len (520) - PARTIAL READ!\n\nhfs_brec_read() only validates that entrylength is not greater than the\nbuffer size, but doesn\u0026apos;t check if it\u0026apos;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\u0026apos;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\u0026apos;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-\u0026gt;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(\u0026quot;[PATCH] rock.c: handle corrupted directories\u0026quot;) added cont_offset\nand cont_size rejection for the CE continuation but did not validate\nthe extent block number itself. commit f54e18f1b831 (\u0026quot;isofs: Fix\ninfinite looping over CE entries\u0026quot;) 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-\u0026gt;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)-\u0026gt;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\u0026apos;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\u0026apos;s optval\nbuffer is large enough for the peer AUTH chunk list with\n\n if (len \u0026lt; num_chunks)\n return -EINVAL;\n\nbut then writes num_chunks bytes to p-\u0026gt;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 \u0026gt; 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 \u0026lt; 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\u0026apos;s AUTH chunk type. The bytes written are under the peer\u0026apos;s\ncontrol but land in the caller\u0026apos;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 \u0026apos;first\u0026apos; tx_buf still points\nto it and is marked as valid (ICE_TX_BUF_SKB).\n\u0026apos;next_to_use\u0026apos; 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() -\u0026gt; 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 \u0026apos;first\u0026apos; up, to ensure it\u0026apos;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 \u0026gt; 0 \u0026amp;\u0026amp; imm \u0026gt;\u0026gt; bits) || (imm \u0026lt; 0 \u0026amp;\u0026amp; ~imm \u0026gt;\u0026gt; bits) which admits\nvalues in [-2^N, 2^N) \u2014 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 \u0026amp; How]\ndp_sdp_message_debugfs_write() dereferences connector-\u0026gt;base.state-\u0026gt;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 \u0026lt; 36.\n\nFix both issues by:\n- Returning -ENODEV when connector-\u0026gt;base.state or state-\u0026gt;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-\u0026gt;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-\u0026gt;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)",
"id": "OESA-2026-3156",
"modified": "2026-08-06T11:12:02Z",
"published": "2026-07-24T11:12:02Z",
"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"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"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"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.