oesa-2026-3454
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
xfs: remove xfs_attr_leaf_hasname
The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values.
Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read.(CVE-2026-43153)
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: Disable KCOV instrumentation after load_segments()
The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop.
To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:
$ kexec -l /boot/otherKernel $ kexec -e
The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously.
Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead.
Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.
The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there.
bp: Space out comment for better readability.
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix & Optimize table creation from possibly unaligned memory
Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.
- Added Fixes tag
- Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access jj: remove duplicate word "convert" in comment trigger checkpatch warning
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: fix race between ICReq handling and queue teardown
nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.
If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.
If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue.
The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference.
Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.
Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.(CVE-2026-46135)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: use list_del_rcu for netlink hooks
nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers.
Add a new helper and use it consistently.(CVE-2026-46324)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: During rereg_mr ensure that REREG_ACCESS is compatible
If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS.
mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.(CVE-2026-52908)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: serialize accept_q access
bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import.
Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.(CVE-2026-52918)
In the Linux kernel, the following vulnerability has been resolved:
ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.
The bug is in ipc_idr_alloc() in the checkpoint/restore path.
-
ids->next_id is passed to:
idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)
-
The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range.
-
The new object id is still encoded with the narrower SysV IPC index width:
new->id = (new->seq << ipcmni_seq_shift()) + idx
-
Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id)
That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.
-
For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.
-
A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.
Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.(CVE-2026-52923)
In the Linux kernel, the following vulnerability has been resolved:
ipc/shm: serialize orphan cleanup with shm_nattch updates
shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem.
Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.(CVE-2026-52930)
In the Linux kernel, the following vulnerability has been resolved:
i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl
While fuzzing with Syzkaller, a persistent schedule_timeout: wrong
timeout value warning was observed, accompanied by SMBus controller
state machine corruption.
The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies().
A malicious user can pass a large value (e.g., 429496729) that passes
the arg > INT_MAX check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal (int)m < 0 check in msecs_to_jiffies().
The truncated value is then assigned to client->adapter->timeout
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
schedule_timeout warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).
Fix this by bounding the user argument to INT_MAX / 10.
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix oops due to out of scope access
Below oops triggers when kill QEMU process:
Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain.(CVE-2026-52953)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
The generic/642 test-case can reproduce the kernel crash:
[40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]---
Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race.
__build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __bui ---truncated---(CVE-2026-52961)
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: fix inode reference leak in fsnotify_recalc_mask()
fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared.
This manifests as a hung task with the following call trace:
INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exit
The race window that triggers the iref leak:
Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return
/* ---- gap: no lock held ---- */
fsnotify_detach_mark(mark_A):
spin_lock(mark_A->lock)
clear ATTACHED flag on mark_A
spin_unlock(mark_A->lock)
fsnotify_put_mark(mark_A)
fsnotify_recalc_mask():
spin_lock(conn->lock)
__fsnotify_recalc_mask():
/* mark_A skipped: ATTACHED cleared */
/* only mark_B(evictable) remains */
want_iref = false
has_iref = true /* not yet cleared */
-> HAS_IREF transitions true -> false
-> returns inode pointer
spin_unlock(conn->lock)
/* BUG: return value discarded!
* iput() and fsnotify_put_sb_watched_objects()
* are never called */
Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).(CVE-2026-52990)
In the Linux kernel, the following vulnerability has been resolved:
erofs: unify lcn as u64 for 32-bit platforms
As sashiko reported [1], lcn was typed as unsigned long (or
unsigned int sometimes), which is only 32 bits wide on 32-bit
platforms, which causes (lcn << lclusterbits) to be truncated
at 4 GiB.
In order to consolidate the logic, just use u64 consistently
around the codebase.
[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com(CVE-2026-53015)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix clone_alias() to use the original device's devid
Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument.
This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device.
Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it.(CVE-2026-53053)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: kl5kusb105: fix bulk-out buffer overflow
klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy:
count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock);
When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does.
Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget:
BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region
The out-of-bounds write no longer occurs with this change applied.(CVE-2026-53194)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: io_ti: fix heap overflow in get_manuf_info()
get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes.
The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.
valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.
Fix by rejecting descriptors with unexpected length before calling read_rom().
johan: amend commit message; also check for short descriptors
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()
pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).
Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference.
To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).(CVE-2026-53262)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED
[Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs.
The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.
[How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation.
(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)(CVE-2026-53285)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths
In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace().
Both functions check:
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
and then call DC_LOG_ERROR() inside that block.
DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash.
Fix this by splitting the checks.
First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid.
Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)(CVE-2026-53313)
In the Linux kernel, the following vulnerability has been resolved:
padata: Put CPU offline callback in ONLINE section to allow failure
syzbot reported the following warning:
DEAD callback error for CPU1
WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614
at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error.
Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible.(CVE-2026-53314)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix driver removal with disabled KMS
DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.(CVE-2026-53347)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.22.159.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.1.22.159.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.22.159.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.1.22.159.oe2403sp1"
}
],
"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\nxfs: remove xfs_attr_leaf_hasname\n\nThe calling convention of xfs_attr_leaf_hasname() is problematic, because\nit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer\nwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a\nnon-NULL buffer pointer for an already released buffer when\nxfs_attr3_leaf_lookup_int fails with other error values.\n\nFix this by simply open coding xfs_attr_leaf_hasname in the callers, so\nthat the buffer release code is done by each caller of\nxfs_attr3_leaf_read.(CVE-2026-43153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: Disable KCOV instrumentation after load_segments()\n\nThe load_segments() function changes segment registers, invalidating GS base\n(which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any\nsubsequent instrumented C code call (e.g. native_gdt_invalidate()) begins\ncrashing the kernel in an endless loop.\n\nTo reproduce the problem, it\u0026apos;s sufficient to do kexec on a KCOV-instrumented\nkernel:\n\n $ kexec -l /boot/otherKernel\n $ kexec -e\n\nThe real-world context for this problem is enabling crash dump collection in\nsyzkaller. For this, the tool loads a panic kernel before fuzzing and then\ncalls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC\nand CONFIG_KCOV to be enabled simultaneously.\n\nAdding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc())\nis also undesirable as it would introduce an extra performance overhead.\n\nDisabling instrumentation for the individual functions would be too fragile,\nso disable KCOV instrumentation for the entire machine_kexec_64.c and\nphysaddr.c. If coverage-guided fuzzing ever needs these components in the\nfuture, other approaches should be considered.\n\nThe problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported\nthere.\n\n [ bp: Space out comment for better readability. ](CVE-2026-43331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix \u0026amp; Optimize table creation from possibly unaligned memory\n\nSource blob may come from userspace and might be unaligned.\nTry to optize the copying process by avoiding unaligned memory accesses.\n\n- Added Fixes tag\n- Added \u0026quot;Fix \u0026amp;\u0026quot; to description as this doesn\u0026apos;t just optimize but fixes\n a potential unaligned memory access\n[jj: remove duplicate word \u0026quot;convert\u0026quot; in comment trigger checkpatch warning](CVE-2026-45893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue-\u0026gt;state after sending an\nInitialization Connection Response (ICResp), but it does so without\nserializing against target-side queue teardown.\n\nIf an NVMe/TCP host sends an Initialization Connection Request\n(ICReq) and immediately closes the connection, target-side teardown\nmay start in softirq context before io_work drains the already\nbuffered ICReq. In that case, nvmet_tcp_schedule_release_queue()\nsets queue-\u0026gt;state to NVMET_TCP_Q_DISCONNECTING and drops the queue\nreference under state_lock.\n\nIf io_work later processes that ICReq, nvmet_tcp_handle_icreq() can\nstill overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the\nDISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and\nallows a later socket state change to re-enter teardown and issue a\nsecond kref_put() on an already released queue.\n\nThe ICResp send failure path has the same problem. If teardown has\nalready moved the queue to DISCONNECTING, a send error can still\noverwrite the state with NVMET_TCP_Q_FAILED, again reopening the\nwindow for a second teardown path to drop the queue reference.\n\nFix this by serializing both post-send state transitions with\nstate_lock and bailing out if teardown has already started.\n\nUse -ESHUTDOWN as an internal sentinel for that bail-out path rather\nthan propagating it as a transport error like -ECONNRESET. Keep\nnvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before\nhonoring that sentinel so receive-side parsing stays quiesced until the\nexisting release path completes.(CVE-2026-46135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: use list_del_rcu for netlink hooks\n\nnft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need\nto use list_del_rcu(), this list can be walked by concurrent dumpers.\n\nAdd a new helper and use it consistently.(CVE-2026-46324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: During rereg_mr ensure that REREG_ACCESS is compatible\n\nIf IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be\nre-evaluated to ensure it is properly pinned as RW. Since the umem is\nhidden inside each driver\u0026apos;s mr struct add a ib_umem_check_rereg() function\nthat each driver has to call before processing IB_MR_REREG_ACCESS.\n\nmlx4 has to retain its duplicate ib_access_writable check because it\nimplements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items\nin place sequentially while the MR is live, so it will continue to not\nsupport this combination.(CVE-2026-52908)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: serialize accept_q access\n\nbt_sock_poll() walks the accept queue without synchronization, while\nchild teardown can unlink the same socket and drop its last reference.\nThe unsynchronized accept queue walk has existed since the initial\nBluetooth import.\n\nProtect accept_q with a dedicated lock for queue updates and polling.\nAlso rework bt_accept_dequeue() to take temporary child references under\nthe queue lock before dropping it and locking the child socket.(CVE-2026-52918)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipc: limit next_id allocation to the valid ID range\n\nThe checkpoint/restore sysctl path can request the next SysV IPC id\nthrough ids-\u0026gt;next_id. ipc_idr_alloc() currently forwards that request to\nidr_alloc() with an open-ended upper bound.\n\nIf the valid tail of the SysV IPC id space is full, the allocation can\nspill beyond ipc_mni. The returned SysV IPC id still uses the normal\nindex encoding, so later lookup and removal can target the wrong slot. \nThis leaves the real IDR entry behind and breaks the IDR state for the\nobject.\n\nThe bug is in ipc_idr_alloc() in the checkpoint/restore path.\n\n1. ids-\u0026gt;next_id is passed to:\n\n idr_alloc(\u0026amp;ids-\u0026gt;ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)\n\n2. The zero upper bound makes the allocation effectively open-ended.\n Once the valid SysV IPC tail is occupied, idr_alloc() can spill past\n ipc_mni and allocate an entry beyond the valid IPC id range.\n\n3. The new object id is still encoded with the narrower SysV IPC index\n width:\n\n new-\u0026gt;id = (new-\u0026gt;seq \u0026lt;\u0026lt; ipcmni_seq_shift()) + idx\n\n4. Later removal goes through ipc_rmid(), which uses:\n\n ipcid_to_idx(ipcp-\u0026gt;id)\n\n That truncates the real IDR index. An object actually stored at a\n high index can then be removed as if it lived at a low in-range\n index.\n\n5. For shared memory, shm_destroy() frees the current object anyway, but\n the real high IDR slot is left behind as a dangling pointer.\n\n6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry\n and dereferences freed memory.\n\nPrevent this by bounding the requested allocation to ipc_mni so the\ncheckpoint/restore path fails once the valid range is exhausted.(CVE-2026-52923)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipc/shm: serialize orphan cleanup with shm_nattch updates\n\nshm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that\ndoes not serialize all fields tested by shm_may_destroy(). In particular,\nshm_nattch is updated while holding shm_perm.lock, and attach paths can do\nthat without holding the rwsem.\n\nDo not decide that an orphaned segment is unused before taking the object\nlock. Move the shm_may_destroy() check under shm_perm.lock, matching the\nother destroy paths, and unlock the segment when it no longer qualifies\nfor removal.(CVE-2026-52930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl\n\nWhile fuzzing with Syzkaller, a persistent `schedule_timeout: wrong\ntimeout value` warning was observed, accompanied by SMBus controller\nstate machine corruption.\n\nThe I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of\n10 ms. The user argument is checked against INT_MAX, but it is\nsubsequently multiplied by 10 before being passed to msecs_to_jiffies().\n\nA malicious user can pass a large value (e.g., 429496729) that passes\nthe `arg \u0026gt; INT_MAX` check but overflows when multiplied by 10. This\nresults in a truncated 32-bit unsigned value that bypasses the\ninternal `(int)m \u0026lt; 0` check in `msecs_to_jiffies()`.\n\nThe truncated value is then assigned to `client-\u0026gt;adapter-\u0026gt;timeout`\n(a signed 32-bit int), which is reinterpreted as a negative number.\nWhen passed to wait_for_completion_timeout(), this negative value\nundergoes sign extension to a 64-bit unsigned long, triggering the\n`schedule_timeout` warning and causing premature returns. This leaves\nthe SMBus state machine in an unrecoverable state, constituting a\nlocal Denial of Service (DoS).\n\nFix this by bounding the user argument to `INT_MAX / 10`.\n\n[wsa: move the comment as well](CVE-2026-52948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix oops due to out of scope access\n\nBelow oops triggers when kill QEMU process:\n\n Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI\n Call Trace:\n \u0026lt;TASK\u0026gt;\n do_raw_spin_lock+0xaa/0xc0\n _raw_spin_lock_irqsave+0x21/0x40\n domain_remove_dev_pasid+0x52/0x160\n intel_nested_set_dev_pasid+0x1b9/0x1e0\n __iommu_set_group_pasid+0x56/0x120\n pci_dev_reset_iommu_done+0xe3/0x180\n pcie_flr+0x65/0x160\n __pci_reset_function_locked+0x5b/0x120\n vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core]\n vfio_df_close+0x4f/0xa0\n vfio_df_unbind_iommufd+0x2d/0x60\n vfio_device_fops_release+0x3e/0x40\n __fput+0xe5/0x2c0\n task_work_run+0x58/0xa0\n do_exit+0x2c8/0x600\n do_group_exit+0x2f/0xa0\n get_signal+0x863/0x8c0\n arch_do_signal_or_restart+0x24/0x100\n exit_to_user_mode_loop+0x87/0x380\n do_syscall_64+0x2ff/0x11e0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe global static blocked domain is a dummy domain without corresponding\ndmar_domain structure, accessing beyond iommu_domain structure triggers\noops easily. Fix it by return early in domain_remove_dev_pasid() like\nidentity domain.(CVE-2026-52953)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size\n\nThe generic/642 test-case can reproduce the kernel crash:\n\n[40243.605254] ------------[ cut here ]------------\n[40243.605956] kernel BUG at fs/ceph/xattr.c:918!\n[40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI\n[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)\n[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[40243.611820] Workqueue: ceph-msgr ceph_con_workfn\n[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0\n[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc \u0026lt;0f\u0026gt; 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc\n[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287\n[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000\n[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000\n[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000\n[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000\n[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd\n[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000\n[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0\n[40243.627408] Call Trace:\n[40243.627839] \u0026lt;TASK\u0026gt;\n[40243.628188] __prep_cap+0x3fd/0x4a0\n[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0\n[40243.629474] ceph_check_caps+0x46a/0xc80\n[40243.630094] ? __lock_acquire+0x4a2/0x2650\n[40243.630773] ? find_held_lock+0x31/0x90\n[40243.631347] ? handle_cap_grant+0x79f/0x1060\n[40243.632068] ? lock_release+0xd9/0x300\n[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340\n[40243.633429] ? lock_release+0xd9/0x300\n[40243.634052] handle_cap_grant+0xcf6/0x1060\n[40243.634745] ceph_handle_caps+0x122b/0x2110\n[40243.635415] mds_dispatch+0x5bd/0x2160\n[40243.636034] ? ceph_con_process_message+0x65/0x190\n[40243.636828] ? lock_release+0xd9/0x300\n[40243.637431] ceph_con_process_message+0x7a/0x190\n[40243.638184] ? kfree+0x311/0x4f0\n[40243.638749] ? kfree+0x311/0x4f0\n[40243.639268] process_message+0x16/0x1a0\n[40243.639915] ? sg_free_table+0x39/0x90\n[40243.640572] ceph_con_v2_try_read+0xf58/0x2120\n[40243.641255] ? lock_acquire+0xc8/0x300\n[40243.641863] ceph_con_workfn+0x151/0x820\n[40243.642493] process_one_work+0x22f/0x630\n[40243.643093] ? process_one_work+0x254/0x630\n[40243.643770] worker_thread+0x1e2/0x400\n[40243.644332] ? __pfx_worker_thread+0x10/0x10\n[40243.645020] kthread+0x109/0x140\n[40243.645560] ? __pfx_kthread+0x10/0x10\n[40243.646125] ret_from_fork+0x3f8/0x480\n[40243.646752] ? __pfx_kthread+0x10/0x10\n[40243.647316] ? __pfx_kthread+0x10/0x10\n[40243.647919] ret_from_fork_asm+0x1a/0x30\n[40243.648556] \u0026lt;/TASK\u0026gt;\n[40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore\n[40243.654766] ---[ end trace 0000000000000000 ]---\n\nCommit d93231a6bc8a (\u0026quot;ceph: prevent a client from exceeding the MDS\nmaximum xattr size\u0026quot;) moved the required_blob_size computation to before\nthe __build_xattrs() call, introducing a race.\n\n__build_xattrs() releases and reacquires i_ceph_lock during execution.\nIn that window, handle_cap_grant() may update i_xattrs.blob with a\nnewer MDS-provided blob and bump i_xattrs.version. When\n__bui\n---truncated---(CVE-2026-52961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfsnotify: fix inode reference leak in fsnotify_recalc_mask()\n\nfsnotify_recalc_mask() fails to handle the return value of\n__fsnotify_recalc_mask(), which may return an inode pointer that needs\nto be released via fsnotify_drop_object() when the connector\u0026apos;s HAS_IREF\nflag transitions from set to cleared.\n\nThis manifests as a hung task with the following call trace:\n\n INFO: task umount:1234 blocked for more than 120 seconds.\n Call Trace:\n __schedule\n schedule\n fsnotify_sb_delete\n generic_shutdown_super\n kill_anon_super\n cleanup_mnt\n task_work_run\n do_exit\n do_group_exit\n\nThe race window that triggers the iref leak:\n\n Thread A (adding mark) Thread B (removing mark)\n \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n fsnotify_add_mark_locked():\n fsnotify_add_mark_list():\n spin_lock(conn-\u0026gt;lock)\n add mark_B(evictable) to list\n spin_unlock(conn-\u0026gt;lock)\n return\n\n /* ---- gap: no lock held ---- */\n\n fsnotify_detach_mark(mark_A):\n spin_lock(mark_A-\u0026gt;lock)\n clear ATTACHED flag on mark_A\n spin_unlock(mark_A-\u0026gt;lock)\n fsnotify_put_mark(mark_A)\n\n fsnotify_recalc_mask():\n spin_lock(conn-\u0026gt;lock)\n __fsnotify_recalc_mask():\n /* mark_A skipped: ATTACHED cleared */\n /* only mark_B(evictable) remains */\n want_iref = false\n has_iref = true /* not yet cleared */\n -\u0026gt; HAS_IREF transitions true -\u0026gt; false\n -\u0026gt; returns inode pointer\n spin_unlock(conn-\u0026gt;lock)\n /* BUG: return value discarded!\n * iput() and fsnotify_put_sb_watched_objects()\n * are never called */\n\nFix this by deferring the transition true -\u0026gt; false of HAS_IREF flag from\nfsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).(CVE-2026-52990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: unify lcn as u64 for 32-bit platforms\n\nAs sashiko reported [1], `lcn` was typed as `unsigned long` (or\n`unsigned int` sometimes), which is only 32 bits wide on 32-bit\nplatforms, which causes `(lcn \u0026lt;\u0026lt; lclusterbits)` to be truncated\nat 4 GiB.\n\nIn order to consolidate the logic, just use `u64` consistently\naround the codebase.\n\n[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com(CVE-2026-53015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix clone_alias() to use the original device\u0026apos;s devid\n\nCurrently clone_alias() assumes first argument (pdev) is always the\noriginal device pointer. This function is called by\npci_for_each_dma_alias() which based on topology decides to send\noriginal or alias device details in first argument.\n\nThis meant that the source devid used to look up and copy the DTE\nmay be incorrect, leading to wrong or stale DTE entries being\npropagated to alias device.\n\nFix this by passing the original pdev as the opaque data argument to\nboth the direct clone_alias() call and pci_for_each_dma_alias(). Inside\nclone_alias(), retrieve the original device from data and compute devid\nfrom it.(CVE-2026-53053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: kl5kusb105: fix bulk-out buffer overflow\n\nklsi_105_prepare_write_buffer() is called by the generic write path\nwith the bulk-out buffer and its size (bulk_out_size, 64 bytes). It\nstores a two-byte length header at the start of the buffer and copies\nthe payload from the write fifo starting at buf + KLSI_HDR_LEN, but\npasses the full buffer size as the number of bytes to copy:\n\n count = kfifo_out_locked(\u0026amp;port-\u0026gt;write_fifo, buf + KLSI_HDR_LEN,\n size, \u0026amp;port-\u0026gt;lock);\n\nWhen the fifo holds at least size bytes, size bytes are copied starting\ntwo bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its\nend. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for\nthe header as safe_serial already does.\n\nWriting bulk_out_size or more bytes to the tty triggers a slab\nout-of-bounds write, observed with KASAN by emulating the device with\ndummy_hcd and raw-gadget:\n\n BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0\n Write of size 64 at addr ffff888112c62202 by task python3\n kfifo_copy_out\n klsi_105_prepare_write_buffer [kl5kusb105]\n usb_serial_generic_write_start [usbserial]\n Allocated by task 139:\n usb_serial_probe [usbserial]\n The buggy address is located 2 bytes inside of allocated 64-byte region\n\nThe out-of-bounds write no longer occurs with this change applied.(CVE-2026-53194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: io_ti: fix heap overflow in get_manuf_info()\n\nget_manuf_info() reads le16_to_cpu(rom_desc-\u0026gt;Size) bytes from the\ndevice I2C EEPROM into a buffer allocated with kmalloc_obj(), which\nis sizeof(struct edge_ti_manuf_descriptor) = 10 bytes.\n\nThe Size field comes from the device and is only validated (in\ncheck_i2c_image()) to make sure the descriptor fits within\nTI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size.\nA malicious USB device can therefore set Size to any value up to 16377,\ncausing a heap overflow of up to 16367 bytes when plugged into a host\nrunning this driver.\n\nvalid_csum() is called after read_rom() and also iterates\nbuffer[0..Size-1], compounding the out-of-bounds access.\n\nFix by rejecting descriptors with unexpected length before calling\nread_rom().\n\n[ johan: amend commit message; also check for short descriptors ](CVE-2026-53196)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()\n\npppol2tp_ioctl() read sock-\u0026gt;sk-\u0026gt;sk_user_data directly without any\nlocks or reference counting. If a controllable sleep was induced during\ncopy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent\nsocket close could trigger pppol2tp_session_close() asynchronously. This\nfrees the l2tp_session structure via the l2tp_session_del_work workqueue.\nUpon resuming, the ioctl thread dereferences the stale session pointer,\nresulting in a Use-After-Free (UAF).\n\nFix this by securely fetching the session reference using the RCU-safe,\nrefcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the\nsession\u0026apos;s refcount across the sleep. We structured the function to exit\nvia standard err breaks, guaranteeing that l2tp_session_put() is cleanly\ncalled on all return paths to drop the reference.\n\nTo preserve existing behavior we validate the session and its magic\nsignature only for the specific L2TP commands that require it. This\nensures that generic/unknown ioctls called on an unconnected socket\nstill return -ENOIOCTLCMD and correctly fall back to generic handlers\n(e.g. in sock_do_ioctl()).(CVE-2026-53262)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED\n\n[Why]\ndcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with\nDC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(),\nwhich disables local softirqs.\n\nThe DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to\nallocate ~335 KiB for dc_plane_state. This triggers the vmalloc path,\nwhich calls BUG_ON(in_interrupt()) because it\u0026apos;s invoked within the\nFPU-enabled (softirq disabled) region, leading to a kernel crash.\n\n[How]\nWrap the dc_state_create_phantom_plane() call with the\nDC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during\nthis memory allocation.\n\n(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)(CVE-2026-53285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths\n\nIn dc_dmub_srv_log_diagnostic_data() and\ndc_dmub_srv_enable_dpia_trace().\n\nBoth functions check:\n\n if (!dc_dmub_srv || !dc_dmub_srv-\u0026gt;dmub)\n\nand then call DC_LOG_ERROR() inside that block.\n\nDC_LOG_ERROR() uses dc_dmub_srv-\u0026gt;ctx internally. So if\ndc_dmub_srv is NULL, the logging itself can dereference a\nNULL pointer and cause a crash.\n\nFix this by splitting the checks.\n\nFirst check if dc_dmub_srv is NULL and return immediately.\nThen check dc_dmub_srv-\u0026gt;dmub and log the error only when\ndc_dmub_srv is valid.\n\nFixes the below:\n../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed \u0026apos;dc_dmub_srv\u0026apos; could be null (see line 961)\n../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed \u0026apos;dc_dmub_srv\u0026apos; could be null (see line 1166)(CVE-2026-53313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Put CPU offline callback in ONLINE section to allow failure\n\nsyzbot reported the following warning:\n\n DEAD callback error for CPU1\n WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614\n\nat commit 4ae12d8bd9a8 (\u0026quot;Merge tag \u0026apos;kbuild-fixes-7.0-2\u0026apos; of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux\u0026quot;)\nwhich tglx traced to padata_cpu_dead() given it\u0026apos;s the only\nsub-CPUHP_TEARDOWN_CPU callback that returns an error.\n\nFailure isn\u0026apos;t allowed in hotplug states before CPUHP_TEARDOWN_CPU\nso move the CPU offline callback to the ONLINE section where failure is\npossible.(CVE-2026-53314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: Fix driver removal with disabled KMS\n\nDRM atomic and modesetting aren\u0026apos;t initialized if virtio-gpu driver built\nwith disabled KMS, leading to access of uninitialized data on driver\nremoval/unbinding and crashing kernel. Fix it by skipping shutting down\natomic core with unavailable KMS.(CVE-2026-53347)",
"id": "OESA-2026-3454",
"modified": "2026-08-20T09:59:30Z",
"published": "2026-08-20T09:59:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3454"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52953"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53347"
}
],
"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-2026-43153",
"CVE-2026-43331",
"CVE-2026-45893",
"CVE-2026-46135",
"CVE-2026-46324",
"CVE-2026-52908",
"CVE-2026-52918",
"CVE-2026-52923",
"CVE-2026-52930",
"CVE-2026-52948",
"CVE-2026-52953",
"CVE-2026-52961",
"CVE-2026-52990",
"CVE-2026-53015",
"CVE-2026-53053",
"CVE-2026-53194",
"CVE-2026-53196",
"CVE-2026-53262",
"CVE-2026-53285",
"CVE-2026-53313",
"CVE-2026-53314",
"CVE-2026-53347"
]
}
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.