{ "document":{ "aggregate_severity":{ "namespace":"https://nvd.nist.gov/vuln-metrics/cvss", "text":"High" }, "category":"csaf_vex", "csaf_version":"2.0", "distribution":{ "tlp":{ "label":"WHITE", "url":"https:/www.first.org/tlp/" } }, "lang":"en", "notes":[ { "text":"kernel security update", "category":"general", "title":"Synopsis" }, { "text":"An update for kernel is now available for openEuler-24.03-LTS-SP1", "category":"general", "title":"Summary" }, { "text":"The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/xattr: missing fdput() in fremovexattr error path\n\nIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a\nfile reference but returns early without calling fdput() when\nstrncpy_from_user() fails on the name argument. In multi-threaded processes\nwhere fdget() takes the slow path, this permanently leaks one\nfile reference per call, pinning the struct file and associated kernel\nobjects in memory. An unprivileged local user can exploit this to cause\nkernel memory exhaustion. The issue was inadvertently fixed by commit\na71874379ec8 (\"xattr: switch to CLASS(fd)\").(CVE-2024-14027)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npps: Fix a use-after-free\n\nOn a board running ntpd and gpsd, I'm seeing a consistent use-after-free\nin sys_exit() from gpsd when rebooting:\n\n pps pps1: removed\n ------------[ cut here ]------------\n kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.\n WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150\n CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1\n Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : kobject_put+0x120/0x150\n lr : kobject_put+0x120/0x150\n sp : ffffffc0803d3ae0\n x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001\n x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440\n x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600\n x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20\n x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n kobject_put+0x120/0x150\n cdev_put+0x20/0x3c\n __fput+0x2c4/0x2d8\n ____fput+0x1c/0x38\n task_work_run+0x70/0xfc\n do_exit+0x2a0/0x924\n do_group_exit+0x34/0x90\n get_signal+0x7fc/0x8c0\n do_signal+0x128/0x13b4\n do_notify_resume+0xdc/0x160\n el0_svc+0xd4/0xf8\n el0t_64_sync_handler+0x140/0x14c\n el0t_64_sync+0x190/0x194\n ---[ end trace 0000000000000000 ]---\n\n...followed by more symptoms of corruption, with similar stacks:\n\n refcount_t: underflow; use-after-free.\n kernel BUG at lib/list_debug.c:62!\n Kernel panic - not syncing: Oops - BUG: Fatal exception\n\nThis happens because pps_device_destruct() frees the pps_device with the\nembedded cdev immediately after calling cdev_del(), but, as the comment\nabove cdev_del() notes, fops for previously opened cdevs are still\ncallable even after cdev_del() returns. I think this bug has always\nbeen there: I can't explain why it suddenly started happening every time\nI reboot this particular board.\n\nIn commit d953e0e837e6 (\"pps: Fix a use-after free bug when\nunregistering a source.\"), George Spelvin suggested removing the\nembedded cdev. That seems like the simplest way to fix this, so I've\nimplemented his suggestion, using __register_chrdev() with pps_idr\nbecoming the source of truth for which minor corresponds to which\ndevice.\n\nBut now that pps_idr defines userspace visibility instead of cdev_add(),\nwe need to be sure the pps->dev refcount can't reach zero while\nuserspace can still find it again. So, the idr_remove() call moves to\npps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.\n\n pps_core: source serial1 got cdev (251:1)\n <...>\n pps pps1: removed\n pps_core: unregistering pps1\n pps_core: deallocating pps1(CVE-2024-57979)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible UAFs\n\nThis attemps to fix possible UAFs caused by struct mgmt_pending being\nfreed while still being processed like in the following trace, in order\nto fix mgmt_pending_valid is introduce and use to check if the\nmgmt_pending hasn't been removed from the pending list, on the complete\ncallbacks it is used to check and in addtion remove the cmd from the list\nwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd\nis left on the list it can still be accessed and freed.\n\nBUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\nRead of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55\n\nCPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\n hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245\n \n\nAllocated by task 12210:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247\n add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n sock_write_iter+0x258/0x330 net/socket.c:1133\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 12221:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2381 [inline]\n slab_free mm/slub.c:4648 [inline]\n kfree+0x18e/0x440 mm/slub.c:4847\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444\n hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290\n hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]\n hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526\n sock_do_ioctl+0xd9/0x300 net/socket.c:1192\n sock_ioctl+0x576/0x790 net/socket.c:1313\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf\n---truncated---(CVE-2025-39981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: xilinx: xdma: Fix regmap max_register\n\nThe max_register field is assigned the size of the register memory\nregion instead of the offset of the last register.\nThe result is that reading from the regmap via debugfs can cause\na segmentation fault:\n\ntail /sys/kernel/debug/regmap/xdma.1.auto/registers\nUnable to handle kernel paging request at virtual address ffff800082f70000\nMem abort info:\n ESR = 0x0000000096000007\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x07: level 3 translation fault\n[...]\nCall trace:\n regmap_mmio_read32le+0x10/0x30\n _regmap_bus_reg_read+0x74/0xc0\n _regmap_read+0x68/0x198\n regmap_read+0x54/0x88\n regmap_read_debugfs+0x140/0x380\n regmap_map_read_file+0x30/0x48\n full_proxy_read+0x68/0xc8\n vfs_read+0xcc/0x310\n ksys_read+0x7c/0x120\n __arm64_sys_read+0x24/0x40\n invoke_syscall.constprop.0+0x64/0x108\n do_el0_svc+0xb0/0xd8\n el0_svc+0x38/0x130\n el0t_64_sync_handler+0x120/0x138\n el0t_64_sync+0x194/0x198\nCode: aa1e03e9 d503201f f9400000 8b214000 (b9400000)\n---[ end trace 0000000000000000 ]---\nnote: tail[1217] exited with irqs disabled\nnote: tail[1217] exited with preempt_count 1\nSegmentation fault(CVE-2025-71195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: fix refcount leak in parse_durable_handle_context()\n\nWhen the command is a replay operation and -ENOEXEC is returned,\nthe refcount of ksmbd_file must be released.(CVE-2025-71204)\n\nIn the Linux kernel, a vulnerability has been identified involving the fix for hugetlb_pmd_shared() function. The vulnerability prevents proper detection of shared PMD tables because sharing/unsharing operations no longer affect the refcount of a PMD table. This allows page migration functions like mbind() or migrate_pages() to incorrectly permit migration of folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps, these folios would be incorrectly accounted as \"private\" instead of \"shared\", and PM_MMAP_EXCLUSIVE would be wrongly set in the pagemap interface.(CVE-2026-23100)\n\nA race condition vulnerability exists in the LED subsystem (led-class) of the Linux kernel. The root cause is that an LED device is added to the global LED list (`leds_list`) prematurely, before it is fully initialized. Specifically, in the `led_classdev_register()` function, the LED device is added to `leds_list` before the call to `led_init_core()`, which performs core initialization including setting up the `set_brightness_work` workqueue. This leaves a time window during which if the LED's default trigger (e.g., provided by `snd_ctl_led.ko`) registers asynchronously (`led_trigger_register`), it may trigger a `led_set_brightness()` call, which in turn attempts to queue work on the uninitialized `set_brightness_work` workqueue. This race condition is hit by the EC driver on specific hardware (like Lenovo ThinkPad T14s) when registering multiple LEDs in quick succession, causing the kernel to issue a warning (WARNING) and potentially leading to system instability.(CVE-2026-23101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\n\nCurrently this is checked before running the pending work. Normally this\nis quite fine, as work items either end up blocking (which will create a\nnew worker for other items), or they complete fairly quickly. But syzbot\nreports an issue where io-wq takes seemingly forever to exit, and with a\nbit of debugging, this turns out to be because it queues a bunch of big\n(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't\nsupport ->read_iter(), loop_rw_iter() ends up handling them. Each read\nreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch of\nthese pending, processing the whole chain can take a long time. Easily\nlonger than the syzbot uninterruptible sleep timeout of 140 seconds.\nThis then triggers a complaint off the io-wq exit path:\n\nINFO: task syz.4.135:6326 blocked for more than 143 seconds.\n Not tainted syzkaller #0\n Blocked by coredump.\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000\nCall Trace:\n \n context_switch kernel/sched/core.c:5256 [inline]\n __schedule+0x1139/0x6150 kernel/sched/core.c:6863\n __schedule_loop kernel/sched/core.c:6945 [inline]\n schedule+0xe7/0x3a0 kernel/sched/core.c:6960\n schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75\n do_wait_for_common kernel/sched/completion.c:100 [inline]\n __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121\n io_wq_exit_workers io_uring/io-wq.c:1328 [inline]\n io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356\n io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203\n io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651\n io_uring_files_cancel include/linux/io_uring.h:19 [inline]\n do_exit+0x2ce/0x2bd0 kernel/exit.c:911\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1112\n get_signal+0x2671/0x26d0 kernel/signal.c:3034\n arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337\n __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]\n exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa02738f749\nRSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca\nRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749\nRDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098\nRBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98\n\nThere's really nothing wrong here, outside of processing these reads\nwill take a LONG time. However, we can speed up the exit by checking the\nIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will\nexit the ring after queueing up all of these reads. Then once the first\nitem is processed, io-wq will simply cancel the rest. That should avoid\nsyzbot running into this complaint again.(CVE-2026-23113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: provide a net pointer to __skb_flow_dissect()\n\nAfter 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\")\nwe have to provide a net pointer to __skb_flow_dissect(),\neither via skb->dev, skb->sk, or a user provided pointer.\n\nIn the following case, syzbot was able to cook a bare skb.\n\nWARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053\nCall Trace:\n \n bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]\n __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157\n bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]\n bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]\n bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515\n xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388\n bpf_prog_run_xdp include/net/xdp.h:700 [inline]\n bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421\n bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390\n bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703\n __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182\n __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94(CVE-2026-23119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT\n\nA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key\ninitialization fails:\n\n ==================================================================\n KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2\n RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]\n RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401\n Call Trace:\n\n sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189\n sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111\n sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217\n sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169\n sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052\n sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88\n sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243\n sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127\n\nThe issue is triggered when sctp_auth_asoc_init_active_key() fails in\nsctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the\ncommand sequence is currently:\n\n- SCTP_CMD_PEER_INIT\n- SCTP_CMD_TIMER_STOP (T1_INIT)\n- SCTP_CMD_TIMER_START (T1_COOKIE)\n- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)\n- SCTP_CMD_ASSOC_SHKEY\n- SCTP_CMD_GEN_COOKIE_ECHO\n\nIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while\nasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by\nSCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL\nto be queued by sctp_datamsg_from_user().\n\nSince command interpretation stops on failure, no COOKIE_ECHO should been\nsent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already\nbeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. As\na result, the DATA chunk can be transmitted together with the COOKIE_ECHO\nin sctp_outq_flush_data(), leading to the observed issue.\n\nSimilar to the other places where it calls sctp_auth_asoc_init_active_key()\nright after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY\nimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting\nT1_COOKIE. This ensures that if shared key generation fails, authenticated\nDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,\ngiving the client another chance to process INIT_ACK and retry key setup.(CVE-2026-23125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Set __nocfi on swsusp_arch_resume()\n\nA DABT is reported[1] on an android based system when resume from hiberate.\nThis happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()\nand does not have a CFI hash, but swsusp_arch_resume() will attempt to\nverify the CFI hash when calling a copy of swsusp_arch_suspend_exit().\n\nGiven that there's an existing requirement that the entrypoint to\nswsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text\nsection, we cannot fix this by marking swsusp_arch_suspend_exit() with\nSYM_FUNC_*(). The simplest fix for now is to disable the CFI check in\nswsusp_arch_resume().\n\nMark swsusp_arch_resume() as __nocfi to disable the CFI check.\n\n[1]\n[ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc\n[ 22.991934][ T1] Mem abort info:\n[ 22.991934][ T1] ESR = 0x0000000096000007\n[ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 22.991934][ T1] SET = 0, FnV = 0\n[ 22.991934][ T1] EA = 0, S1PTW = 0\n[ 22.991934][ T1] FSC = 0x07: level 3 translation fault\n[ 22.991934][ T1] Data abort info:\n[ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n[ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper\n[ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP\n[ 22.991934][ T1] Dumping ftrace buffer:\n[ 22.991934][ T1] (ftrace buffer empty)\n[ 22.991934][ T1] Modules linked in:\n[ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419\n[ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)\n[ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344\n[ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344\n[ 22.991934][ T1] sp : ffffffc08006b960\n[ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000\n[ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820\n[ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000\n[ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058\n[ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004\n[ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000\n[ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000\n[ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b\n[ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530\n[ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000\n[ 22.991934][ T1] Call trace:\n[ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344\n[ 22.991934][ T1] hibernation_restore+0x158/0x18c\n[ 22.991934][ T1] load_image_and_restore+0xb0/0xec\n[ 22.991934][ T1] software_resume+0xf4/0x19c\n[ 22.991934][ T1] software_resume_initcall+0x34/0x78\n[ 22.991934][ T1] do_one_initcall+0xe8/0x370\n[ 22.991934][ T1] do_initcall_level+0xc8/0x19c\n[ 22.991934][ T1] do_initcalls+0x70/0xc0\n[ 22.991934][ T1] do_basic_setup+0x1c/0x28\n[ 22.991934][ T1] kernel_init_freeable+0xe0/0x148\n[ 22.991934][ T1] kernel_init+0x20/0x1a8\n[ 22.991934][ T1] ret_from_fork+0x10/0x20\n[ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)\n\n[catalin.marinas@arm.com: commit log updated by Mark Rutland](CVE-2026-23128)\n\nIn the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Subtract size of xdp_frame from allowed metadata size The xdp_frame structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpf_test_run, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom). If userspace supplies such a large metadata size in live packet mode, the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff. The commit in the Fixes tag fixed a related bug where the second check in xdp_update_frame_from_buff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment. The Linux kernel CVE team has assigned CVE-2026-23140 to this issue.(CVE-2026-23140)\n\nIn the Linux kernel, there is a vulnerability in the shmem (shared memory) subsystem. When truncating a large swap entry, if the index points to the middle of a large swap entry and the entry doesn't cross the end boundary, it causes an infinite loop condition. An attacker could potentially exploit this vulnerability to cause denial of service.(CVE-2026-23177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix oops due to invalid pointer for kfree() in parse_longname()\n\nThis fixes a kernel oops when reading ceph snapshot directories (.snap),\nfor example by simply running `ls /mnt/my_ceph/.snap`.\n\nThe variable str is guarded by __free(kfree), but advanced by one for\nskipping the initial '_' in snapshot names. Thus, kfree() is called\nwith an invalid pointer. This patch removes the need for advancing the\npointer so kfree() is called with correct memory pointer.\n\nSteps to reproduce:\n\n1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)\n\n2. Add cephfs mount to fstab\n$ echo \"(CVE-2026-23201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n\n\nThe issue is triggered when a new macvlan link is created with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port's vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n if (ops->newlink)\n err = ops->newlink(dev, ¶ms, extack);\n else\n err = register_netdevice(dev);\n if (err < 0) {\n free_netdev(dev);\n goto out;\n }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device's macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \"goto destroy_macvlan_port;\"\npath is taken.\n\nMany thanks to valis for following up on this issue.(CVE-2026-23209)\n\nIn the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock to protect ksmbd_chann_list xarray ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del). Adds rw_semaphore chann_lock to struct ksmbd_session and protects all xa_load/xa_store/xa_erase accesses. The Linux kernel CVE team has assigned CVE-2026-23226 to this issue.(CVE-2026-23226)\n\nIn the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. The Linux kernel CVE team has assigned CVE-2026-23229 to this issue.(CVE-2026-23229)\n\nIn the Linux kernel, a NULL pointer dereference vulnerability exists in the Classmate laptop driver. The vulnerability occurs in platform/x86/classmate-laptop driver where code using the accel object may run before that object's address is stored in the driver data of the input device. Specifically, sysfs attributes may be accessed before initializing the device, causing dev_get_drvdata() calls to return NULL and leading to NULL pointer dereference.(CVE-2026-23237)", "category":"general", "title":"Description" }, { "text":"An update for kernel is now available for openEuler-22.03-LTS-SP4/openEuler-24.03-LTS-SP1/openEuler-22.03-LTS-SP3.\n\nopenEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.", "category":"general", "title":"Topic" }, { "text":"High", "category":"general", "title":"Severity" }, { "text":"kernel", "category":"general", "title":"Affected Component" } ], "publisher":{ "issuing_authority":"openEuler security committee", "name":"openEuler", "namespace":"https://www.openeuler.org", "contact_details":"openeuler-security@openeuler.org", "category":"vendor" }, "references":[ { "summary":"openEuler-SA-2026-1643", "category":"self", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" }, { "summary":"CVE-2024-14027", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-14027&packageName=kernel" }, { "summary":"CVE-2024-57979", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-57979&packageName=kernel" }, { "summary":"CVE-2025-39981", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39981&packageName=kernel" }, { "summary":"CVE-2025-71195", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71195&packageName=kernel" }, { "summary":"CVE-2025-71204", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71204&packageName=kernel" }, { "summary":"CVE-2026-23100", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23100&packageName=kernel" }, { "summary":"CVE-2026-23101", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23101&packageName=kernel" }, { "summary":"CVE-2026-23113", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23113&packageName=kernel" }, { "summary":"CVE-2026-23119", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23119&packageName=kernel" }, { "summary":"CVE-2026-23125", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23125&packageName=kernel" }, { "summary":"CVE-2026-23128", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23128&packageName=kernel" }, { "summary":"CVE-2026-23140", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23140&packageName=kernel" }, { "summary":"CVE-2026-23177", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23177&packageName=kernel" }, { "summary":"CVE-2026-23201", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23201&packageName=kernel" }, { "summary":"CVE-2026-23209", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23209&packageName=kernel" }, { "summary":"CVE-2026-23226", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23226&packageName=kernel" }, { "summary":"CVE-2026-23229", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23229&packageName=kernel" }, { "summary":"CVE-2026-23237", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23237&packageName=kernel" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2024-14027" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57979" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39981" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71195" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71204" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23100" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23101" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23113" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23119" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23125" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23128" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23140" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23177" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23201" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23209" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23226" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23229" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23237" }, { "summary":"openEuler-SA-2026-1643 vex file", "category":"self", "url":"https://repo.openeuler.org/security/data/csaf/advisories/2026/csaf-openeuler-sa-2026-1643.json" } ], "title":"An update for kernel is now available for openEuler-24.03-LTS-SP1", "tracking":{ "initial_release_date":"2026-03-20T22:25:37+08:00", "revision_history":[ { "date":"2026-03-20T22:25:37+08:00", "summary":"Initial", "number":"1.0.0" } ], "generator":{ "date":"2026-03-20T22:25:37+08:00", "engine":{ "name":"openEuler CSAF Tool V1.0" } }, "current_release_date":"2026-03-20T22:25:37+08:00", "id":"openEuler-SA-2026-1643", "version":"1.0.0", "status":"final" } }, "product_tree":{ "branches":[ { "name":"openEuler", "category":"vendor", "branches":[ { "name":"openEuler", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"openEuler-24.03-LTS-SP1", "name":"openEuler-24.03-LTS-SP1" }, "name":"openEuler-24.03-LTS-SP1", "category":"product_version" } ], "category":"product_name" }, { "name":"x86_64", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm" }, "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "category":"product_version" } ], "category":"architecture" }, { "name":"src", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-6.6.0-143.0.0.137.oe2403sp1.src.rpm", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.src.rpm" }, "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.src.rpm", "category":"product_version" } ], "category":"architecture" }, { "name":"aarch64", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP1" }, "product_id":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm" }, "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "category":"product_version" } ], "category":"architecture" } ] } ], "relationships":[ { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:perf-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"perf-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-6.6.0-143.0.0.137.oe2403sp1.src.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.src", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.src as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:perf-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"perf-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP1", "product_reference":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP1:python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "name":"python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64 as a component of openEuler-24.03-LTS-SP1" }, "category":"default_component_of" } ] }, "vulnerabilities":[ { "cve":"CVE-2024-14027", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs/xattr: missing fdput() in fremovexattr error path\n\nIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a\nfile reference but returns early without calling fdput() when\nstrncpy_from_user() fails on the name argument. In multi-threaded processes\nwhere fdget() takes the slow path, this permanently leaks one\nfile reference per call, pinning the struct file and associated kernel\nobjects in memory. An unprivileged local user can exploit this to cause\nkernel memory exhaustion. The issue was inadvertently fixed by commit\na71874379ec8 (\"xattr: switch to CLASS(fd)\").", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":[ "openEuler-24.03-LTS-SP1:bpftool-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-headers-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-source-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-tools-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:perf-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:python3-perf-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.x86_64", "openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.src", "openEuler-24.03-LTS-SP1:bpftool-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:bpftool-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-debugsource-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-headers-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-source-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-tools-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-tools-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:kernel-tools-devel-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:perf-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:python3-perf-6.6.0-143.0.0.137.oe2403sp1.aarch64", "openEuler-24.03-LTS-SP1:python3-perf-debuginfo-6.6.0-143.0.0.137.oe2403sp1.aarch64" ] }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2024-14027" }, { "cve":"CVE-2024-57979", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\npps: Fix a use-after-free\n\nOn a board running ntpd and gpsd, I'm seeing a consistent use-after-free\nin sys_exit() from gpsd when rebooting:\n\n pps pps1: removed\n ------------[ cut here ]------------\n kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.\n WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150\n CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1\n Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : kobject_put+0x120/0x150\n lr : kobject_put+0x120/0x150\n sp : ffffffc0803d3ae0\n x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001\n x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440\n x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600\n x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20\n x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n kobject_put+0x120/0x150\n cdev_put+0x20/0x3c\n __fput+0x2c4/0x2d8\n ____fput+0x1c/0x38\n task_work_run+0x70/0xfc\n do_exit+0x2a0/0x924\n do_group_exit+0x34/0x90\n get_signal+0x7fc/0x8c0\n do_signal+0x128/0x13b4\n do_notify_resume+0xdc/0x160\n el0_svc+0xd4/0xf8\n el0t_64_sync_handler+0x140/0x14c\n el0t_64_sync+0x190/0x194\n ---[ end trace 0000000000000000 ]---\n\n...followed by more symptoms of corruption, with similar stacks:\n\n refcount_t: underflow; use-after-free.\n kernel BUG at lib/list_debug.c:62!\n Kernel panic - not syncing: Oops - BUG: Fatal exception\n\nThis happens because pps_device_destruct() frees the pps_device with the\nembedded cdev immediately after calling cdev_del(), but, as the comment\nabove cdev_del() notes, fops for previously opened cdevs are still\ncallable even after cdev_del() returns. I think this bug has always\nbeen there: I can't explain why it suddenly started happening every time\nI reboot this particular board.\n\nIn commit d953e0e837e6 (\"pps: Fix a use-after free bug when\nunregistering a source.\"), George Spelvin suggested removing the\nembedded cdev. That seems like the simplest way to fix this, so I've\nimplemented his suggestion, using __register_chrdev() with pps_idr\nbecoming the source of truth for which minor corresponds to which\ndevice.\n\nBut now that pps_idr defines userspace visibility instead of cdev_add(),\nwe need to be sure the pps->dev refcount can't reach zero while\nuserspace can still find it again. So, the idr_remove() call moves to\npps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.\n\n pps_core: source serial1 got cdev (251:1)\n <...>\n pps pps1: removed\n pps_core: unregistering pps1\n pps_core: deallocating pps1", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2024-57979" }, { "cve":"CVE-2025-39981", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible UAFs\n\nThis attemps to fix possible UAFs caused by struct mgmt_pending being\nfreed while still being processed like in the following trace, in order\nto fix mgmt_pending_valid is introduce and use to check if the\nmgmt_pending hasn't been removed from the pending list, on the complete\ncallbacks it is used to check and in addtion remove the cmd from the list\nwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd\nis left on the list it can still be accessed and freed.\n\nBUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\nRead of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55\n\nCPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\n hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245\n \n\nAllocated by task 12210:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247\n add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n sock_write_iter+0x258/0x330 net/socket.c:1133\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 12221:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2381 [inline]\n slab_free mm/slub.c:4648 [inline]\n kfree+0x18e/0x440 mm/slub.c:4847\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444\n hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290\n hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]\n hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526\n sock_do_ioctl+0xd9/0x300 net/socket.c:1192\n sock_ioctl+0x576/0x790 net/socket.c:1313\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf\n---truncated---", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.3, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2025-39981" }, { "cve":"CVE-2025-71195", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: xilinx: xdma: Fix regmap max_register\n\nThe max_register field is assigned the size of the register memory\nregion instead of the offset of the last register.\nThe result is that reading from the regmap via debugfs can cause\na segmentation fault:\n\ntail /sys/kernel/debug/regmap/xdma.1.auto/registers\nUnable to handle kernel paging request at virtual address ffff800082f70000\nMem abort info:\n ESR = 0x0000000096000007\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x07: level 3 translation fault\n[...]\nCall trace:\n regmap_mmio_read32le+0x10/0x30\n _regmap_bus_reg_read+0x74/0xc0\n _regmap_read+0x68/0x198\n regmap_read+0x54/0x88\n regmap_read_debugfs+0x140/0x380\n regmap_map_read_file+0x30/0x48\n full_proxy_read+0x68/0xc8\n vfs_read+0xcc/0x310\n ksys_read+0x7c/0x120\n __arm64_sys_read+0x24/0x40\n invoke_syscall.constprop.0+0x64/0x108\n do_el0_svc+0xb0/0xd8\n el0_svc+0x38/0x130\n el0t_64_sync_handler+0x120/0x138\n el0t_64_sync+0x194/0x198\nCode: aa1e03e9 d503201f f9400000 8b214000 (b9400000)\n---[ end trace 0000000000000000 ]---\nnote: tail[1217] exited with irqs disabled\nnote: tail[1217] exited with preempt_count 1\nSegmentation fault", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-71195" }, { "cve":"CVE-2025-71204", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: fix refcount leak in parse_durable_handle_context()\n\nWhen the command is a replay operation and -ENOEXEC is returned,\nthe refcount of ksmbd_file must be released.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-71204" }, { "cve":"CVE-2026-23100", "notes":[ { "text":"In the Linux kernel, a vulnerability has been identified involving the fix for hugetlb_pmd_shared() function. The vulnerability prevents proper detection of shared PMD tables because sharing/unsharing operations no longer affect the refcount of a PMD table. This allows page migration functions like mbind() or migrate_pages() to incorrectly permit migration of folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps, these folios would be incorrectly accounted as \"private\" instead of \"shared\", and PM_MMAP_EXCLUSIVE would be wrongly set in the pagemap interface.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.4, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23100" }, { "cve":"CVE-2026-23101", "notes":[ { "text":"A race condition vulnerability exists in the LED subsystem (led-class) of the Linux kernel. The root cause is that an LED device is added to the global LED list (`leds_list`) prematurely, before it is fully initialized. Specifically, in the `led_classdev_register()` function, the LED device is added to `leds_list` before the call to `led_init_core()`, which performs core initialization including setting up the `set_brightness_work` workqueue. This leaves a time window during which if the LED's default trigger (e.g., provided by `snd_ctl_led.ko`) registers asynchronously (`led_trigger_register`), it may trigger a `led_set_brightness()` call, which in turn attempts to queue work on the uninitialized `set_brightness_work` workqueue. This race condition is hit by the EC driver on specific hardware (like Lenovo ThinkPad T14s) when registering multiple LEDs in quick succession, causing the kernel to issue a warning (WARNING) and potentially leading to system instability.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23101" }, { "cve":"CVE-2026-23113", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\n\nCurrently this is checked before running the pending work. Normally this\nis quite fine, as work items either end up blocking (which will create a\nnew worker for other items), or they complete fairly quickly. But syzbot\nreports an issue where io-wq takes seemingly forever to exit, and with a\nbit of debugging, this turns out to be because it queues a bunch of big\n(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't\nsupport ->read_iter(), loop_rw_iter() ends up handling them. Each read\nreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch of\nthese pending, processing the whole chain can take a long time. Easily\nlonger than the syzbot uninterruptible sleep timeout of 140 seconds.\nThis then triggers a complaint off the io-wq exit path:\n\nINFO: task syz.4.135:6326 blocked for more than 143 seconds.\n Not tainted syzkaller #0\n Blocked by coredump.\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000\nCall Trace:\n \n context_switch kernel/sched/core.c:5256 [inline]\n __schedule+0x1139/0x6150 kernel/sched/core.c:6863\n __schedule_loop kernel/sched/core.c:6945 [inline]\n schedule+0xe7/0x3a0 kernel/sched/core.c:6960\n schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75\n do_wait_for_common kernel/sched/completion.c:100 [inline]\n __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121\n io_wq_exit_workers io_uring/io-wq.c:1328 [inline]\n io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356\n io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203\n io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651\n io_uring_files_cancel include/linux/io_uring.h:19 [inline]\n do_exit+0x2ce/0x2bd0 kernel/exit.c:911\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1112\n get_signal+0x2671/0x26d0 kernel/signal.c:3034\n arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337\n __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]\n exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa02738f749\nRSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca\nRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749\nRDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098\nRBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98\n\nThere's really nothing wrong here, outside of processing these reads\nwill take a LONG time. However, we can speed up the exit by checking the\nIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will\nexit the ring after queueing up all of these reads. Then once the first\nitem is processed, io-wq will simply cancel the rest. That should avoid\nsyzbot running into this complaint again.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23113" }, { "cve":"CVE-2026-23119", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: provide a net pointer to __skb_flow_dissect()\n\nAfter 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\")\nwe have to provide a net pointer to __skb_flow_dissect(),\neither via skb->dev, skb->sk, or a user provided pointer.\n\nIn the following case, syzbot was able to cook a bare skb.\n\nWARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053\nCall Trace:\n \n bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]\n __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157\n bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]\n bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]\n bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515\n xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388\n bpf_prog_run_xdp include/net/xdp.h:700 [inline]\n bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421\n bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390\n bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703\n __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182\n __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23119" }, { "cve":"CVE-2026-23125", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT\n\nA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key\ninitialization fails:\n\n ==================================================================\n KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2\n RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]\n RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401\n Call Trace:\n\n sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189\n sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111\n sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217\n sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169\n sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052\n sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88\n sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243\n sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127\n\nThe issue is triggered when sctp_auth_asoc_init_active_key() fails in\nsctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the\ncommand sequence is currently:\n\n- SCTP_CMD_PEER_INIT\n- SCTP_CMD_TIMER_STOP (T1_INIT)\n- SCTP_CMD_TIMER_START (T1_COOKIE)\n- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)\n- SCTP_CMD_ASSOC_SHKEY\n- SCTP_CMD_GEN_COOKIE_ECHO\n\nIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while\nasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by\nSCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL\nto be queued by sctp_datamsg_from_user().\n\nSince command interpretation stops on failure, no COOKIE_ECHO should been\nsent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already\nbeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. As\na result, the DATA chunk can be transmitted together with the COOKIE_ECHO\nin sctp_outq_flush_data(), leading to the observed issue.\n\nSimilar to the other places where it calls sctp_auth_asoc_init_active_key()\nright after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY\nimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting\nT1_COOKIE. This ensures that if shared key generation fails, authenticated\nDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,\ngiving the client another chance to process INIT_ACK and retry key setup.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23125" }, { "cve":"CVE-2026-23128", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: Set __nocfi on swsusp_arch_resume()\n\nA DABT is reported[1] on an android based system when resume from hiberate.\nThis happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()\nand does not have a CFI hash, but swsusp_arch_resume() will attempt to\nverify the CFI hash when calling a copy of swsusp_arch_suspend_exit().\n\nGiven that there's an existing requirement that the entrypoint to\nswsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text\nsection, we cannot fix this by marking swsusp_arch_suspend_exit() with\nSYM_FUNC_*(). The simplest fix for now is to disable the CFI check in\nswsusp_arch_resume().\n\nMark swsusp_arch_resume() as __nocfi to disable the CFI check.\n\n[1]\n[ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc\n[ 22.991934][ T1] Mem abort info:\n[ 22.991934][ T1] ESR = 0x0000000096000007\n[ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 22.991934][ T1] SET = 0, FnV = 0\n[ 22.991934][ T1] EA = 0, S1PTW = 0\n[ 22.991934][ T1] FSC = 0x07: level 3 translation fault\n[ 22.991934][ T1] Data abort info:\n[ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n[ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper\n[ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP\n[ 22.991934][ T1] Dumping ftrace buffer:\n[ 22.991934][ T1] (ftrace buffer empty)\n[ 22.991934][ T1] Modules linked in:\n[ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419\n[ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)\n[ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344\n[ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344\n[ 22.991934][ T1] sp : ffffffc08006b960\n[ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000\n[ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820\n[ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000\n[ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058\n[ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004\n[ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000\n[ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000\n[ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b\n[ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530\n[ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000\n[ 22.991934][ T1] Call trace:\n[ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344\n[ 22.991934][ T1] hibernation_restore+0x158/0x18c\n[ 22.991934][ T1] load_image_and_restore+0xb0/0xec\n[ 22.991934][ T1] software_resume+0xf4/0x19c\n[ 22.991934][ T1] software_resume_initcall+0x34/0x78\n[ 22.991934][ T1] do_one_initcall+0xe8/0x370\n[ 22.991934][ T1] do_initcall_level+0xc8/0x19c\n[ 22.991934][ T1] do_initcalls+0x70/0xc0\n[ 22.991934][ T1] do_basic_setup+0x1c/0x28\n[ 22.991934][ T1] kernel_init_freeable+0xe0/0x148\n[ 22.991934][ T1] kernel_init+0x20/0x1a8\n[ 22.991934][ T1] ret_from_fork+0x10/0x20\n[ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)\n\n[catalin.marinas@arm.com: commit log updated by Mark Rutland]", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23128" }, { "cve":"CVE-2026-23140", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Subtract size of xdp_frame from allowed metadata size The xdp_frame structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpf_test_run, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom). If userspace supplies such a large metadata size in live packet mode, the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff. The commit in the Fixes tag fixed a related bug where the second check in xdp_update_frame_from_buff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment. The Linux kernel CVE team has assigned CVE-2026-23140 to this issue.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23140" }, { "cve":"CVE-2026-23177", "notes":[ { "text":"In the Linux kernel, there is a vulnerability in the shmem (shared memory) subsystem. When truncating a large swap entry, if the index points to the middle of a large swap entry and the entry doesn't cross the end boundary, it causes an infinite loop condition. An attacker could potentially exploit this vulnerability to cause denial of service.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23177" }, { "cve":"CVE-2026-23201", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix oops due to invalid pointer for kfree() in parse_longname()\n\nThis fixes a kernel oops when reading ceph snapshot directories (.snap),\nfor example by simply running `ls /mnt/my_ceph/.snap`.\n\nThe variable str is guarded by __free(kfree), but advanced by one for\nskipping the initial '_' in snapshot names. Thus, kfree() is called\nwith an invalid pointer. This patch removes the need for advancing the\npointer so kfree() is called with correct memory pointer.\n\nSteps to reproduce:\n\n1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)\n\n2. Add cephfs mount to fstab\n$ echo \"", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23201" }, { "cve":"CVE-2026-23209", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n\n\nThe issue is triggered when a new macvlan link is created with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port's vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n if (ops->newlink)\n err = ops->newlink(dev, ¶ms, extack);\n else\n err = register_netdevice(dev);\n if (err < 0) {\n free_netdev(dev);\n goto out;\n }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device's macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \"goto destroy_macvlan_port;\"\npath is taken.\n\nMany thanks to valis for following up on this issue.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.0, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23209" }, { "cve":"CVE-2026-23226", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock to protect ksmbd_chann_list xarray ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del). Adds rw_semaphore chann_lock to struct ksmbd_session and protects all xa_load/xa_store/xa_erase accesses. The Linux kernel CVE team has assigned CVE-2026-23226 to this issue.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23226" }, { "cve":"CVE-2026-23229", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. The Linux kernel CVE team has assigned CVE-2026-23229 to this issue.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23229" }, { "cve":"CVE-2026-23237", "notes":[ { "text":"In the Linux kernel, a NULL pointer dereference vulnerability exists in the Classmate laptop driver. The vulnerability occurs in platform/x86/classmate-laptop driver where code using the accel object may run before that object's address is stored in the driver data of the input device. Specifically, sysfs attributes may be accessed before initializing the device, causing dev_get_drvdata() calls to return NULL and leading to NULL pointer dereference.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1643" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23237" } ] }