{"schema_version":"1.7.2","id":"OESA-2026-3454","modified":"2026-08-20T09:59:30Z","published":"2026-08-20T09:59:30Z","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"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\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'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 & Optimize table creation from possibly unaligned memory\n\nSource blob may come from userspace and might be unaligned.\nTry to optize the copying process by avoiding unaligned memory accesses.\n\n- Added Fixes tag\n- Added "Fix &" to description as this doesn't just optimize but fixes\n        a potential unaligned memory access\n[jj: remove duplicate word "convert" in comment trigger checkpatch warning](CVE-2026-45893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue->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->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'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->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->next_id is passed to:\n\n       idr_alloc(&ids->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->id = (new->seq << ipcmni_seq_shift()) + idx\n\n4. Later removal goes through ipc_rmid(), which uses:\n\n       ipcid_to_idx(ipcp->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 > INT_MAX` check but overflows when multiplied by 10. This\nresults in a truncated 32-bit unsigned value that bypasses the\ninternal `(int)m < 0` check in `msecs_to_jiffies()`.\n\nThe truncated value is then assigned to `client->adapter->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   <TASK>\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 <0f> 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]  <TASK>\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]  </TASK>\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 ("ceph: prevent a client from exceeding the MDS\nmaximum xattr size") 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'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  ──────────────────────              ────────────────────────\n  fsnotify_add_mark_locked():\n    fsnotify_add_mark_list():\n      spin_lock(conn->lock)\n      add mark_B(evictable) to list\n      spin_unlock(conn->lock)\n    return\n\n    /* ---- gap: no lock held ---- */\n\n                                      fsnotify_detach_mark(mark_A):\n                                        spin_lock(mark_A->lock)\n                                        clear ATTACHED flag on mark_A\n                                        spin_unlock(mark_A->lock)\n                                        fsnotify_put_mark(mark_A)\n\n    fsnotify_recalc_mask():\n      spin_lock(conn->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        -> HAS_IREF transitions true -> false\n        -> returns inode pointer\n      spin_unlock(conn->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 -> 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 << 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'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(&port->write_fifo, buf + KLSI_HDR_LEN,\n                           size, &port->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->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->sk->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'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'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->dmub)\n\nand then call DC_LOG_ERROR() inside that block.\n\nDC_LOG_ERROR() uses dc_dmub_srv->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->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 'dc_dmub_srv' could be null (see line 961)\n../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)\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 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux")\nwhich tglx traced to padata_cpu_dead() given it's the only\nsub-CPUHP_TEARDOWN_CPU callback that returns an error.\n\nFailure isn'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'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)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.22.159.oe2403sp1"}]}],"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"]}}],"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"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}