{"schema_version":"1.7.2","id":"OESA-2026-2495","modified":"2026-05-29T13:34:54Z","published":"2026-05-29T13:34:54Z","upstream":["CVE-2026-31503","CVE-2026-43054","CVE-2026-43057","CVE-2026-43119","CVE-2026-43123","CVE-2026-43134","CVE-2026-43170","CVE-2026-43223","CVE-2026-43344","CVE-2026-43381","CVE-2026-43408","CVE-2026-43416","CVE-2026-43472","CVE-2026-43483","CVE-2026-43492"],"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\nudp: Fix wildcard bind conflict check when using hash2\n\nWhen binding a udp_sock to a local address and port, UDP uses\ntwo hashes (udptable->hash and udptable->hash2) for collision\ndetection. The current code switches to "hash2" when\nhslot->count > 10.\n\n"hash2" is keyed by local address and local port.\n"hash" is keyed by local port only.\n\nThe issue can be shown in the following bind sequence (pseudo code):\n\nbind(fd1,  "[fd00::1]:8888")\nbind(fd2,  "[fd00::2]:8888")\nbind(fd3,  "[fd00::3]:8888")\nbind(fd4,  "[fd00::4]:8888")\nbind(fd5,  "[fd00::5]:8888")\nbind(fd6,  "[fd00::6]:8888")\nbind(fd7,  "[fd00::7]:8888")\nbind(fd8,  "[fd00::8]:8888")\nbind(fd9,  "[fd00::9]:8888")\nbind(fd10, "[fd00::10]:8888")\n\n/* Correctly return -EADDRINUSE because "hash" is used\n * instead of "hash2". udp_lib_lport_inuse() detects the\n * conflict.\n */\nbind(fail_fd, "[::]:8888")\n\n/* After one more socket is bound to "[fd00::11]:8888",\n * hslot->count exceeds 10 and "hash2" is used instead.\n */\nbind(fd11, "[fd00::11]:8888")\nbind(fail_fd, "[::]:8888")      /* succeeds unexpectedly */\n\nThe same issue applies to the IPv4 wildcard address "0.0.0.0"\nand the IPv4-mapped wildcard address "::ffff:0.0.0.0". For\nexample, if there are existing sockets bound to\n"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or\n"[::ffff:0.0.0.0]:8888" can also miss the conflict when\nhslot->count > 10.\n\nTCP inet_csk_get_port() already has the correct check in\ninet_use_bhash2_on_bind(). Rename it to\ninet_use_hash2_on_bind() and move it to inet_hashtables.h\nso udp.c can reuse it in this fix.(CVE-2026-31503)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Drain commands in target_reset handler\n\ntcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS\nwithout draining any in-flight commands.  The SCSI EH documentation\n(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver\nhas made lower layers "forget about timed out scmds" and is ready for new\ncommands.  Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,\nmpi3mr) enforces this by draining or completing outstanding commands before\nreturning SUCCESS.\n\nBecause tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight\nscsi_cmnd structures for recovery commands (e.g. TUR) while the target core\nstill has async completion work queued for the old se_cmd.  The memset in\nqueuecommand zeroes se_lun and lun_ref_active, causing\ntransport_lun_remove_cmd() to skip its percpu_ref_put().  The leaked LUN\nreference prevents transport_clear_lun_ref() from completing, hanging\nconfigfs LUN unlink forever in D-state:\n\n  INFO: task rm:264 blocked for more than 122 seconds.\n  rm              D    0   264    258 0x00004000\n  Call Trace:\n   __schedule+0x3d0/0x8e0\n   schedule+0x36/0xf0\n   transport_clear_lun_ref+0x78/0x90 [target_core_mod]\n   core_tpg_remove_lun+0x28/0xb0 [target_core_mod]\n   target_fabric_port_unlink+0x50/0x60 [target_core_mod]\n   configfs_unlink+0x156/0x1f0 [configfs]\n   vfs_unlink+0x109/0x290\n   do_unlinkat+0x1d5/0x2d0\n\nFix this by making tcm_loop_target_reset() actually drain commands:\n\n 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that\n    the target core knows about (those not yet CMD_T_COMPLETE).\n\n 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and\n    flush_work() on each se_cmd — this drains any deferred completion work\n    for commands that already had CMD_T_COMPLETE set before the TMR (which\n    the TMR skips via __target_check_io_state()).  This is the same pattern\n    used by mpi3mr, scsi_debug, and libsas to drain outstanding commands\n    during reset.(CVE-2026-43054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: correctly handle tunneled traffic on IPV6_CSUM GSO fallback\n\nNETIF_F_IPV6_CSUM only advertises support for checksum offload of\npackets without IPv6 extension headers. Packets with extension\nheaders must fall back onto software checksumming. Since TSO\ndepends on checksum offload, those must revert to GSO.\n\nThe below commit introduces that fallback. It always checks\nnetwork header length. For tunneled packets, the inner header length\nmust be checked instead. Extend the check accordingly.\n\nA special case is tunneled packets without inner IP protocol. Such as\nRFC 6951 SCTP in UDP. Those are not standard IPv6 followed by\ntransport header either, so also must revert to the software GSO path.(CVE-2026-43057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: annotate data-races around hdev->req_status\n\n__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:\n\n    hdev->req_status = HCI_REQ_PEND;\n\nHowever, several other functions read or write hdev->req_status without\nholding any lock:\n\n  - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)\n  - hci_cmd_sync_complete() reads/writes from HCI event completion\n  - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write\n  - hci_abort_conn() reads in connection abort path\n\nSince __hci_cmd_sync_sk() runs on hdev->req_workqueue while\nhci_send_cmd_sync() runs on hdev->workqueue, these are different\nworkqueues that can execute concurrently on different CPUs. The plain\nC accesses constitute a data race.\n\nAdd READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses\nto hdev->req_status to prevent potential compiler optimizations that\ncould affect correctness (e.g., load fusing in the wait_event\ncondition or store reordering).(CVE-2026-43119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: check return value of con2fb_acquire_newinfo()\n\nIf fbcon_open() fails when called from con2fb_acquire_newinfo() then\ninfo->fbcon_par pointer remains NULL which is later dereferenced.\n\nAdd check for return value of the function con2fb_acquire_newinfo() to\navoid it.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-43123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ\n\nThis adds a check for encryption key size upon receiving\nL2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which\nexpects L2CAP_CR_LE_BAD_KEY_SIZE.(CVE-2026-43134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: Move vbus draw to workqueue context\n\nCurrently dwc3_gadget_vbus_draw() can be called from atomic\ncontext, which in turn invokes power-supply-core APIs. And\nsome these PMIC APIs have operations that may sleep, leading\nto kernel panic.\n\nFix this by moving the vbus_draw into a workqueue context.(CVE-2026-43170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix URB leak in pvr2_send_request_ex\n\nWhen pvr2_send_request_ex() submits a write URB successfully but fails to\nsubmit the read URB (e.g. returns -ENOMEM), it returns immediately without\nwaiting for the write URB to complete. Since the driver reuses the same\nURB structure, a subsequent call to pvr2_send_request_ex() attempts to\nsubmit the still-active write URB, triggering a 'URB submitted while\nactive' warning in usb_submit_urb().\n\nFix this by ensuring the write URB is unlinked and waited upon if the read\nURB submission fails.(CVE-2026-43223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/uncore: Fix die ID init and look up bugs\n\nIn snbep_pci2phy_map_init(), in the nr_node_ids > 8 path,\nuncore_device_to_die() may return -1 when all CPUs associated\nwith the UBOX device are offline.\n\nRemove the WARN_ON_ONCE(die_id == -1) check for two reasons:\n\n- The current code breaks out of the loop. This is incorrect because\n  pci_get_device() does not guarantee iteration in domain or bus order,\n  so additional UBOX devices may be skipped during the scan.\n\n- Returning -EINVAL is incorrect, since marking offline buses with\n  die_id == -1 is expected and should not be treated as an error.\n\nSeparately, when NUMA is disabled on a NUMA-capable platform,\npcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die()\nto return -1 for all PCI devices.  As a result,\nspr_update_device_location(), used on Intel SPR and EMR, ignores the\ncorresponding PMON units and does not add them to the RB tree.\n\nFix this by using uncore_pcibus_to_dieid(), which retrieves topology\nfrom the UBOX GIDNIDMAP register and works regardless of whether NUMA\nis enabled in Linux.  This requires snbep_pci2phy_map_init() to be\nadded in spr_uncore_pci_init().\n\nKeep uncore_device_to_die() only for the nr_node_ids > 8 case, where\nNUMA is expected to be enabled.(CVE-2026-43344)\n\nThe Linux kernel Nouveau graphics driver has a race condition/null pointer dereference issue in DPCD (DisplayPort Configuration Data) AUX channel transmission processing. When the GPU device enters the suspend state due to runtime power management (runtime PM), if the user space program (such as through the /dev/drm_dp_ interface) attempts to initiate an AUX transfer request, the driver will try to access the GSP (Graphics System Processor) firmware code of the suspended device, causing the kernel to crash.(CVE-2026-43381)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: add a bunch of missing ceph_path_info initializers\n\nceph_mdsc_build_path() must be called with a zero-initialized\nceph_path_info parameter, or else the following\nceph_mdsc_free_path_info() may crash.\n\nExample crash (on Linux 6.18.12):\n\n  virt_to_cache: Object is not a Slab page!\n  WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmem_cache_free+0x316/0x400\n  [...]\n  Call Trace:\n   [...]\n   ceph_open+0x13d/0x3e0\n   do_dentry_open+0x134/0x480\n   vfs_open+0x2a/0xe0\n   path_openat+0x9a3/0x1160\n  [...]\n  cache_from_obj: Wrong slab cache. names_cache but object is from ceph_inode_info\n  WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmem_cache_free+0x2dd/0x400\n  [...]\n  kernel BUG at mm/slub.c:634!\n  Oops: invalid opcode: 0000 [#1] SMP NOPTI\n  RIP: 0010:__slab_free+0x1a4/0x350\n\nSome of the ceph_mdsc_build_path() callers had initializers, but\nothers had not, even though they were all added by commit 15f519e9f883\n("ceph: fix race condition validating r_parent before applying state").\nThe ones without initializer are suspectible to random crashes.  (I can\nimagine it could even be possible to exploit this bug to elevate\nprivileges.)\n\nUnfortunately, these Ceph functions are undocumented and its semantics\ncan only be derived from the code.  I see that ceph_mdsc_build_path()\ninitializes the structure only on success, but not on error.\n\nCalling ceph_mdsc_free_path_info() after a failed\nceph_mdsc_build_path() call does not even make sense, but that's what\nall callers do, and for it to be safe, the structure must be\nzero-initialized.  The least intrusive approach to fix this is\ntherefore to add initializers everywhere.(CVE-2026-43408)\n\nIn the Linux kernel, the following vulnerability has been resolved: powerpc, perf: Check that current->mm is alive before getting user callchain. It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools). In addition, move storing the top-level stack entry to generic perf_callchain_user to make sure the top-level entry is always captured, even if current->mm is NULL.(CVE-2026-43416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunshare: fix unshare_fs() handling\n\nThere's an unpleasant corner case in unshare(2), when we have a\nCLONE_NEWNS in flags and current->fs hadn't been shared at all; in that\ncase copy_mnt_ns() gets passed current->fs instead of a private copy,\nwhich causes interesting warts in proof of correctness]\n\n> I guess if private means fs->users == 1, the condition could still be true.\n\nUnfortunately, it's worse than just a convoluted proof of correctness.\nConsider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS\n(and current->fs->users == 1).\n\nWe pass current->fs to copy_mnt_ns(), all right.  Suppose it succeeds and\nflips current->fs->{pwd,root} to corresponding locations in the new namespace.\nNow we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).\nWe call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's\ndestroyed and its mount tree is dissolved, but...  current->fs->root and\ncurrent->fs->pwd are both left pointing to now detached mounts.\n\nThey are pinning those, so it's not a UAF, but it leaves the calling\nprocess with unshare(2) failing with -ENOMEM _and_ leaving it with\npwd and root on detached isolated mounts.  The last part is clearly a bug.\n\nThere is other fun related to that mess (races with pivot_root(), including\nthe one between pivot_root() and fork(), of all things), but this one\nis easy to isolate and fix - treat CLONE_NEWNS as "allocate a new\nfs_struct even if it hadn't been shared in the first place".  Sure, we could\ngo for something like "if both CLONE_NEWNS *and* one of the things that might\nend up failing after copy_mnt_ns() call in create_new_namespaces() are set,\nforce allocation of new fs_struct", but let's keep it simple - the cost\nof copy_fs_struct() is trivial.\n\nAnother benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets\na freshly allocated fs_struct, yet to be attached to anything.  That\nseriously simplifies the analysis...\n\nFWIW, that bug had been there since the introduction of unshare(2) ;-/(CVE-2026-43472)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated\n\nExplicitly set/clear CR8 write interception when AVIC is (de)activated to\nfix a bug where KVM leaves the interception enabled after AVIC is\nactivated.  E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8\nwill remain intercepted in perpetuity.\n\nOn its own, the dangling CR8 intercept is "just" a performance issue, but\ncombined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:\nSync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging\nintercept is fatal to Windows guests as the TPR seen by hardware gets\nwildly out of sync with reality.\n\nNote, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored\nwhen Virtual Interrupt Delivery is enabled, i.e. when APICv is active in\nKVM's world.  I.e. there's no need to trigger update_cr8_intercept(), this\nis firmly an SVM implementation flaw/detail.\n\nWARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should\nnever enter the guest with AVIC enabled and CR8 writes intercepted.\n\n[Squash fix to avic_deactivate_vmcb. - Paolo](CVE-2026-43483)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()\n\nYiming reports an integer underflow in mpi_read_raw_from_sgl() when\nsubtracting "lzeros" from the unsigned "nbytes".\n\nFor this to happen, the scatterlist "sgl" needs to occupy more bytes\nthan the "nbytes" parameter and the first "nbytes + 1" bytes of the\nscatterlist must be zero.  Under these conditions, the while loop\niterating over the scatterlist will count more zeroes than "nbytes",\nsubtract the number of zeroes from "nbytes" and cause the underflow.\n\nWhen commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally\nintroduced the bug, it couldn't be triggered because all callers of\nmpi_read_raw_from_sgl() passed a scatterlist whose length was equal to\n"nbytes".\n\nHowever since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto\ninterface without scatterlists"), the underflow can now actually be\ntriggered.  When invoking a KEYCTL_PKEY_ENCRYPT system call with a\nlarger "out_len" than "in_len" and filling the "in" buffer with zeroes,\ncrypto_akcipher_sync_prep() will create an all-zero scatterlist used for\nboth the "src" and "dst" member of struct akcipher_request and thereby\nfulfil the conditions to trigger the bug:\n\n  sys_keyctl()\n    keyctl_pkey_e_d_s()\n      asymmetric_key_eds_op()\n        software_key_eds_op()\n          crypto_akcipher_sync_encrypt()\n            crypto_akcipher_sync_prep()\n              crypto_akcipher_encrypt()\n                rsa_enc()\n                  mpi_read_raw_from_sgl()\n\nTo the user this will be visible as a DoS as the kernel spins forever,\ncausing soft lockup splats as a side effect.\n\nFix it.(CVE-2026-43492)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.3.13.143.oe2403sp3"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","bpftool-debuginfo-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-debuginfo-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-debugsource-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-devel-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-extra-modules-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-headers-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-source-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-tools-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","kernel-tools-devel-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","perf-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","perf-debuginfo-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","python3-perf-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.3.13.143.oe2403sp3.aarch64.rpm"],"src":["kernel-6.6.0-145.3.13.143.oe2403sp3.src.rpm"],"x86_64":["bpftool-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","bpftool-debuginfo-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-debuginfo-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-debugsource-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-devel-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-extra-modules-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-headers-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-source-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-tools-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","kernel-tools-devel-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","perf-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","perf-debuginfo-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","python3-perf-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.3.13.143.oe2403sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2495"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31503"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43119"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43123"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43223"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43344"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43381"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43472"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43483"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43492"}],"database_specific":{"severity":"High"}}