{"id":"OESA-2026-3303","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\ncomedi: me4000: Fix potential overrun of firmware buffer\n\n`me4000_xilinx_download()` loads the firmware that was requested by\n`request_firmware()`.  It is possible for it to overrun the source\nbuffer because it blindly trusts the file format.  It reads a data\nstream length from the first 4 bytes into variable `file_length` and\nreads the data stream contents of length `file_length` from offset 16\nonwards.\n\nAdd a test to ensure that the supplied firmware is long enough to\ncontain the header and the data stream.  On failure, log an error and\nreturn `-EINVAL`.\n\nNote: The firmware loading was totally broken before commit ac584af59945\n("staging: comedi: me4000: fix firmware downloading"), but that is the\nmost sensible target for this fix.(CVE-2026-31747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: soc-core: flush delayed work before removing DAIs and widgets\n\nWhen a sound card is unbound while a PCM stream is open, a\nuse-after-free can occur in snd_soc_dapm_stream_event(), called from\nthe close_delayed_work workqueue handler.\n\nDuring unbind, snd_soc_unbind_card() flushes delayed work and then\ncalls soc_cleanup_card_resources(). Inside cleanup,\nsnd_card_disconnect_sync() releases all PCM file descriptors, and\nthe resulting PCM close path can call snd_soc_dapm_stream_stop()\nwhich schedules new delayed work with a pmdown_time timer delay.\nSince this happens after the flush in snd_soc_unbind_card(), the\nnew work is not caught. soc_remove_link_components() then frees\nDAPM widgets before this work fires, leading to the use-after-free.\n\nThe existing flush in soc_free_pcm_runtime() also cannot help as it\nruns after soc_remove_link_components() has already freed the widgets.\n\nAdd a flush in soc_cleanup_card_resources() after\nsnd_card_disconnect_sync() (after which no new PCM closes can\nschedule further delayed work) and before soc_remove_link_dais()\nand soc_remove_link_components() (which tear down the structures the\ndelayed work accesses).(CVE-2026-43459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free\n\ndlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages\nto userspace but sets no vm_ops on the VMA. This means the kernel cannot\ntrack active mmaps. When dlfb_realloc_framebuffer() replaces the backing\nbuffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.\nOn USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages\nwhile userspace PTEs still reference them, resulting in a use-after-free:\nthe process retains read/write access to freed kernel pages.\n\nAdd vm_operations_struct with open/close callbacks that maintain an\natomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),\ncheck mmap_count and return -EBUSY if the buffer is currently mapped,\npreventing buffer replacement while userspace holds stale PTEs.\n\nTested with PoC using dummy_hcd + raw_gadget USB device emulation.(CVE-2026-43497)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umem: Fix truncation for block sizes >= 4G\n\nWhen the iommu is used the linearization of the mapping can give a single\nblock that is very large split across multiple SG entries.\n\nWhen __rdma_block_iter_next() reassembles the split SG entries it is\noverflowing the 32 bit stack values and computed the wrong DMA addresses\nfor blocks after the truncation.\n\nUse the right types to hold DMA addresses.(CVE-2026-53133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()\n\npppol2tp_ioctl() read sock->sk->sk_user_data directly without any\nlocks or reference counting.  If a controllable sleep was induced during\ncopy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent\nsocket close could trigger pppol2tp_session_close() asynchronously.  This\nfrees the l2tp_session structure via the l2tp_session_del_work workqueue.\nUpon resuming, the ioctl thread dereferences the stale session pointer,\nresulting in a Use-After-Free (UAF).\n\nFix this by securely fetching the session reference using the RCU-safe,\nrefcounted helper pppol2tp_sock_to_session(sk) on entry.  This locks the\nsession's refcount across the sleep.  We structured the function to exit\nvia standard err breaks, guaranteeing that l2tp_session_put() is cleanly\ncalled on all return paths to drop the reference.\n\nTo preserve existing behavior we validate the session and its magic\nsignature only for the specific L2TP commands that require it.  This\nensures that generic/unknown ioctls called on an unconnected socket\nstill return -ENOIOCTLCMD and correctly fall back to generic handlers\n(e.g. in sock_do_ioctl()).(CVE-2026-53262)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before replacing page cache folio\n\nfuse_try_move_folio() unlocks the request on entry but does not\nre-lock it on the success path. This means fuse_chan_abort() can end the\nrequest and free the fuse_io_args (eg fuse_readpages_end()) while the\nsubsequent copy chain logic after fuse_try_move_folio() accesses the\nfuse_io_args, leading to use-after-free issues.\n\nFix this by calling lock_request() before replace_page_cache_folio().\nThis ensures the request is locked on the success path which will\nprevent the fuse_io_args from being freed while the later copying logic\nruns, and also ensures that the ap->folios[i]->mapping is never null\nsince ap->folios[i] will always point to the newfolio after\nreplace_page_cache_folio().(CVE-2026-53388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: core: fix adapter registration race\n\nAdapters can be looked up based on their id using i2c_get_adapter()\nwhich takes a reference to the embedded struct device.\n\nMake sure that the adapter (including its struct device) has been\ninitialised before adding it to the IDR to avoid accessing uninitialised\ndata which could, for example, lead to NULL-pointer dereferences or\nuse-after-free.\n\nNote that the i2c-dev chardev, which is registered from a bus notifier,\ncurrently uses i2c_get_adapter() so the adapter needs to be added to the\nIDR before registration.(CVE-2026-53400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngcov: use atomic counter updates to fix concurrent access crashes\n\nGCC's GCOV instrumentation can merge global branch counters with loop\ninduction variables as an optimization.  In inflate_fast(), the inner copy\nloops get transformed so that the GCOV counter value is loaded multiple\ntimes to compute the loop base address, start index, and end bound.  Since\nGCOV counters are global (not per-CPU), concurrent execution on different\nCPUs causes the counter to change between loads, producing inconsistent\nvalues and out-of-bounds memory writes.\n\nThe crash manifests during IPComp (IP Payload Compression) processing when\ninflate_fast() runs concurrently on multiple CPUs:\n\n  BUG: unable to handle page fault for address: ffffd0a3c0902ffa\n  RIP: inflate_fast+1431\n  Call Trace:\n   zlib_inflate\n   __deflate_decompress\n   crypto_comp_decompress\n   ipcomp_decompress [xfrm_ipcomp]\n   ipcomp_input [xfrm_ipcomp]\n   xfrm_input\n\nAt the crash point, the compiler generated three loads from the same\nglobal GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and\nend for an indexed loop.  Another CPU modified the counter between loads,\nmaking the values inconsistent - the write went 3.4 MB past a 65 KB\nbuffer.\n\nAdd -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in\nthe top-level Makefile, guarded by a try-run compile test.  The test\ncompiles a minimal program with and without -fprofile-update=prefer-atomic\nusing the full KBUILD_CFLAGS, then compares undefined symbols in the\nresulting object files.  If prefer-atomic introduces new undefined\nreferences (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax\non arm64 with outline-atomics), the flag is not added -- the kernel does\nnot link against libatomic.\n\nOn architectures where GCC inlines 64-bit atomic counter updates (x86_64,\ns390, ...) the test passes and the flag is enabled, preventing the\ncompiler from merging counters with loop induction variables and fixing\nthe observed concurrent-access crash.\n\nOn architectures where the flag would introduce libatomic dependencies, it\nis silently omitted and behaviour is no worse than before this patch.\n\nMove the CFLAGS_GCOV block from its original position (before the arch\nMakefile include) to after the core KBUILD_CFLAGS assignments but before\nthe scripts/Makefile.gcc-plugins include.  This placement ensures the\ntry-run test sees arch-specific flags (-m32, -march=,\n-mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that\nwould break the test on clean builds when plugin shared objects do not yet\nexist.(CVE-2026-63825)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns->rawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns->lock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips "saturated" and "underflow" warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 ("apparmor: fix race on rawdata\ndereference") the dedup path used a get_unless_zero-style helper\non a single counter, so the existing "if (tmp)" guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles.(CVE-2026-63827)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf\n\niscsi_encode_text_output() concatenates "key=value\\0" records into\nlogin->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer\nallocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call\nsites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check\nthe remaining buffer capacity:\n\n\t*length += sprintf(output_buf, "%s=%s", er->key, er->value);\n\t*length += 1;\n\toutput_buf = textbuf + *length;\n\nThe 8192-byte ceiling at iscsi_target_check_login_request() bounds the\n*input* Login PDU payload, but a single PDU can carry up to 2048 minimal\nfour-byte "a=b\\0" pairs, each unknown key expanding to a 16-byte\n"a=NotUnderstood\\0" output record via iscsi_add_notunderstood_response().\n2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB\nheap overrun in the kmalloc-8k slab.\n\nThe fix introduces a static iscsi_encode_text_record() helper that uses\nsnprintf() with a per-call bounds check against the remaining buffer,\nand threads a u32 textbuf_size parameter through\niscsi_encode_text_output(). Both call sites in\niscsi_target_handle_csg_zero() (PHASE_SECURITY) and\niscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass\nMAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls\niscsi_release_extra_responses() to drop queued records, and returns -1;\nboth caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR /\nISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning,\nso the initiator sees an explicit failed-login response rather than a\nsilent connection drop. (Prior to this patch only the PHASE_OPERATIONAL\ncaller did that; the PHASE_SECURITY caller is converted to the same\nshape.)(CVE-2026-63887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()\n\nTwo latent bugs in the Text-phase handler, both present since the\noriginal LIO integration in commit e48354ce078c ("iscsi-target: Add\niSCSI fabric support for target v4.1"):\n\n1) DataDigest CRC buffer overread (4 bytes past text_in).\n\n   text_in is kzalloc()'d at ALIGN(payload_length, 4).  rx_size is then\n   incremented by ISCSI_CRC_LEN to make room for the received DataDigest\n   in the iovec, but the same (now-bumped) rx_size is passed as the\n   buffer length to iscsit_crc_buf():\n\n       if (conn->conn_ops->DataDigest) {\n               ...\n               rx_size += ISCSI_CRC_LEN;\n       }\n       ...\n       if (conn->conn_ops->DataDigest) {\n               data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);\n\n   iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so\n   when DataDigest is negotiated it reads 4 bytes past the end of the\n   text_in allocation.  KASAN reproduces this directly on the unpatched\n   mainline tree as slab-out-of-bounds in crc32c() called from the Text\n   PDU path.  The OOB bytes feed crc32c() and are then compared against\n   the initiator-supplied checksum, so the value does not flow back to\n   the attacker, but the kernel does read past the buffer on every Text\n   PDU with DataDigest=CRC32C.\n\n   Fix by passing the actual padded payload length\n   (ALIGN(payload_length, 4)) that was used for the kzalloc().\n\n2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest\n   drop.\n\n   On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler\n   silently drops the PDU and lets the initiator plug the CmdSN gap:\n\n               kfree(text_in);\n               return 0;\n\n   cmd->text_in_ptr still points at the freed buffer.  The next Text\n   Request on the same ITT re-enters iscsit_setup_text_cmd(), which\n   unconditionally does\n\n       kfree(cmd->text_in_ptr);\n       cmd->text_in_ptr = NULL;\n\n   freeing the same pointer a second time.  Session teardown via\n   iscsit_release_cmd() has the same shape and hits the same double-free\n   if the connection is dropped before a second Text Request arrives.\n\n   On an unmodified mainline tree the bug-1 CRC overread fires first on\n   the initial valid Text Request and perturbs the subsequent state, so\n   #4 was isolated by building a kernel with only the bug-1 hunk of this\n   patch applied plus temporary printk() observability around the three\n   relevant kfree() sites.  The observability prints are not part of\n   this patch.  On that build, a three-PDU Text Request sequence after\n   login produces two back-to-back splats:\n\n       BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??\n       BUG: KASAN: double-free in iscsit_release_cmd+0x??\n\n   showing the same pointer freed in the ERL>0 drop path and again in\n   iscsit_setup_text_cmd() (next Text Request on the same ITT) and once\n   more in iscsit_release_cmd() (session teardown).  On distro kernels\n   with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free\n   becomes a remote kernel BUG(); on non-hardened kernels it corrupts\n   the slab freelist.\n\n   Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop\n   path.  With both hunks applied #4 is directly observable on the stock\n   tree without observability printks; fixing bug-1 alone would mask #4\n   less, not more, so the hunks are submitted together.\n\nBoth fixes are one-liners.  The Text PDU state machine is unchanged and\nthe wire protocol is unaffected.(CVE-2026-63888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: cypress_m8: fix memory corruption with small endpoint\n\nMake sure that the interrupt-out endpoint max packet size is at least\neight bytes to avoid user-controlled slab corruption or NULL-pointer\ndereference should a malicious device report a smaller size.(CVE-2026-63956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\n\nIf dcid is received for an already-assigned destination CID the spec\nrequires that both channels to be discarded, but calling l2cap_chan_del\nmay invalidate the tmp cursor created by list_for_each_entry_safe and\nin fact it is the wrong procedure as the chan->dcid may be assigned\npreviously it really needs to be disconnected.\n\nCalling l2cap_chan_clone directly may still lead to l2cap_chan_del so\ninstead schedule l2cap_chan_timeout with delay 0 to close the channel\nasynchronously.(CVE-2026-63975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: fix double free in qed_cxt_tables_alloc()\n\nIf one of the later PF or VF CID bitmap allocations fails,\nqed_cid_map_alloc() jumps to cid_map_fail and frees the previously\nallocated CID bitmaps before returning an error. qed_cxt_tables_alloc()\nthen calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()\nagain.\n\nFix this by setting each CID bitmap pointer to NULL after bitmap_free()\nto avoid double free.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still\npresent in v7.1-rc3.\n\nRuntime reproduction was not attempted because exercising the failing\nallocation path requires device-specific setup.(CVE-2026-64118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: qup: fix error pointer deref after DMA setup failure\n\nThe driver falls back to PIO mode if DMA setup fails during probe.\n\nMake sure to the clear the DMA channel pointers on setup failure to\navoid dereferencing an error pointer (or attempting to release a channel\na second time) on later probe errors or driver unbind.\n\nThis issue was flagged by Sashiko when reviewing a devres allocation\nconversion patch.(CVE-2026-64170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: stub: Reject I2C block transfers with invalid length\n\nThe I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]\nas the transfer length. The existing check only clamps it to avoid\noverrunning the chip->words[256] register array, but does not validate\nit against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union\ni2c_smbus_data.block buffer (34 bytes total). The driver is a\ndevelopment/test tool (CONFIG_I2C_STUB=m, not built by default)\nthat must be loaded with a chip_addr= parameter.\n\nA local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl\nwith I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing\nstub_xfer() to read or write past the end of the union\ni2c_smbus_data.block buffer:\n\n BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)\n Read of size 1 at addr ffff88800abcfd92 by task exploit/81\n Call Trace:\n  <TASK>\n  stub_xfer (drivers/i2c/i2c-stub.c:223)\n  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)\n  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)\n  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)\n  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)\n  __x64_sys_ioctl (fs/ioctl.c:583)\n  do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  </TASK>\n\nThe bug exists because i2c-stub implements .smbus_xfer directly,\nbypassing the I2C_SMBUS_BLOCK_MAX validation in\ni2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same\nfunction correctly validates against I2C_SMBUS_BLOCK_MAX, but the\nI2C_SMBUS_I2C_BLOCK_DATA case does not.\n\nFix by rejecting transfers with data->block[0] == 0 or\ndata->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with\nboth the I2C_SMBUS_BLOCK_DATA case in the same function and the\nI2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().(CVE-2026-64191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized\n\nWhen CONFIG_BPF_LSM=y is set, BPF inode storage maps\n(BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,\nif the BPF LSM is not explicitly enabled at boot time (e.g. omitted\nfrom the "lsm=" boot parameter), lsm_prepare() is never executed for\nthe BPF LSM.\n\nConsequently, the BPF inode security blob offset\n(bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at\nits default compiled size of 8 bytes instead of being updated to a\nvalid offset past the reserved struct rcu_head (typically 16 bytes\nor more).\n\nWhen a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE\nmap, bpf_inode() evaluates inode->i_security + 8. This erroneously\naliases the struct rcu_head.func callback pointer at the beginning\nof the inode->i_security blob. During subsequent map element cleanup\nor inode destruction, writing NULL to owner_storage clears the queued\nRCU callback pointer. When rcu_do_batch() later executes the queued\ncallback, it attempts an instruction fetch at address 0x0, triggering\nan immediate kernel panic.\n\nFix this by introducing a global bpf_lsm_initialized boolean flag\nmarked with __ro_after_init. Set this flag to true inside bpf_lsm_init()\nwhen the LSM framework successfully registers the BPF LSM. Gate map\nallocation in inode_storage_map_alloc() on this flag, returning\n-EOPNOTSUPP if the BPF LSM is in turn uninitialized.\n\nThis fail-fast approach prevents userspace from allocating inode\nstorage maps when the supporting BPF LSM infrastructure is absent,\navoiding zombie map states.(CVE-2026-64192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent out-of-bounds read in glob matching\n\nString event fields are not necessarily NUL-terminated, so the filter\npredicate functions (filter_pred_string(), filter_pred_strloc() and\nfilter_pred_strrelloc()) pass the field length to the regex match\ncallbacks, and the length-aware matchers honour it.\n\nregex_match_glob() was the exception: it ignored the length and called\nglob_match(), which scans the string until it hits a NUL byte. Some\nstring fields are not NUL-terminated. One example is the dynamic char\narray of the xfs_* namespace tracepoints, which is copied without a\ntrailing NUL. For such a field, glob matching reads past the end of\nthe event field, causing a KASAN slab-out-of-bounds read in\nglob_match(), reached via regex_match_glob() and filter_match_preds()\nfrom the xfs_lookup tracepoint.\n\nAdd a length-bounded glob_match_len() and use it from regex_match_glob()\nso glob matching always stops at the field boundary. The matching loop\nis factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: iowarrior: fix use-after-free on disconnect race\n\nmutex_unlock() may access the mutex structure after releasing the lock\nand therefore cannot be used to manage lifetime of objects directly\n(unlike spinlocks and refcounts). [1][2]\n\nUse a kref to release the driver data to avoid use-after-free in\nmutex_unlock() when release() races with disconnect().\n\n[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic")\n[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most\n                   other sleeping locks, can still use the lock object\n                   after it's unlocked")(CVE-2026-64341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: lg-g15: cancel pending work on remove to fix a use-after-free\n\nlg_g15_data is allocated with devm and holds a work item. The report\nhandlers schedule that work straight from device input.\nlg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,\nand lg_g510_leds_event() does it too. The worker dereferences the\nlg_g15_data back through container_of.\n\nThe driver had no remove callback and never cancelled the work. So if a\nreport scheduled the work and the keyboard was then unplugged, devres\nfreed lg_g15_data while the work was still pending or running, and the\nworker touched freed memory. This is a use-after-free. It is reachable\nas a race on device unplug.\n\nAdd a remove callback that cancels the work before devres frees the\nstate. g15->work is only initialized for the models that schedule it\n(G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the\ncancel on g15->work.func to avoid cancelling a work that was never set\nup. The g15 NULL test mirrors the one already in lg_g15_raw_event().(CVE-2026-64362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.(CVE-2026-64374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: fix race between cgroup_writeback_umount() and inode_switch_wbs()\n\nWhen a container exits, the following BUG_ON() is occasionally triggered:\n\n==================================================================\n VFS: Busy inodes after unmount of sdb (ext4)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:695!\n CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1\n pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : generic_shutdown_super+0xf0/0x100\n lr : generic_shutdown_super+0xf0/0x100\n Call trace:\n  generic_shutdown_super+0xf0/0x100\n  kill_block_super+0x20/0x48\n  ext4_kill_sb+0x28/0x60\n  deactivate_locked_super+0x54/0x130\n  deactivate_super+0x84/0xa0\n  cleanup_mnt+0xa4/0x140\n  __cleanup_mnt+0x18/0x28\n  task_work_run+0x78/0xe0\n  do_notify_resume+0x204/0x240\n==================================================================\n\nThe root cause is a race between cgroup_writeback_umount() and\ninode_switch_wbs()/cleanup_offline_cgwb(). There is a window between\ninode_prepare_wbs_switch() returning true and the subsequent\nwb_queue_isw() call. Following is the process that triggers the issue:\n\n      CPU A (umount)           |          CPU B (writeback)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n                                 inode_switch_wbs/cleanup_offline_cgwb\n                                  atomic_inc(&isw_nr_in_flight)\n                                  inode_prepare_wbs_switch\n                                   -> passes SB_ACTIVE check\n                                   __iget(inode)\n generic_shutdown_super\n  sb->s_flags &= ~SB_ACTIVE\n  cgroup_writeback_umount(sb)\n   smp_mb()\n   atomic_read(&isw_nr_in_flight)\n   rcu_barrier()\n    -> no pending RCU callbacks\n   flush_workqueue(isw_wq)\n    -> nothing queued, returns\n  evict_inodes(sb)\n   -> Inode skipped as isw still holds a ref.\n  sop->put_super(sb)\n   /* destroys percpu counters */\n  -> VFS: Busy inodes after unmount!\n                                  wb_queue_isw()\n                                   queue_work(isw_wq, ...)\n                                  /* later in work function */\n                                  inode_switch_wbs_work_fn\n                                   process_inode_switch_wbs\n                                    iput() -> evict\n                                     percpu_counter_dec() // UAF!\n\nFix this by extending the RCU read-side critical section in\ninode_switch_wbs() and cleanup_offline_cgwb() to cover from\ninode_prepare_wbs_switch() through wb_queue_isw().  Since there is\nno sleep in this window, rcu_read_lock() can be used.  Then add a\nsynchronize_rcu() in cgroup_writeback_umount() before the existing\nrcu_barrier(), so that all in-flight switchers that have passed the\nSB_ACTIVE check have completed queue_work() before flush_workqueue()\nis called.\n\nThe existing rcu_barrier() is intentionally retained so this fix can\nbe backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that\nstill queue switches via queue_rcu_work(). It is a no-op on current\nmainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on\nwb->list_lock when switching inodes")) and is removed in a follow-up\npatch.(CVE-2026-64378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: serialize QUERY_DIRECTORY requests per file\n\nsmb2_query_dir() stores a pointer to its stack-allocated private data in\nthe ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the\nsame file handle can overwrite this pointer while an iterate_dir() callback\nis still using it, resulting in a stack use-after-free.\n\nAdd a per-file mutex and hold it while accessing the shared directory\nenumeration state. The lock covers scan restart, dot entry state,\nreaddir_data setup and iteration, and response construction. This prevents\nanother request from replacing readdir_data.private before the current\nrequest has finished using it and also serializes the shared file position.(CVE-2026-64397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio: clamp device-reported used.len at copy_data()\n\nrandom_recv_done() stores the device-reported used.len directly into\nvi->data_avail.  copy_data() then indexes vi->data[] using\nvi->data_idx (advanced by previous copy_data() calls) and issues a\nmemcpy() without re-validating either value against the posted\nbuffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32\nor 64).\n\nA malicious or buggy virtio-rng backend can set used.len beyond\nsizeof(vi->data), steering the memcpy() past the end of the inline\narray into adjacent kmalloc-1k slab bytes.  hwrng_fillfn() mixes\nthose bytes into the guest RNG, and guest root can also observe\nthem directly via /dev/hwrng.\n\nConcrete impact is inside the guest:\n\n - Memory-safety / hardening: any virtio-rng backend that\n   over-reports used.len causes the driver to read past vi->data\n   into unrelated slab contents.  hwrng_fillfn() is a kernel thread\n   that runs as soon as the device is probed; no guest userspace\n   interaction is required to first-trigger the OOB.\n\n - Cross-boundary leak (confidential-compute threat model): a\n   malicious hypervisor cooperating with a malicious or compromised\n   guest root userspace can use /dev/hwrng as a leak channel for\n   guest-kernel heap data.  The host sets a large used.len, guest\n   root reads /dev/hwrng, and the returned bytes contain guest\n   kernel slab contents that were adjacent to vi->data.  In\n   practice, confidential-compute guests (SEV-SNP, TDX) usually\n   disable virtio-rng entirely, so this path is narrow, but the\n   fix is still worth carrying because the underlying\n   memory-safety bug contaminates the guest RNG on any host.\n\nKASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend\nhas been patched to report used.len = 0x10000:\n\n  BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0\n  Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52\n  Call Trace:\n   __asan_memcpy+0x23/0x60\n   virtio_read+0x394/0x5d0\n   hwrng_fillfn+0xb2/0x470\n   kthread+0x2cc/0x3a0\n  Allocated by task 1:\n   probe_common+0xa5/0x660\n   virtio_dev_probe+0x549/0xbc0\n  The buggy address belongs to the object at ffff88800ae0b800\n   which belongs to the cache kmalloc-1k of size 1024\n  The buggy address is located 0 bytes to the right of\n   allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)\n\nSame class of bug as commit c04db81cd028 ("net/9p: Fix buffer\noverflow in USB transport layer"), which hardened\nusb9pfs_rx_complete() against unchecked device-reported length in\nthe USB 9p transport.\n\nWith the clamp at point of use and array_index_nospec() in place,\nthe same harness boots cleanly: copy_data() returns zero for the\nbogus report, the device-supplied bytes after data_idx are\ndiscarded, and the driver issues a fresh request.(CVE-2026-64456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: event: Fix event FIFO reset race\n\n`iio_event_getfd()` creates the event file descriptor with\n`anon_inode_getfd()`, which allocates a new fd, creates the anonymous\nfile and installs it in the process fd table before returning to the\ncaller.\n\nThe IIO code resets the event FIFO after `anon_inode_getfd()` has returned,\nbut before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.\nBut since fd tables are shared between threads, another thread can guess\nthe newly allocated fd number and issue a `read()` on it as soon as the fd\nhas been installed.\n\nThis means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in\nparallel with the `kfifo_reset_out()` in `iio_event_getfd()`.\n\nThe kfifo documentation says that `kfifo_reset_out()` is only safe when it\nis called from the reader thread and there is only one concurrent reader.\nOtherwise it is dangerous and must be handled in the same way as\n`kfifo_reset()`.\n\nIf that happens, `kfifo_to_user()` can advance the FIFO `out` index based\non state from before the reset, after the reset has already moved the `out`\nindex to the current `in` index. That can leave the FIFO with an `out`\nindex past the `in` index. A later `read()` can then see an underflowed\nFIFO length and copy more data than the event FIFO buffer contains. This\ncan result in an out-of-bounds read and leak adjacent kernel memory to\nuserspace.\n\nMove the FIFO reset before `anon_inode_getfd()`. At that point the event fd is\nmarked busy, but the new fd has not been installed yet, so userspace cannot\naccess it while the FIFO is reset.(CVE-2026-64496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nposix-cpu-timers: Prevent UAF caused by non-leader exec() race\n\nWongi and Jungwoo decoded and reported a non-leader exec() related race\nwhich can result in an UAF:\n\n sys_timer_delete()\t\t\texec()\n   posix_cpu_timer_del()\n   // Observes old leader\n   p = pid_task(pid, pid_type);\t\tde_thread()\n   \t\t\t\t\t  switch_leader();\n\t\t\t\t\t  release_task(old_leader)\n\t\t\t\t\t    __exit_signal(old_leader)\n\t\t\t\t\t      sighand = lock(old_leader, sighand);\n\t\t\t\t\t      posix_cpu_timers*_exit();\n   sighand = lock_task_sighand(p)\t      unhash_task(old_leader);\n     sh = lock(p, sighand)\t    \t      old_leader->sighand = NULL;\n\t\t\t\t\t      unlock(sighand);\n     (p->sighand == NULL)\n\tunlock(sh)\n\treturn NULL;\n\n   // Returns without action\n   if(!sighand)\n      return 0;\n   free_posix_timer();\n\nThis is "harmless" unless the deleted timer was armed and enqueued in\np->signal because on exec() a TGID targeted timer is inherited.\n\nAs sys_timer_delete() freed the underlying posix timer object\nrun_posix_cpu_timers() or any timerqueue related add/delete operations on\nother timers will access the freed object's timerqueue node, which results\nin an UAF.\n\nThere is a similar problem vs. posix_cpu_timer_set(). For regular posix\ntimers it just transiently returns -ESRCH to user space, but for the use\ncase in do_cpu_nanosleep() it's the same UAF just that the k_itimer is\nallocated on the stack.\n\nAlso posix_cpu_timer_rearm() fails to rearm the timer, which means it stops\nto expire.\n\nWhile debating solutions Frederic pointed out another problem:\n\n   posix_cpu_timer_del(tmr)\n\t\t\t\t\t__exit_signal(p)\n\t\t\t\t\t  posix_cpu_timers*_exit(p);\n\t\t\t\t\t  unhash_task(p);\n\t\t\t\t\t  p->sighand = NULL;\n     sh = lock_task_sighand(p)\n        sighand = p->sighand;\n\tif (!sighand)\n\t    return NULL;\n\tlock(sighand);\n\n     if (!sh)\n\tWARN_ON_ONCE(timer_queued(tmr));\n\nOn weakly ordered architectures it is not guaranteed that\nposix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit()\nwhen p->sighand is observed as NULL, which means the WARN() can be a false\npositive.\n\nSolve these issues by:\n\n  1) Changing the store in __exit_signal() to smp_store_release().\n\n  2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path\n     of lock_task_sighand().\n\n  3) Creating a helper function for looking up the task and locking sighand\n     which does not return when sighand == NULL. Instead it retries the\n     task lookup and only if that fails it gives up.\n\n  4) Using that helper in the three affected functions.\n\n#1/#2 ensures that the reader side which observes sighand == NULL also\nobserves all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()\nand the ones in unhash_task().\n\n#3 ensures that the above described non-leader exec() situation is handled\ngracefully. When the task lookup returns the old leader, but sighand ==\nNULL then it retries. In the non-leader exec() case the subsequent task\nlookup will observe the new leader due to #1/#2. In normal exit() scenarios\nthe subsequent lookup fails.\n\nWhen the task lookup fails, the function also checks whether the timer is\nstill enqueued and issues a warning if that's the case. Unfortunately there\nis nothing which can be done about it, but as the task is already not\nlonger visible the timer should not be accessed anymore. This check also\nrequires memory ordering, which is not provided when the first lookup\nfails. To achieve that the check is preceeded by a smp_rmb() which pairs\nwith the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that\nthe stores in posix_cpu_timers*_exit() are visible.\n\nThe history of the non-leader exec() issue goes back to the early days of\nposix CPU timers, which stored a pointer to the group leader task in the\ntimer. That obviously fails when a non-leader exec() switches the leader.\ncommit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems\nwith mt exec") added a temporary workaround for that in 2010 which surv\n---truncated---(CVE-2026-64560)","modified":"2026-08-07T03:01:01.134415926Z","published":"2026-08-07T02:45:24Z","upstream":["CVE-2026-31747","CVE-2026-43459","CVE-2026-43497","CVE-2026-53133","CVE-2026-53262","CVE-2026-53388","CVE-2026-53400","CVE-2026-63825","CVE-2026-63827","CVE-2026-63887","CVE-2026-63888","CVE-2026-63956","CVE-2026-63975","CVE-2026-64118","CVE-2026-64170","CVE-2026-64191","CVE-2026-64192","CVE-2026-64299","CVE-2026-64341","CVE-2026-64362","CVE-2026-64374","CVE-2026-64378","CVE-2026-64397","CVE-2026-64456","CVE-2026-64496","CVE-2026-64560"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3303"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31747"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43459"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43497"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53133"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53262"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63825"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63827"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64191"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64192"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64341"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64362"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64378"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64456"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64496"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64560"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-327.0.0.228.oe2203sp4"}]}],"ecosystem_specific":{"x86_64":["bpftool-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","perf-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm"],"aarch64":["bpftool-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","perf-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-327.0.0.228.oe2203sp4.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3303.json"}}],"schema_version":"1.8.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}