{"schema_version":"1.7.2","id":"OESA-2026-2415","modified":"2026-05-22T13:19:18Z","published":"2026-05-22T13:19:18Z","upstream":["CVE-2026-31527","CVE-2026-31698","CVE-2026-31699","CVE-2026-43047","CVE-2026-43048","CVE-2026-46333"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus&apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don&apos;t attempt to copy PDH cert to userspace if PSP command failed\n\nWhen retrieving the PDH cert, don&apos;t attempt to copy the blobs to userspace\nif the firmware command failed.  If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n  Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033\n\n  CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY\n  Tainted: [U]=USER, [O]=OOT_MODULE\n  Hardware name: Google, Inc.                                                       Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025\n  Call Trace:\n   &lt;TASK&gt;\n   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n   print_address_description ../mm/kasan/report.c:378 [inline]\n   print_report+0xbc/0x260 ../mm/kasan/report.c:482\n   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n   check_region_inline ../mm/kasan/generic.c:-1 [inline]\n   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n   copy_to_user ../include/linux/uaccess.h:236 [inline]\n   sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347\n   sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568\n   vfs_ioctl ../fs/ioctl.c:51 [inline]\n   __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   &lt;/TASK&gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31698)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don&apos;t attempt to copy CSR to userspace if PSP command failed\n\nWhen retrieving the PEK CSR, don&apos;t attempt to copy the blob to userspace\nif the firmware command failed.  If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n  BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n  BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n  Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405\n\n  CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G     U     O        7.0.0-smp-DEV #28 PREEMPTLAZY\n  Tainted: [U]=USER, [O]=OOT_MODULE\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n  Call Trace:\n   &lt;TASK&gt;\n   dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n   print_address_description ../mm/kasan/report.c:378 [inline]\n   print_report+0xbc/0x260 ../mm/kasan/report.c:482\n   kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n   check_region_inline ../mm/kasan/generic.c:-1 [inline]\n   kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n   instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n   _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n   _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n   copy_to_user ../include/linux/uaccess.h:236 [inline]\n   sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872\n   sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562\n   vfs_ioctl ../fs/ioctl.c:51 [inline]\n   __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n   __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n   do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   &lt;/TASK&gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report&apos;s feature request using a completely different report\nID.  This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested.  If it doesn&apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer.  However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires &lt;(CVE-2026-43048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptrace: slightly saner &apos;get_dumpable()&apos; logic\n\nThe &apos;dumpability&apos; of a task is fundamentally about the memory image of\nthe task - the concept comes from whether it can core dump or not - and\nmakes no sense when you don&apos;t have an associated mm.\n\nAnd almost all users do in fact use it only for the case where the task\nhas a mm pointer.\n\nBut we have one odd special case: ptrace_may_access() uses &apos;dumpable&apos; to\ncheck various other things entirely independently of the MM (typically\nexplicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for\nthreads that no longer have a VM (and maybe never did, like most kernel\nthreads).\n\nIt&apos;s not what this flag was designed for, but it is what it is.\n\nThe ptrace code does check that the uid/gid matches, so you do have to\nbe uid-0 to see kernel thread details, but this means that the\ntraditional &quot;drop capabilities&quot; model doesn&apos;t make any difference for\nthis all.\n\nMake it all make a *bit* more sense by saying that if you don&apos;t have a\nMM pointer, we&apos;ll use a cached &quot;last dumpability&quot; flag if the thread\never had a MM (it will be zero for kernel threads since it is never\nset), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2605.4.0.0373.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2605.4.0.0373.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2605.4.0.0373.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2415"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31698"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31699"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43048"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46333"}],"database_specific":{"severity":"High"}}
