Vulnerability-Lookup

URL	Tags
https://git.kernel.org/stable/c/59eecf0ffde15670e…
https://git.kernel.org/stable/c/5fb69e1eeea9d6cba…
https://git.kernel.org/stable/c/7cadb03be37e76113…
https://git.kernel.org/stable/c/1d0bdbfe3e91c11f0…
https://git.kernel.org/stable/c/ea3cd36d7382d5f83…
https://git.kernel.org/stable/c/b255531b27da33657…

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < 59eecf0ffde15670e6a5e10c47be67f73d843b20 (git) Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < 5fb69e1eeea9d6cba80517e9f058b56b34bc3a81 (git) Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < 7cadb03be37e761130edb153544fe0770a842b19 (git) Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < 1d0bdbfe3e91c11f0a704c52443a9446a10d699c (git) Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < ea3cd36d7382d5f8309df04c275d20df139ed42c (git) Affected: 95118dd4edfec950898a00180c6f998df0a6406d , < b255531b27da336571411248c2a72a350662bd09 (git)	guessed
Linux	Linux	Affected: 5.17 Unaffected: 0 , < 5.17 (semver) Unaffected: 6.1.168 , ≤ 6.1.* (semver) Unaffected: 6.6.134 , ≤ 6.6.* (semver) Unaffected: 6.12.81 , ≤ 6.12.* (semver) Unaffected: 6.18.22 , ≤ 6.18.* (semver) Unaffected: 6.19.12 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix)	guessed

GHSA-6JMV-JJW5-5RWP

Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-03 09:33

Details

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt

hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently.

Extend the hci_dev_lock critical section to cover all conn usage.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-43018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-01T15:16:45Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt\n\nhci_conn lookup and field access must be covered by hdev lock in\nhci_le_remote_conn_param_req_evt, otherwise it\u0027s possible it is freed\nconcurrently.\n\nExtend the hci_dev_lock critical section to cover all conn usage.",
  "id": "GHSA-6jmv-jjw5-5rwp",
  "modified": "2026-05-03T09:33:10Z",
  "published": "2026-05-01T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43018"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1d0bdbfe3e91c11f0a704c52443a9446a10d699c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/59eecf0ffde15670e6a5e10c47be67f73d843b20"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5fb69e1eeea9d6cba80517e9f058b56b34bc3a81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7cadb03be37e761130edb153544fe0770a842b19"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b255531b27da336571411248c2a72a350662bd09"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ea3cd36d7382d5f8309df04c275d20df139ed42c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

OESA-2026-2312 (CVE-2026-31436)

Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()

At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks.

Fix this by completing d instead of found in the final list_for_each_entry_safe() loop.(CVE-2026-31436)

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/core) Protect regulator operations with mutex

The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions.

However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex.

Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker.

Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset().

While at it, remove the unnecessary include of linux/of.h.(CVE-2026-31486)

In the Linux kernel, the following vulnerability has been resolved:

net: fix fanout UAF in packet_release() via NETDEV_UP race

