{"schema_version":"1.7.2","id":"OESA-2026-1306","modified":"2026-02-06T15:57:05Z","published":"2026-02-06T15:57:05Z","upstream":["CVE-2023-53254","CVE-2023-53309","CVE-2023-53519","CVE-2023-53715","CVE-2023-53847","CVE-2023-54168","CVE-2023-54186","CVE-2023-54294","CVE-2023-54317","CVE-2025-38499","CVE-2025-38572","CVE-2025-38618","CVE-2025-40178","CVE-2025-40271"],"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\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix integer overflow in radeon_cs_parser_init\n\nThe type of size is unsigned, if size is 0x40000000, there will be an\ninteger overflow, size will be zero after size *= sizeof(uint32_t),\nwill cause uninitialized memory to be referenced later(CVE-2023-53309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report&]\n\nkworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c(CVE-2023-53519)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex\n\nApparently the hex passphrase mechanism does not work on newer\nchips/firmware (e.g. BCM4387). It seems there was a simple way of\npassing it in binary all along, so use that and avoid the hexification.\n\nOpenBSD has been doing it like this from the beginning, so this should\nwork on all chips.\n\nAlso clear the structure before setting the PMK. This was leaking\nuninitialized stack contents to the device.(CVE-2023-53715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb-storage: alauda: Fix uninit-value in alauda_check_media()\n\nSyzbot got KMSAN to complain about access to an uninitialized value in\nthe alauda subdriver of usb-storage:\n\nBUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0\ndrivers/usb/storage/alauda.c:1137\nCPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n  __dump_stack lib/dump_stack.c:77 [inline]\n  dump_stack+0x191/0x1f0 lib/dump_stack.c:113\n  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108\n  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250\n  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460\n\nThe problem is that alauda_check_media() doesn't verify that its USB\ntransfer succeeded before trying to use the received data.  What\nshould happen if the transfer fails isn't entirely clear, but a\nreasonably conservative approach is to pretend that no media is\npresent.\n\nA similar problem exists in a usb_stor_dbg() call in\nalauda_get_media_status().  In this case, when an error occurs the\ncall is redundant, because usb_stor_ctrl_transfer() already will print\na debugging message.\n\nFinally, unrelated to the uninitialized memory access, is the fact\nthat alauda_check_media() performs DMA to a buffer on the stack.\nFortunately usb-storage provides a general purpose DMA-able buffer for\nuses like this.  We'll use it instead.(CVE-2023-53847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Prevent shift wrapping in set_user_sq_size()\n\nThe ucmd->log_sq_bb_count variable is controlled by the user so this\nshift can wrap.  Fix it by using check_shl_overflow() in the same way\nthat it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined\nbehavior in hns_roce_set_user_sq_size()").(CVE-2023-54168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmodes/displayport: fix pin_assignment_show\n\nThis patch fixes negative indexing of buf array in pin_assignment_show\nwhen get_current_pin_assignments returns 0 i.e. no compatible pin\nassignments are found.\n\nBUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c\n...\nCall trace:\ndump_backtrace+0x110/0x204\ndump_stack_lvl+0x84/0xbc\nprint_report+0x358/0x974\nkasan_report+0x9c/0xfc\n__do_kernel_fault+0xd4/0x2d4\ndo_bad_area+0x48/0x168\ndo_tag_check_fault+0x24/0x38\ndo_mem_abort+0x6c/0x14c\nel1_abort+0x44/0x68\nel1h_64_sync_handler+0x64/0xa4\nel1h_64_sync+0x78/0x7c\npin_assignment_show+0x26c/0x33c\ndev_attr_show+0x50/0xc0(CVE-2023-54186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix memleak of md thread\n\nIn raid10_run(), if setup_conf() succeed and raid10_run() failed before\nsetting 'mddev->thread', then in the error path 'conf->thread' is not\nfreed.\n\nFix the problem by setting 'mddev->thread' right after setup_conf().(CVE-2023-54294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm flakey: don't corrupt the zero page\n\nWhen we need to zero some range on a block device, the function\n__blkdev_issue_zero_pages submits a write bio with the bio vector pointing\nto the zero page. If we use dm-flakey with corrupt bio writes option, it\nwill corrupt the content of the zero page which results in crashes of\nvarious userspace programs. Glibc assumes that memory returned by mmap is\nzeroed and it uses it for calloc implementation; if the newly mapped\nmemory is not zeroed, calloc will return non-zeroed memory.\n\nFix this bug by testing if the page is equal to ZERO_PAGE(0) and\navoiding the corruption in this case.(CVE-2023-54317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns\n\nWhat we want is to verify there is that clone won't expose something\nhidden by a mount we wouldn't be able to undo.  "Wouldn't be able to undo"\nmay be a result of MNT_LOCKED on a child, but it may also come from\nlacking admin rights in the userns of the namespace mount belongs to.\n\nclone_private_mnt() checks the former, but not the latter.\n\nThere's a number of rather confusing CAP_SYS_ADMIN checks in various\nuserns during the mount, especially with the new mount API; they serve\ndifferent purposes and in case of clone_private_mnt() they usually,\nbut not always end up covering the missing check mentioned above.(CVE-2025-38499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb->transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n <TASK>\n  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n  __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n  skb_gso_segment include/net/gso.h:83 [inline]\n  validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n  validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n  __dev_xmit_skb net/core/dev.c:4102 [inline]\n  __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n        ns = task_active_pid_ns(current);\n        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n                if (pid && ns->level <= pid->level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time.  The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n   pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n   them from rbtree.  erase tun3 first, and then erase tun2.  the\n   pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n   pde(tun2) which is released, it will case uaf access.\n\nCPU 0                                      |    CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun->dev)   //tun3 tun2\nsys_getdents64()                           |\n  iterate_dir()                            |\n    proc_readdir()                         |\n      proc_readdir_de()                    |     snmp6_unregister_dev()\n        pde_get(de);                       |       proc_remove()\n        read_unlock(&proc_subdir_lock);    |         remove_proc_subtree()\n                                           |           write_lock(&proc_subdir_lock);\n        [time window]                      |           rb_erase(&root->subdir_node, &parent->subdir);\n                                           |           write_unlock(&proc_subdir_lock);\n        read_lock(&proc_subdir_lock);      |\n        next = pde_subdir_next(de);        |\n        pde_put(de);                       |\n        de = next;    //UAF                |\n\nrbtree of dev_snmp6\n                        |\n                    pde(tun3)\n                     /    \\\n                  NULL  pde(tun2)(CVE-2025-40271)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2602.1.0.0361.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2602.1.0.0361.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1306"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53254"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53309"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53519"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53715"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54168"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54186"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54294"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38499"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38572"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38618"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40178"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40271"}],"database_specific":{"severity":"High"}}