{"id":"OESA-2026-4358","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\nerofs: fix inline data read failure for ztailpacking pclusters\n\nCompressed folios for ztailpacking pclusters must be valid before adding\nthese pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster()\nmay assume they are already valid and then trigger a NULL pointer\ndereference.\n\nIt is somewhat hard to reproduce because the inline data is in the same\nblock as the tail of the compressed indexes, which are usually read just\nbefore. However, it may still happen if a fatal signal arrives while\nread_mapping_folio() is running, as shown below:\n\n erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n\n ...\n\n pc : z_erofs_decompress_queue+0x4c8/0xa14\n lr : z_erofs_decompress_queue+0x160/0xa14\n sp : ffffffc08b3eb3a0\n x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000\n x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001\n x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700\n x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098\n x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004\n x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9\n x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f\n x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020\n x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  z_erofs_decompress_queue+0x4c8/0xa14\n  z_erofs_runqueue+0x908/0x97c\n  z_erofs_read_folio+0x128/0x228\n  filemap_read_folio+0x68/0x128\n  filemap_get_pages+0x44c/0x8b4\n  filemap_read+0x12c/0x5b8\n  generic_file_read_iter+0x4c/0x15c\n  do_iter_readv_writev+0x188/0x1e0\n  vfs_iter_read+0xac/0x1a4\n  backing_file_read_iter+0x170/0x34c\n  ovl_read_iter+0xf0/0x140\n  vfs_read+0x28c/0x344\n  ksys_read+0x80/0xf0\n  __arm64_sys_read+0x24/0x34\n  invoke_syscall+0x60/0x114\n  el0_svc_common+0x88/0xe4\n  do_el0_svc+0x24/0x30\n  el0_svc+0x40/0xa8\n  el0t_64_sync_handler+0x70/0xbc\n  el0t_64_sync+0x1bc/0x1c0\n\nFix this by reading the inline data before allocating and adding\nthe pclusters to the I/O chains.(CVE-2026-45943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()\n\nIn amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM,\nthe function returns directly without releasing the allocated xcc_info,\nresulting in a memory leak.\n\nFix this by ensuring that xcc_info is properly freed in the error paths.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-45947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: core - use RCU and work_struct to fix race condition\n\nCurrently, hwrng_fill is not cleared until the hwrng_fillfn() thread\nexits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex\nlock, a concurrent hwrng_unregister() may call kthread_stop() again on\nthe same task.\n\nAdditionally, if hwrng_unregister() is called immediately after\nhwrng_register(), the stopped thread may have never been executed. Thus,\nhwrng_fill remains dirty even after hwrng_unregister() returns. In this\ncase, subsequent calls to hwrng_register() will fail to start new\nthreads, and hwrng_unregister() will call kthread_stop() on the same\nfreed task. In both cases, a use-after-free occurs:\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0\nCall Trace:\n kthread_stop+0x181/0x360\n hwrng_unregister+0x288/0x380\n virtrng_remove+0xe3/0x200\n\nThis patch fixes the race by protecting the global hwrng_fill pointer\ninside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only\nonce, and calls to kthread_run() and kthread_stop() are serialized\nwith the lock held.\n\nTo avoid deadlock in hwrng_fillfn() while being stopped with the lock\nheld, we convert current_rng to RCU, so that get_current_rng() can read\ncurrent_rng without holding the lock. To remove the lock from put_rng(),\nwe also delay the actual cleanup into a work_struct.\n\nSince get_current_rng() no longer returns ERR_PTR values, the IS_ERR()\nchecks are removed from its callers.\n\nWith hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no\nlonger clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns\ndirectly after current_rng is dropped, kthread_stop() would be called on\na freed task_struct later. To fix this, hwrng_fillfn() calls schedule()\nnow to keep the task alive until being stopped. The kthread_stop() call\nis also moved from hwrng_unregister() to drop_current_rng(), ensuring\nkthread_stop() is called on all possible paths where current_rng becomes\nNULL, so that the thread would not wait forever.(CVE-2026-45949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus' match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53115)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvdpa: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus' match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/mbcache: cancel shrink work before destroying the cache\n\nmb_cache_destroy() calls shrinker_free() and then frees all cache\nentries and the cache itself, but it does not cancel the pending\nc_shrink_work work item first.\n\nIf mb_cache_entry_create() schedules c_shrink_work via schedule_work()\nand the work item is still pending or running when mb_cache_destroy()\nruns, mb_cache_shrink_worker() will access the cache after its memory\nhas been freed, causing a use-after-free.\n\nThis is only reachable by a privileged user (root or CAP_SYS_ADMIN)\nwho can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem.\n\nCancel the work item with cancel_work_sync() before calling\nshrinker_free(), ensuring the worker has finished and will not be\nrescheduled before the cache is torn down.(CVE-2026-53129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Bound VBIOS record-chain walk loops\n\n[Why & How]\nAll record-chain walk loops in bios_parser.c and bios_parser2.c use\nfor(;;) and only terminate on a 0xFF record_type sentinel or zero\nrecord_size. A malformed VBIOS image missing the terminator record\ncauses unbounded iteration at probe time, potentially hundreds of\nthousands of iterations with record_size=1. In the final iterations\nnear the BIOS image boundary, struct casts beyond the 2-byte header\nvalidated by GET_IMAGE can also read out of bounds.\n\nCap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256)\niterations. The atombios.h defines up to 22 distinct record types\nand atomfirmware.h has 13. Assuming an average of less than 10\nrecords per type (which is reasonable since most are connector-\nbased) 256 is a generous upper bound.\n\n(cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)(CVE-2026-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix use-after-free on sbi->sync_decompress\n\nz_erofs_decompress_kickoff() can race with filesystem unmount, causing\na use-after-free on sbi->sync_decompress.\n\nWhen I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff()\nto queue z_erofs_decompressqueue_work() asynchronously. Then, after all\nfolios are unlocked, unmount workflow can proceed and sbi will be freed\nbefore accessing to sbi->sync_decompress.\n\nThread (unmount)        I/O completion        kworker\n                        queue_work\n                                              z_erofs_decompressqueue_work\n                                               (all folios are unlocked)\ncleanup_mnt\n ..\n erofs_kill_sb\n  erofs_sb_free\n   kfree(sbi)\n                        access sbi->sync_decompress  // UAF!!(CVE-2026-53272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying\n\nWhen marking a page dirty, complain about not having a running/loaded vCPU\nif and only if the VM is still alive, i.e. its refcount is non-zero.  This\nwill allow fixing a memory leak for x86 SEV-ES guests without hitting what\nis effectively a false positive on the WARN.\n\nFor some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page\nacross an exit to userspace, and typically unmaps the page on the next\nKVM_RUN.  But if userspace never calls KVM_RUN after such an exit, then KVM\nneeds to unmap the page when the vCPU is destroyed, which in turn triggers\nthe WARN about not having a running vCPU.\n\nAlternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,\nas is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;\nsuppressing WARN from nested_put_vmcs12_pages() is pure happenstance).  But\nloading a vCPU during destruction is gross (ideally nVMX code would be\ncleaned up), risks complicating the SEV-ES code (KVM would need to ensure\nthe temporarily load()+put() only runs when the vCPU isn't already loaded),\nand is ultimately pointless.\n\nThe motivation for the WARN is to guard against KVM dirtying guest memory\nwithout pushing the corresponding GFN to the active vCPU's dirty ring, e.g.\nto ensure userspace doesn't miss a dirty page.  But for the VM's refcount\nto reach zero, there can't be _any_ userspace mappings to the dirty ring,\nas mapping the dirty ring requires doing mmap() on the vCPU FD.  I.e. if\nuserspace had a valid mapping for the dirty ring, then the vCPU file and\nthus the owning VM would still be alive.  And so since userspace can't\npossibly reach the dirty ring, whether or not KVM technically "misses" a\npush to the dirty ring is irrelevant.(CVE-2026-53345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: don't leak bad clone into future transaction\n\nOn memory allocation failure the cloned nft_pipapo_match can enter a bad\nstate:\n - some fields can have their lookup tables resized while others did\n   not\n - bits might have been toggled\n - scratch map can be undersized which also means m->bsize_max can be\n   lower than what is required\n\nThis means that the next insertion in the same batch can trigger\nout-of-bounds writes.\n\nFurthermore, a failure in the first can result in the bad clone to\nleak into the next transaction because the abort callback is never\nexecuted in this case (the upper layer saw an error and no attempt to\nallocate a transactional request was made).\n\nRecord a state for the nft_pipapo_match structure:\n- NEW (pristine clone)\n- MOD (modified clone with good state)\n- ERR (potentially bogus content)\n\nThen make it so that deletes and insertions fail when the clone\nentered ERR state.\n\nIn case the very first insert attempt results in an error, free the\nclone right away.(CVE-2026-72252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: Shut down rtpoll_timer in psi_cgroup_free()\n\npsi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath\nand can race psi_trigger_destroy() taking down the last rtpoll trigger under\nrtpoll_trigger_lock:\n\n  psi_schedule_rtpoll_work()        psi_trigger_destroy()\n\n  rcu_read_lock();\n  task = rcu_dereference(rtpoll_task);\n                                    rcu_assign_pointer(rtpoll_task, NULL);\n                                    timer_delete(&rtpoll_timer);\n  mod_timer(&rtpoll_timer, ...);\n  rcu_read_unlock();\n                                    synchronize_rcu();\n                                    kthread_stop(task_to_destroy);\n\nThe group can then be freed with the re-armed timer still pending, and\npoll_timer_fn() runs on freed memory.\n\n461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling\nmechanism") deleted the timer synchronously after the synchronize_rcu(),\nwhich prevented this but raced trigger creation instead: the deletion could\ncancel the timer that a new trigger set armed during the grace period and,\nas creation also reinitialized the timer at the time, corrupt it.\n8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the\ninitialization into group_init() and the deletion into the locked section,\ntrading the creation races for the window above.\n\nNeither placement in the destruction path works. A pending timer firing\nwhile the group is alive is harmless though. poll_timer_fn() just wakes the\nrtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's\nlifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it\nby then. timer_shutdown_sync() because the timer is never armed again.(CVE-2026-74594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: Fix accept list UAF during suspend\n\nhci_update_event_filter_sync() walks hdev->accept_list while sending a\nsynchronous HCI command for each remote-wakeup device.  The suspend path\nholds hdev->req_lock, but accept-list updates are serialized by hdev->lock.\nConsequently, remove_device() can free the current list entry during the\ncontroller wait.\n\nThe following interleaving causes the use-after-free:\n\n  hci_update_event_filter_sync()    remove_device()\n  fetch accept-list entry\n  hci_set_event_filter_sync()\n    wait for controller response    hci_dev_lock()\n                                    list_del()\n                                    kfree()\n                                    hci_dev_unlock()\n  read the freed list.next\n\nKASAN reported:\n\n  BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910\n  Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10\n  Workqueue: events vhci_suspend_work\n  Call Trace:\n   hci_suspend_sync+0x835/0x910\n   hci_suspend_dev+0x182/0x450\n   process_one_work+0x661/0x1090\n   worker_thread+0x45b/0xd10\n\n  Allocated by task 86:\n   hci_bdaddr_list_add_with_flags+0x1a8/0x400\n   add_device+0x381/0x820\n   hci_sock_sendmsg+0x1033/0x1ea0\n\n  Freed by task 91:\n   kfree+0x131/0x3c0\n   remove_device+0x429/0xb70\n   hci_sock_sendmsg+0x1033/0x1ea0\n\nSnapshot the remote-wakeup addresses under hdev->lock.  Release the lock\nbefore sending HCI commands.  Clear the controller event filter before\nbuilding the snapshot, and skip allocation and the second list traversal\nwhen there are no matching entries.  This preserves the original filter\nand scan-state updates without retaining an accept-list node across a\ncontroller wait.(CVE-2026-80762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Wrap user-invoked calls to fb_set_var() in helper\n\nHandle fbcon during display updates in fb_set_var_from_user(). Check\nwith fbcon if the mode change is possible, update hardware state and\nfinally update fbcon. Update all callers.\n\nOnly the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other\nmode-changes callers in sysfs and driver code are missing fbcon-related\nsteps.\n\nWith the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain\nfbcon state themselves.(CVE-2026-80786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix OOB in free_rd_atomic_resources()\n\nfree_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic.\nUpdating max_dest_rd_atomic before freeing the old array can make the\nfree path walk past the old allocation and trigger a slab out-of-bounds\nwrite catched by KASAN:\n==================================================================\nBUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline]\nBUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline]\nBUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline]\nBUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712\nWrite of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063\n\nCPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full)\nHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xf7/0x600 mm/kasan/report.c:482\n kasan_report+0xe4/0x120 mm/kasan/report.c:595\n free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline]\n free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline]\n free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline]\n rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712\n rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623\n ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625\n _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915\n modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932\n ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958\n ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680\n vfs_write+0x2aa/0x1070 fs/read_write.c:686\n ksys_write+0x1f8/0x250 fs/read_write.c:740\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fefc75a70cd\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd\nRDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007\nRBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0\n </TASK>\n\nAllocated by task 11063:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:57\n kasan_save_track+0x14/0x30 mm/kasan/common.c:78\n poison_kmalloc_redzone mm/kasan/common.c:398 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415\n kasan_kmalloc include/linux/kasan.h:263 [inline]\n __do_kmalloc_node mm/slub.c:5296 [inline]\n __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308\n kmalloc_noprof include/linux/slab.h:954 [inline]\n kzalloc_noprof include/linux/slab.h:1188 [inline]\n alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline]\n rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714\n rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623\n ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625\n _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915\n modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932\n ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958\n ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma\n---truncated---(CVE-2026-80863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp\n\nrxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the\nIB_QP_STATE path, so it holds no state_lock and runs while the responder\ntask rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting\nonly that attribute calls free_rd_atomic_resources() then\nalloc_rd_atomic_resources(), swapping qp->resp.resources[] while\nrxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources()\nalso leaves the cached pointer qp->resp.res dangling. A local\nunprivileged user can race the free/realloc into a use-after-free in\nrxe_receiver() (local DoS).\n\nDrain recv_task around the swap with rxe_disable_task()/rxe_enable_task(),\nas rxe_qp_reset() already does when tearing this array down, re-enabling\nonly after alloc_rd_atomic_resources() succeeds so the responder never\nresumes against a NULL qp->resp.resources on the ENOMEM path. Also clear\nqp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c\ncompletion paths.\n\nReproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.(CVE-2026-80864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready\n\niso_conn_ready() looks up the BIS listener socket with iso_get_sock(),\nwhich takes a reference, and then, without re-checking its state,\ncreates a child socket from it:\n\n    parent = iso_get_sock(hdev, ...);\n    if (!parent)\n        return;\n\n    lock_sock(parent);\n    sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...);\n    ...\n    iso_chan_add(conn, sk, parent);\n    ...\n    release_sock(parent);\n    sock_put(parent);\n\nIf the listener socket is closed concurrently, between iso_get_sock()\nand lock_sock(), the reference taken by iso_get_sock() may be the last\none: the close path drops the link-list reference, and once\niso_conn_ready() drops its own reference at the end of the function the\nsocket is freed.  The child socket, however, is already linked to the\nfreed parent, and a later disconnect of the child runs iso_chan_del()\n-> bt_accept_unlink(), which dereferences the dangling parent pointer\ninto the freed accept queue (a use-after-free).  The same dangling\npointer is also dereferenced through parent->***() in\niso_chan_del().\n\nFix it the same way the connected (non-BIS) path was fixed in commit\n0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"):\nafter taking the socket lock, re-check that the parent is still a\nlistening, alive socket, and bail out otherwise.(CVE-2026-80914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: ssd1307fb: defer I2C transfers from damage callbacks\n\nThe fbdev damage callbacks may run from fbcon while printk has disabled\npreemption.  They currently update the display synchronously, which enters\nthe sleeping I2C transfer path from atomic context.\n\nA complete report from an RK3566 system follows:\n\n  [  258.129004] watchdog: watchdog0: watchdog did not stop!\n  [  258.129067] BUG: scheduling while atomic: systemd/1/0x00000003\n  [  258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep\n  binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart\n  fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card\n  motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1\n  ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb\n  brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm\n  snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine\n  v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2\n  spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem\n  videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2\n  stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio\n  stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables\n  x_tables autofs4\n  [  258.129215] Preemption disabled at:\n  [  258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340\n  [  258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G         C\n  6.6.0-rc5-rockchip-rk356x #4\n  [  258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT)\n  [  258.129243] Call trace:\n  [  258.129245]  dump_backtrace+0xa0/0x128\n  [  258.129252]  show_stack+0x20/0x38\n  [  258.129256]  dump_stack_lvl+0x60/0xb0\n  [  258.129265]  dump_stack+0x18/0x28\n  [  258.129269]  __schedule_bug+0xa0/0xc8\n  [  258.129274]  __schedule+0x9ac/0xd30\n  [  258.129279]  schedule+0x60/0x100\n  [  258.129282]  schedule_timeout+0x194/0x338\n  [  258.129289]  rk3x_i2c_xfer_common.isra.0+0x384/0x498\n  [  258.129296]  rk3x_i2c_xfer+0x20/0x60\n  [  258.129300]  __i2c_transfer+0x194/0x648\n  [  258.129308]  i2c_transfer+0x9c/0x130\n  [  258.129313]  i2c_transfer_buffer_flags+0x64/0x98\n  [  258.129318]  ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb]\n  [  258.129334]  ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb]\n  [  258.129343]  soft_cursor+0x13c/0x210\n  [  258.129350]  bit_cursor+0x2dc/0x550\n  [  258.129354]  fbcon_cursor+0xec/0x108\n  [  258.129359]  hide_cursor+0x44/0xc8\n  [  258.129365]  vt_console_print+0x398/0x3b0\n  [  258.129370]  console_flush_all.isra.0+0x17c/0x410\n  [  258.129377]  console_unlock+0x4c/0x100\n  [  258.129382]  vprintk_emit+0x1c8/0x340\n  [  258.129386]  vprintk_default+0x40/0x58\n  [  258.129389]  vprintk+0xb8/0xd0\n  [  258.129392]  _printk+0x68/0x98\n  [  258.129398]  watchdog_release+0x170/0x230\n  [  258.129404]  __fput+0xbc/0x288\n  [  258.129409]  __fput_sync+0x58/0x70\n  [  258.129413]  __arm64_sys_close+0x40/0x90\n  [  258.129419]  invoke_syscall+0x4c/0x118\n  [  258.129426]  el0_svc_common.constprop.0+0x48/0xf0\n  [  258.129432]  do_el0_svc+0x24/0x38\n  [  258.129437]  el0_svc+0x48/0x100\n  [  258.129443]  el0t_64_sync_handler+0xc0/0xc8\n  [  258.129448]  el0t_64_sync+0x190/0x198\n  [  258.573087] ------------[ cut here ]------------\n  [  258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count())\n  [  258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871\n  preempt_count_sub+0x9c/0x148\n  [  258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep\n  binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart\n  fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card\n  motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1\n  ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb\n  brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm\n  snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine\n  v4l2_vp\n---truncated---(CVE-2026-89598)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventfs: Initialize ei->children and ei->list in init_ei()\n\neventfs_create_dir() allocates the eventfs_inode and initializes it with\ninit_ei(). But this does not initialize the eventfs_inode list_heads. If\nthe eventfs_create_dir() fails due to memory pressure, it will call\nfree_ei() before it initialized the lists, and that checks to make sure\nthe eventfs_inode has no children. But because the list wasn't\ninitialized, it will give a false warning.\n\nFix it by moving the list initialization into init_ei().\n\n[ Rewrote change log ](CVE-2026-89618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix ALIGN() overflow in symlink_data() error context loop\n\nThe check added by commit 7d9a7f1f96cd ("smb/client: fix possible\ninfinite loop and oob read in symlink_data()") compared the post-ALIGN\nlength against the remaining buffer, but ALIGN() itself can overflow:\nfor ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8)\nwraps to 0, so the subsequent bounds check passes, and the loop\nadvances by zero bytes leaving 'p' pointing into stale data.\n\nFix by checking the raw ErrorDataLength against the remaining space\nbefore applying ALIGN(), then checking again after.  Since raw_len is\nbounded by the buffer, raw_len + 7 cannot overflow, so the second check\nis an exact post-alignment bounds guard.(CVE-2026-89634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2\n\nWhen a valid primary TRANSACT2 response has been received (mid->resp_buf\nset, mid->multiRsp true) and a subsequent secondary response causes\ncifs_check_trans2() to return false -- either because the SMB header is\ninvalid (malformed != 0) or because check2ndT2() rejects the PDU --\nhandle_mid() overwrites mid->resp_buf with the new buffer (leaking the\nprimary buffer) and, because mid->multiRsp is set, skips the\nserver->smallbuf/bigbuf NULL-out.  When the user thread frees\nmid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the\ndemux thread reuses it for the next packet, resulting in a use-after-free.\n\nCombine both early-exit conditions and, when mid->multiRsp is already\nset, abort the pending transaction inline: set multiEnd, call\ndequeue_mid() with malformed=true, and return true so handle_mid() exits\nwithout touching mid->resp_buf or the server buffer pointers.(CVE-2026-89637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound copied dentry name length in NFS export get_name\n\nceph_get_name() copies the MDS-supplied name into the caller's\nNAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len)\nand then writes name[rinfo->dname_len] = 0, without checking dname_len\nagainst NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply\nwith dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies\nrde->name / rde->name_len the same unchecked way.\n\nImpact: a malicious or compromised Ceph MDS overflows the NAME_MAX name\nbuffer in a client's NFS-export get_name path, a slab out-of-bounds write\nreported by KASAN. Reachable when a CephFS mount is re-exported over NFS.\n\nAdd ceph_export_copy_name(), which rejects lengths above NAME_MAX with\n-ENAMETOOLONG before the copy, and use it in both ceph_get_name() and\n__get_snap_name().(CVE-2026-89652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock\n\nlist_for_each_entry() iterates ci->i_cap_flush_list but drops\ni_ceph_lock to send cap messages.  During the unlock window,\nhandle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries\nwith tid <= flush_tid from the list, release i_ceph_lock, and free\nthem via ceph_free_cap_flush() outside any lock.  When the original\nthread reacquires i_ceph_lock and the for-loop macro advances via\ncf = list_next_entry(cf, i_list), it dereferences cf->i_list.next\non freed memory.\n\nThe race timeline:\n\n  __kick_flushing_caps()              handle_cap_flush_ack()\n  -----------------------             -----------------------\n  holds i_ceph_lock        <---\n  iterates to cf (tid=10)\n  prepares FLUSH message\n  drops i_ceph_lock        <---\n  __send_cap() ── FLUSH(tid=10)\n\t                              MDS sends FLUSH_ACK(tid=10)\n                           --->       acquires i_ceph_lock\n                                      cf->tid(10) <= flush_tid(10),\n                                      detaches cf from i_cap_flush_list\n                                      drops i_ceph_lock\n                                      ceph_free_cap_flush(cf) <- frees it!\n  acquires i_ceph_lock     <---\n  for-loop advances:\n    cf = list_next_entry(cf, i_list)\n      -- UAF on freed cf->i_list.next\n\nThe cf was just sent by __kick_flushing_caps itself via __send_cap().\nThe MDS may respond with FLUSH_ACK quickly enough that\nhandle_cap_flush_ack() frees cf before __kick_flushing_caps can\nfinish the iteration.\n\nFix by converting to a manual while loop: save the next pointer\nunder i_ceph_lock before dropping it, then use the saved pointer\nafter reacquiring, so the potentially-freed cf is never accessed again.(CVE-2026-89655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix crash passing ERR_PTR to kthread_stop()\n\nevent_test_stuff() calls kthread_run() and unconditionally passes the\nreturned task_struct pointer to kthread_stop(). kthread_run() returns an\nerror pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for\nexample under memory pressure during the boot-time event self-test.\nkthread_stop() then dereferences the invalid pointer, crashing the kernel.\n\nCheck the result of kthread_run() before passing it to kthread_stop(). Use\nWARN_ON() so that a failure to create the self-test thread does not go\nunnoticed, matching the ring-buffer self-test fix in commit\n91542863abad ("ring-buffer: Fix crash passing ERR_PTR to kthread_stop()").(CVE-2026-89749)","modified":"2026-10-16T12:15:11.608903650Z","published":"2026-10-16T11:59:45Z","upstream":["CVE-2026-45943","CVE-2026-45947","CVE-2026-45949","CVE-2026-53115","CVE-2026-53118","CVE-2026-53129","CVE-2026-53138","CVE-2026-53272","CVE-2026-53345","CVE-2026-72252","CVE-2026-74594","CVE-2026-80762","CVE-2026-80786","CVE-2026-80863","CVE-2026-80864","CVE-2026-80914","CVE-2026-89598","CVE-2026-89618","CVE-2026-89634","CVE-2026-89637","CVE-2026-89652","CVE-2026-89655","CVE-2026-89749"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4358"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45943"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53115"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53129"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53138"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53272"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53345"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72252"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74594"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80762"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80786"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80864"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89598"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89618"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89634"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89749"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.28.165.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-145.1.28.165.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.28.165.oe2403sp1.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-4358.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}