packet_release() has a race window where NETDEV_UP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanout_release(), leaving a dangling pointer in the fanout array. packet_release() does NOT zero po->num in its bind_lock section. After releasing bind_lock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packet_notifier(NETDEV_UP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls __fanout_link(sk, po) which adds the socket back into f->arr[] and increments f->num_members, but does NOT increment f->sk_ref.

The fix sets po->num to zero in packet_release while bind_lock is held to prevent NETDEV_UP from linking, preventing the race window.

This bug was found following an additional audit with Claude Code based on CVE-2025-38617.(CVE-2026-31504)

In the Linux kernel, the following vulnerability has been resolved:

af_key: validate families in pfkey_send_migrate()

syzbot was able to trigger a crash in skb_put() [1]

Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb.

Validate families early, do not wait set_ipsecrequest().

[1]

skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<NULL> kernel BUG at net/core/skbuff.c:214 ! Call Trace: <TASK> skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150(CVE-2026-31515)

In the Linux kernel, the following vulnerability has been resolved:

mm/userfaultfd: fix hugetlb fault mutex hash calculation

In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release().

Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index().(CVE-2026-31575)

In the Linux kernel, the following vulnerability has been resolved:

HID: core: clamp report_size in s32ton() to avoid undefined shift

s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field().

Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_event") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way.

Fix this up by just clamping the max value of n, just like snto32() does.(CVE-2026-31624)

In the Linux kernel, the following vulnerability has been resolved:

HID: alps: fix NULL pointer dereference in alps_raw_event()

Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at raw event handle"), but the alps driver was missed.

Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.(CVE-2026-31625)

In the Linux kernel, the following vulnerability has been resolved:

af_unix: read UNIX_DIAG_VFS data under unix_state_lock

Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking.

Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock.

This keeps the VFS data stable while the reply is being built.(CVE-2026-31673)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()

Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.

rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.(CVE-2026-31674)

In the Linux kernel, the following vulnerability has been resolved:

bridge: br_nd_send: linearize skb before parsing ND options

br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request.

Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer.

Linearize request before option parsing and derive ns from the linear network header.(CVE-2026-31682)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: lag: Check for LAG device before creating debugfs

__mlx5_lag_dev_add_mdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5_ldev_add_debugfs() even when there is no valid LAG context.

mlx5_ldev_add_debugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL.

Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer before attempting to create the debugfs entries.(CVE-2026-43013)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: validate mesh send advertising payload length

mesh_send() currently bounds MGMT_OP_MESH_SEND by total command length, but it never verifies that the bytes supplied for the flexible adv_data[] array actually match the embedded adv_data_len field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer.

Keep rejecting zero-length and oversized advertising payloads, but validate adv_data_len explicitly and require the command length to exactly match the flexible array size before queueing the request.(CVE-2026-43017)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt

hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently.

Extend the hci_dev_lock critical section to cover all conn usage.(CVE-2026-43018)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync

hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently.

Take hdev lock to prevent hci_conn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration.(CVE-2026-43019)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()

Add SRCU read-side protection when reading PDPTR registers in __get_sregs2().

Reading PDPTRs may trigger access to guest memory: kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot()

kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(), which uses srcu_dereference_check() and requires either kvm->srcu or kvm->slots_lock to be held. Currently only vcpu->mutex is held, triggering lockdep warning:

============================= WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot 6.12.59+ #3 Not tainted

include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590

Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2026-43214)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()

Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as something has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects.

As explained in the Fixes commits, it should be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state.

Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where KVM would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running.(CVE-2026-43265)

In the Linux kernel xfrm/ESP (IPsec) subsystem, when appending pipe pages to network packets (skb) via zero-copy mechanisms such as splice() / MSG_SPLICE_PAGES, IPv4/IPv6 datagram paths are not correctly marked with the SKBFL_SHARED_FRAG flag. The ESP receive path incorrectly treats these externally owned shared pages as private data, skipping the COW (copy-on-write) step and performing in-place decryption directly, allowing an attacker to pollute otherwise read-only pages in the page cache. Combined with CVE-2026-43500, a complete exploit chain can be formed, allowing local unprivileged users to obtain root privileges. This vulnerability affects almost all Linux distributions since 2017 (kernel ~ 4.10), including Ubuntu, RHEL, AlmaLinux, Debian, Fedora, etc. A public PoC has been released and signs of active exploitation have been observed.(CVE-2026-43284)

A NULL-pointer dereference vulnerability exists in the ACPI processor driver of the Linux kernel. In the acpi_processor_errata_piix4() function, the pointer dev is first assigned an IDE device and then reassigned an ISA device. If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called. The fix is to use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value.(CVE-2026-43313)

In the Linux kernel x86 APIC (Advanced Programmable Interrupt Controller) subsystem, when the system resumes from suspend (s2ram/suspend-to-RAM) state, if the kernel expects to disable x2APIC mode at startup, but the BIOS/firmware re-enables x2APIC during the recovery process, the kernel and hardware status will be inconsistent. This status mismatch may cause interrupt handling exceptions, system instability, or denial of service. The vulnerability belongs to CWE-372 (Internal State Corruption).(CVE-2026-43363)

In the Linux kernel, there is a race condition vulnerability in the Ceph filesystem. During async unlink, the i_nlink counter is dropped before receiving the completion (that will eventually update the i_nlink) because "we assume that the unlink will succeed". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one:

WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023

In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the i_nlink counter to the value received from the MDS. If that new i_nlink value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then.

The root cause of this vulnerability is updating the i_nlink counter without proper lock protection, creating a TOCTOU (Time-of-Check Time-of-Use) race condition. Since ceph_fill_inode() and handle_cap_grant() both hold the ceph_inode_info.i_ceph_lock spinlock while set_nlink() runs, this seems like the proper lock to protect the i_nlink updates.(CVE-2026-43420)

In the Linux kernel, there is a security vulnerability in the USB Test and Measurement Class driver (usbtmc). The driver accepts timeout values specified by the user via an ioctl command and uses these timeouts for usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, this may cause kernel threads to hang indefinitely.(CVE-2026-43429)

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31436	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31486	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31504	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31515	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31575	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31624	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31625	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31673	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31674	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31682	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43013	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43017	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43018	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43019	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43214	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43265	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43284	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43313	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43363	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43420	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43429	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "perf-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-145.0.10.137.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.0.10.137.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.0.10.137.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "perf-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-145.0.10.137.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.0.10.137.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.0.10.137.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\ndmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()\n\nAt the end of this function, d is the traversal cursor of flist, but the\ncode completes found instead. This can lead to issues such as NULL pointer\ndereferences, double completion, or descriptor leaks.\n\nFix this by completing d instead of found in the final\nlist_for_each_entry_safe() loop.(CVE-2026-31436)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus/core) Protect regulator operations with mutex\n\nThe regulator operations pmbus_regulator_get_voltage(),\npmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()\naccess PMBus registers and shared data but were not protected by\nthe update_lock mutex. This could lead to race conditions.\n\nHowever, adding mutex protection directly to these functions causes\na deadlock because pmbus_regulator_notify() (which calls\nregulator_notifier_call_chain()) is often called with the mutex\nalready held (e.g., from pmbus_fault_handler()). If a regulator\ncallback then calls one of the now-protected voltage functions,\nit will attempt to acquire the same mutex.\n\nRework pmbus_regulator_notify() to utilize a worker function to\nsend notifications outside of the mutex protection. Events are\nstored as atomics in a per-page bitmask and processed by the worker.\n\nInitialize the worker and its associated data during regulator\nregistration, and ensure it is cancelled on device removal using\ndevm_add_action_or_reset().\n\nWhile at it, remove the unnecessary include of linux/of.h.(CVE-2026-31486)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix fanout UAF in packet_release() via NETDEV_UP race\n\n`packet_release()` has a race window where `NETDEV_UP` can re-register a\nsocket into a fanout group\u0026apos;s `arr[]` array. The re-registration is not\ncleaned up by `fanout_release()`, leaving a dangling pointer in the fanout\narray.\n`packet_release()` does NOT zero `po-\u0026gt;num` in its `bind_lock` section.\nAfter releasing `bind_lock`, `po-\u0026gt;num` is still non-zero and `po-\u0026gt;ifindex`\nstill matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`\nthat already found the socket in `sklist` can re-register the hook.\nFor fanout sockets, this re-registration calls `__fanout_link(sk, po)`\nwhich adds the socket back into `f-\u0026gt;arr[]` and increments `f-\u0026gt;num_members`,\nbut does NOT increment `f-\u0026gt;sk_ref`.\n\nThe fix sets `po-\u0026gt;num` to zero in `packet_release` while `bind_lock` is\nheld to prevent NETDEV_UP from linking, preventing the race window.\n\nThis bug was found following an additional audit with Claude Code based\non CVE-2025-38617.(CVE-2026-31504)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_key: validate families in pfkey_send_migrate()\n\nsyzbot was able to trigger a crash in skb_put() [1]\n\nIssue is that pfkey_send_migrate() does not check old/new families,\nand that set_ipsecrequest() @family argument was truncated,\nthus possibly overfilling the skb.\n\nValidate families early, do not wait set_ipsecrequest().\n\n[1]\n\nskbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:\u0026lt;NULL\u0026gt;\n kernel BUG at net/core/skbuff.c:214 !\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_over_panic net/core/skbuff.c:219 [inline]\n  skb_put+0x159/0x210 net/core/skbuff.c:2655\n  skb_put_zero include/linux/skbuff.h:2788 [inline]\n  set_ipsecrequest net/key/af_key.c:3532 [inline]\n  pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636\n  km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848\n  xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705\n  xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150(CVE-2026-31515)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/userfaultfd: fix hugetlb fault mutex hash calculation\n\nIn mfill_atomic_hugetlb(), linear_page_index() is used to calculate the\npage index for hugetlb_fault_mutex_hash().  However, linear_page_index()\nreturns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()\nexpects the index in huge page units.  This mismatch means that different\naddresses within the same huge page can produce different hash values,\nleading to the use of different mutexes for the same huge page.  This can\ncause races between faulting threads, which can corrupt the reservation\nmap and trigger the BUG_ON in resv_map_release().\n\nFix this by introducing hugetlb_linear_page_index(), which returns the\npage index in huge page granularity, and using it in place of\nlinear_page_index().(CVE-2026-31575)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: clamp report_size in s32ton() to avoid undefined shift\n\ns32ton() shifts by n-1 where n is the field\u0026apos;s report_size, a value that\ncomes directly from a HID device.  The HID parser bounds report_size\nonly to \u0026lt;= 256, so a broken HID device can supply a report descriptor\nwith a wide field that triggers shift exponents up to 256 on a 32-bit\ntype when an output report is built via hid_output_field() or\nhid_set_field().\n\nCommit ec61b41918587 (\u0026quot;HID: core: fix shift-out-of-bounds in\nhid_report_raw_event\u0026quot;) added the same n \u0026gt; 32 clamp to the function\nsnto32(), but s32ton() was never given the same fix as I guess syzbot\nhadn\u0026apos;t figured out how to fuzz a device the same way.\n\nFix this up by just clamping the max value of n, just like snto32()\ndoes.(CVE-2026-31624)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: alps: fix NULL pointer dereference in alps_raw_event()\n\nCommit ecfa6f34492c (\u0026quot;HID: Add HID_CLAIMED_INPUT guards in raw_event\ncallbacks missing them\u0026quot;) attempted to fix up the HID drivers that had\nmissed the previous fix that was done in 2ff5baa9b527 (\u0026quot;HID: appleir:\nFix potential NULL dereference at raw event handle\u0026quot;), but the alps\ndriver was missed.\n\nFix this up by properly checking in the hid-alps driver that it had been\nclaimed correctly before attempting to process the raw event.(CVE-2026-31625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: read UNIX_DIAG_VFS data under unix_state_lock\n\nExact UNIX diag lookups hold a reference to the socket, but not to\nu-\u0026gt;path. Meanwhile, unix_release_sock() clears u-\u0026gt;path under\nunix_state_lock() and drops the path reference after unlocking.\n\nRead the inode and device numbers for UNIX_DIAG_VFS while holding\nunix_state_lock(), then emit the netlink attribute after dropping the\nlock.\n\nThis keeps the VFS data stable while the reply is being built.(CVE-2026-31673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()\n\nReject rt match rules whose addrnr exceeds IP6T_RT_HOPS.\n\nrt_mt6() expects addrnr to stay within the bounds of rtinfo-\u0026gt;addrs[].\nValidate addrnr during rule installation so malformed rules are rejected\nbefore the match logic can use an out-of-range value.(CVE-2026-31674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: br_nd_send: linearize skb before parsing ND options\n\nbr_nd_send() parses neighbour discovery options from ns-\u0026gt;opt[] and\nassumes that these options are in the linear part of request.\n\nIts callers only guarantee that the ICMPv6 header and target address\nare available, so the option area can still be non-linear. Parsing\nns-\u0026gt;opt[] in that case can access data past the linear buffer.\n\nLinearize request before option parsing and derive ns from the linear\nnetwork header.(CVE-2026-31682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: lag: Check for LAG device before creating debugfs\n\n__mlx5_lag_dev_add_mdev() may return 0 (success) even when an error\noccurs that is handled gracefully. Consequently, the initialization\nflow proceeds to call mlx5_ldev_add_debugfs() even when there is no\nvalid LAG context.\n\nmlx5_ldev_add_debugfs() blindly created the debugfs directory and\nattributes. This exposed interfaces (like the members file) that rely on\na valid ldev pointer, leading to potential NULL pointer dereferences if\naccessed when ldev is NULL.\n\nAdd a check to verify that mlx5_lag_dev(dev) returns a valid pointer\nbefore attempting to create the debugfs entries.(CVE-2026-43013)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate mesh send advertising payload length\n\nmesh_send() currently bounds MGMT_OP_MESH_SEND by total command\nlength, but it never verifies that the bytes supplied for the\nflexible adv_data[] array actually match the embedded adv_data_len\nfield. MGMT_MESH_SEND_SIZE only covers the fixed header, so a\ntruncated command can still pass the existing 20..50 byte range\ncheck and later drive the async mesh send path past the end of the\nqueued command buffer.\n\nKeep rejecting zero-length and oversized advertising payloads, but\nvalidate adv_data_len explicitly and require the command length to\nexactly match the flexible array size before queueing the request.(CVE-2026-43017)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt\n\nhci_conn lookup and field access must be covered by hdev lock in\nhci_le_remote_conn_param_req_evt, otherwise it\u0026apos;s possible it is freed\nconcurrently.\n\nExtend the hci_dev_lock critical section to cover all conn usage.(CVE-2026-43018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: fix potential UAF in set_cig_params_sync\n\nhci_conn lookup and field access must be covered by hdev lock in\nset_cig_params_sync, otherwise it\u0026apos;s possible it is freed concurrently.\n\nTake hdev lock to prevent hci_conn from being deleted or modified\nconcurrently.  Just RCU lock is not suitable here, as we also want to\navoid \u0026quot;tearing\u0026quot; in the configuration.(CVE-2026-43019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()\n\nAdd SRCU read-side protection when reading PDPTR registers in\n__get_sregs2().\n\nReading PDPTRs may trigger access to guest memory:\nkvm_pdptr_read() -\u0026gt; svm_cache_reg() -\u0026gt; load_pdptrs() -\u0026gt;\nkvm_vcpu_read_guest_page() -\u0026gt; kvm_vcpu_gfn_to_memslot()\n\nkvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),\nwhich uses srcu_dereference_check() and requires either kvm-\u0026gt;srcu or\nkvm-\u0026gt;slots_lock to be held. Currently only vcpu-\u0026gt;mutex is held,\ntriggering lockdep warning:\n\n=============================\nWARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot\n6.12.59+ #3 Not tainted\n\ninclude/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by syz.5.1717/15100:\n #0: ff1100002f4b00b0 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120\n lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824\n __kvm_memslots include/linux/kvm_host.h:1062 [inline]\n __kvm_memslots include/linux/kvm_host.h:1059 [inline]\n kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline]\n kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617\n kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302\n load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065\n svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688\n kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline]\n __get_sregs2 arch/x86/kvm/x86.c:11784 [inline]\n kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279\n kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2026-43214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()\n\nIgnore -EBUSY when checking nested events after exiting a blocking state\nwhile L2 is active, as exiting to userspace will generate a spurious\nuserspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM\u0026apos;s\ndemise.  Continuing with the wakeup isn\u0026apos;t perfect either, as *something*\nhas gone sideways if a vCPU is awakened in L2 with an injected event (or\nworse, a nested run pending), but continuing on gives the VM a decent\nchance of surviving without any major side effects.\n\nAs explained in the Fixes commits, it _should_ be impossible for a vCPU to\nbe put into a blocking state with an already-injected event (exception,\nIRQ, or NMI).  Unfortunately, userspace can stuff MP_STATE and/or injected\nevents, and thus put the vCPU into what should be an impossible state.\n\nDon\u0026apos;t bother trying to preserve the WARN, e.g. with an anti-syzkaller\nKconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be\nviolating x86 architecture, e.g. by WARNing if KVM attempts to inject an\nexception or interrupt while the vCPU isn\u0026apos;t running.(CVE-2026-43265)\n\nIn the Linux kernel xfrm/ESP (IPsec) subsystem, when appending pipe pages to network packets (skb) via zero-copy mechanisms such as splice() / MSG_SPLICE_PAGES, IPv4/IPv6 datagram paths are not correctly marked with the SKBFL_SHARED_FRAG flag. The ESP receive path incorrectly treats these externally owned shared pages as private data, skipping the COW (copy-on-write) step and performing in-place decryption directly, allowing an attacker to pollute otherwise read-only pages in the page cache. Combined with CVE-2026-43500, a complete exploit chain can be formed, allowing local unprivileged users to obtain root privileges. This vulnerability affects almost all Linux distributions since 2017 (kernel ~ 4.10), including Ubuntu, RHEL, AlmaLinux, Debian, Fedora, etc. A public PoC has been released and signs of active exploitation have been observed.(CVE-2026-43284)\n\nA NULL-pointer dereference vulnerability exists in the ACPI processor driver of the Linux kernel. In the acpi_processor_errata_piix4() function, the pointer dev is first assigned an IDE device and then reassigned an ISA device. If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called. The fix is to use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value.(CVE-2026-43313)\n\nIn the Linux kernel x86 APIC (Advanced Programmable Interrupt Controller) subsystem, when the system resumes from suspend (s2ram/suspend-to-RAM) state, if the kernel expects to disable x2APIC mode at startup, but the BIOS/firmware re-enables x2APIC during the recovery process, the kernel and hardware status will be inconsistent. This status mismatch may cause interrupt handling exceptions, system instability, or denial of service. The vulnerability belongs to CWE-372 (Internal State Corruption).(CVE-2026-43363)\n\nIn the Linux kernel, there is a race condition vulnerability in the Ceph filesystem. During async unlink, the `i_nlink` counter is dropped before receiving the completion (that will eventually update the `i_nlink`) because \u0026quot;we assume that the unlink will succeed\u0026quot;. That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one:\n\nWARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68\nModules linked in:\nCPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655\nHardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023\n\nIn ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then.\n\nThe root cause of this vulnerability is updating the `i_nlink` counter without proper lock protection, creating a TOCTOU (Time-of-Check Time-of-Use) race condition. Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates.(CVE-2026-43420)\n\nIn the Linux kernel, there is a security vulnerability in the USB Test and Measurement Class driver (usbtmc). The driver accepts timeout values specified by the user via an ioctl command and uses these timeouts for usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, this may cause kernel threads to hang indefinitely.(CVE-2026-43429)",
  "id": "OESA-2026-2312",
  "modified": "2026-08-06T11:11:17Z",
  "published": "2026-05-15T11:11:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31436"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31486"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31504"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31515"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31575"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31624"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31682"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43013"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43018"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43214"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43313"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43363"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43420"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43429"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-31436",
    "CVE-2026-31486",
    "CVE-2026-31504",
    "CVE-2026-31515",
    "CVE-2026-31575",
    "CVE-2026-31624",
    "CVE-2026-31625",
    "CVE-2026-31673",
    "CVE-2026-31674",
    "CVE-2026-31682",
    "CVE-2026-43013",
    "CVE-2026-43017",
    "CVE-2026-43018",
    "CVE-2026-43019",
    "CVE-2026-43214",
    "CVE-2026-43265",
    "CVE-2026-43284",
    "CVE-2026-43313",
    "CVE-2026-43363",
    "CVE-2026-43420",
    "CVE-2026-43429"
  ]
}

OESA-2026-2313 (CVE-2026-31436)