{"id":"OESA-2026-3155","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\niio: accel: bmc150: Fix irq assumption regression\n\nThe code in bmc150-accel-core.c unconditionally calls\nbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,\nsuch as on the runtime PM resume path giving a kernel\nsplat like this if the device has no interrupts:\n\nUnable to handle kernel NULL pointer dereference at virtual\n  address 00000001 when read\n\nPC is at bmc150_accel_set_interrupt+0x98/0x194\nLR is at __pm_runtime_resume+0x5c/0x64\n(...)\nCall trace:\nbmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108\nbmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc\n__iio_update_buffers from enable_store+0x84/0xc8\nenable_store from kernfs_fop_write_iter+0x154/0x1b4\n\nThis bug seems to have been in the driver since the beginning,\nbut it only manifests recently, I do not know why.\n\nStore the IRQ number in the state struct, as this is a common\npattern in other drivers, then use this to determine if we have\nIRQ support or not.(CVE-2025-68330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver\n\nat91_adc_interrupt can call at91_adc_touch_data_handler function\nto start the work by schedule_work(&st->touch_st.workq).\n\nIf we remove the module which will call at91_adc_remove to\nmake cleanup, it will free indio_dev through iio_device_unregister but\nquite a bit later. While the work mentioned above will be used. The\nsequence of operations that may lead to a UAF bug is as follows:\n\nCPU0                                      CPU1\n\n                                     | at91_adc_workq_handler\nat91_adc_remove                      |\niio_device_unregister(indio_dev)     |\n//free indio_dev a bit later         |\n                                     | iio_push_to_buffers(indio_dev)\n                                     | //use indio_dev\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in at91_adc_remove.(CVE-2025-71199)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: Fix potential block overflow that cause system hang\n\nWhen a user executes the FITRIM command, an underflow can occur when\ncalculating nblocks if end_block is too small. Since nblocks is of\ntype sector_t, which is u64, a negative nblocks value will become a\nvery large positive integer. This ultimately leads to the block layer\nfunction __blkdev_issue_discard() taking an excessively long time to\nprocess the bio chain, and the ns_segctor_sem lock remains held for a\nlong period. This prevents other tasks from acquiring the ns_segctor_sem\nlock, resulting in the hang reported by syzbot in [1].\n\nIf the ending block is too small, typically if it is smaller than 4KiB\nrange, depending on the usage of the segment 0, it may be possible to\nattempt a discard request beyond the device size causing the hang.\n\nExiting successfully and assign the discarded size (0 in this case)\nto range->len.\n\nAlthough the start and len values in the user input range are too small,\na conservative strategy is adopted here to safely ignore them, which is\nequivalent to a no-op; it will not perform any trimming and will not\nthrow an error.\n\n[1]\ntask:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000\nCall Trace:\n rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272\n nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]\n nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684\n\n[ryusuke: corrected part of the commit message about the consequences](CVE-2025-71237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: omap-dma: fix dma_pool resource leak in error paths\n\nThe dma_pool created by dma_pool_create() is not destroyed when\ndma_async_device_register() or of_dma_controller_register() fails,\ncausing a resource leak in the probe error paths.\n\nAdd dma_pool_destroy() in both error paths to properly release the\nallocated dma_pool resource.(CVE-2026-23033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: avoid possible NULL deref\n\ntcf_ife_encode() must make sure ife_encode() does not return NULL.\n\nsyzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166\nCPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)\nCall Trace:\n <TASK>\n  ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101\n  tcf_ife_encode net/sched/act_ife.c:841 [inline]\n  tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877\n  tc_act include/net/tc_wrapper.h:130 [inline]\n  tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152\n  tcf_exts_exec include/net/pkt_cls.h:349 [inline]\n  mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42\n  tc_classify include/net/tc_wrapper.h:197 [inline]\n  __tcf_classify net/sched/cls_api.c:1764 [inline]\n  tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860\n  multiq_classify net/sched/sch_multiq.c:39 [inline]\n  multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66\n  dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147\n  __dev_xmit_skb net/core/dev.c:4262 [inline]\n  __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798(CVE-2026-23064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: Fix memory corruption due to not set vif driver data size\n\nThe struct ieee80211_vif contains trailing space for vif driver data,\nwhen struct ieee80211_vif is allocated, the total memory size that is\nallocated is sizeof(struct ieee80211_vif) + size of vif driver data.\nThe size of vif driver data is set by each WiFi driver as needed.\n\nThe RSI911x driver does not set vif driver data size, no trailing space\nfor vif driver data is therefore allocated past struct ieee80211_vif .\nThe RSI911x driver does however use the vif driver data to store its\nvif driver data structure "struct vif_priv". An access to vif->drv_priv\nleads to access out of struct ieee80211_vif bounds and corruption of\nsome memory.\n\nIn case of the failure observed locally, rsi_mac80211_add_interface()\nwould write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv;\nvif_info->vap_id = vap_idx. This write corrupts struct fq_tin member\nstruct list_head new_flows . The flow = list_first_entry(head, struct\nfq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus\naddress, which when accessed causes a crash.\n\nThe trigger is very simple, boot the machine with init=/bin/sh , mount\ndevtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1",\n"ip link set wlan0 down" and the crash occurs.\n\nFix this by setting the correct size of vif driver data, which is the\nsize of "struct vif_priv", so that memory is allocated and the driver\ncan store its driver data in it, instead of corrupting memory around\nit.(CVE-2026-23073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: fix double-free in nr_route_frame()\n\nIn nr_route_frame(), old_skb is immediately freed without checking if\nnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,\nthe caller function will free old_skb again, causing a double-free bug.\n\nTherefore, to prevent this, we need to modify it to check whether\nnr_neigh->ax25 is NULL before freeing old_skb.(CVE-2026-23098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: toshiba_haps: Fix memory leaks in add/remove routines\n\ntoshiba_haps_add() leaks the haps object allocated by it if it returns\nan error after allocating that object successfully.\n\ntoshiba_haps_remove() does not free the object pointed to by\ntoshiba_haps before clearing that pointer, so it becomes unreachable\nallocated memory.\n\nAddress these memory leaks by using devm_kzalloc() for allocating\nthe memory in question.(CVE-2026-23176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()\n\nA malicious or compromised VIO server can return a num_written value in the\ndiscover targets MAD response that exceeds max_targets. This value is\nstored directly in vhost->num_targets without validation, and is then used\nas the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which\nis only allocated for max_targets entries. Indices at or beyond max_targets\naccess kernel memory outside the DMA-coherent allocation.  The\nout-of-bounds data is subsequently embedded in Implicit Logout and PLOGI\nMADs that are sent back to the VIO server, leaking kernel memory.\n\nFix by clamping num_written to max_targets before storing it.(CVE-2026-31464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY\n\nfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,\nas documented in mm/filemap.c:\n\n  "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock\n  may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."\n\nWhen this happens, a concurrent munmap() can call remove_vma() and free\nthe vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then\nbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() call\ndereferences it -- a use-after-free.\n\nFix this by saving ip_blkno as a plain integer before calling\nfilemap_fault(), and removing vma from the trace event. Since\nip_blkno is copied by value before the lock can be dropped, it\nremains valid regardless of what happens to the vma or inode\nafterward.(CVE-2026-31597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):\nocfs2_unlink\n  ocfs2_prepare_orphan_dir\n    ocfs2_lookup_lock_orphan_dir\n      inode_lock(orphan_dir_inode) <- lock A\n    __ocfs2_prepare_orphan_dir\n      ocfs2_prepare_dir_for_insert\n        ocfs2_extend_dir\n\t  ocfs2_expand_inline_dir\n\t    down_write(&oi->ip_alloc_sem) <- Lock B\n\nLock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):\nocfs2_dio_end_io_write\n  down_write(&oi->ip_alloc_sem) <- Lock B\n  ocfs2_del_inode_from_orphan()\n    inode_lock(orphan_dir_inode) <- Lock A\n\nDeadlock Scenario:\n  CPU0 (unlink)                     CPU1 (dio_end_io_write)\n  ------                            ------\n  inode_lock(orphan_dir_inode)\n                                    down_write(ip_alloc_sem)\n  down_write(ip_alloc_sem)\n                                    inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan.  So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.(CVE-2026-31598)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb->number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb->iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input"). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo's series ("usb: usbip: fix integer overflow in\nusbip_recv_iso()", v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu->number_of_packets against\nurb->number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO\n\nMuch like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide\nby zero error"), we also need to prevent that same crash from happening\nin the udlfb driver as it uses pixclock directly when dividing, which\nwill crash.(CVE-2026-31618)\n\nIn the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler. The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays") fixed similar missing checks against the same field on the NCI path.(CVE-2026-31622)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: vt8500lcdfb: fix missing dma_free_coherent()\n\nfbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not\nfreed if the error path is reached.(CVE-2026-43202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: No shortcut out of RDS_CONN_ERROR\n\nRDS connections carry a state "rds_conn_path::cp_state"\nand transitions from one state to another and are conditional\nupon an expected state: "rds_conn_path_transition."\n\nThere is one exception to this conditionality, which is\n"RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"\nregardless of what state the condition is currently in.\n\nBut as soon as a connection enters state "RDS_CONN_ERROR",\nthe connection handling code expects it to go through the\nshutdown-path.\n\nThe RDS/TCP multipath changes added a shortcut out of\n"RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"\nvia "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").\n\nA subsequent "rds_tcp_reset_callbacks" can then transition\nthe state to "RDS_CONN_RESETTING" with a shutdown-worker queued.\n\nThat'll trip up "rds_conn_init_shutdown", which was\nnever adjusted to handle "RDS_CONN_RESETTING" and subsequently\ndrops the connection with the dreaded "DR_INV_CONN_STATE",\nwhich leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.\n\nSo we do two things here:\n\na) Don't shortcut "RDS_CONN_ERROR", but take the longer\n   path through the shutdown code.\n\nb) Add "RDS_CONN_RESETTING" to the expected states in\n  "rds_conn_init_shutdown" so that we won't error out\n  and get stuck, if we ever hit weird state transitions\n  like this again."(CVE-2026-43226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()\n\nibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read\nwhen the queue reader or writer index from hardware exceeds\nREMOTE_QUEUE_SIZE (60).\n\nA compromised service processor can trigger this by writing an\nout-of-range value to the reader or writer MMIO register before\nasserting an interrupt. Since writer is re-read from hardware on\nevery loop iteration, it can also be set to an out-of-range value\nafter the loop has already started.\n\nThe root cause is that get_queue_reader() and get_queue_writer() return\nraw readl() values that are passed directly into get_queue_entry(),\nwhich computes:\n\n  queue_begin + reader * sizeof(struct remote_input)\n\nwith no bounds check. This unchecked MMIO address is then passed to\nmemcpy_fromio(), reading 8 bytes from unintended device registers.\nFor sufficiently large values the address falls outside the PCI BAR\nmapping entirely, triggering a machine check exception.\n\nFix by checking both indices against REMOTE_QUEUE_SIZE at the top of\nthe loop body, before any call to get_queue_entry(). On an out-of-range\nvalue, reset the reader register to 0 via set_queue_reader() before\nbreaking, so that normal queue operation can resume if the corrupted\nhardware state is transient.(CVE-2026-46022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: caif: clear client service pointer on teardown\n\n`caif_connect()` can tear down an existing client after remote shutdown by\ncalling `caif_disconnect_client()` followed by `caif_free_client()`.\n`caif_free_client()` releases the service layer referenced by\n`adap_layer->dn`, but leaves that pointer stale.\n\nWhen the socket is later destroyed, `caif_sock_destructor()` calls\n`caif_free_client()` again and dereferences the freed service pointer.\n\nClear the client/service links before releasing the service object so\nrepeated teardown becomes harmless.(CVE-2026-46098)","modified":"2026-07-24T03:45:17.153557145Z","published":"2026-07-24T03:28:14Z","upstream":["CVE-2025-68330","CVE-2025-71199","CVE-2025-71237","CVE-2026-23033","CVE-2026-23064","CVE-2026-23073","CVE-2026-23098","CVE-2026-23176","CVE-2026-31464","CVE-2026-31597","CVE-2026-31598","CVE-2026-31607","CVE-2026-31618","CVE-2026-31622","CVE-2026-43202","CVE-2026-43226","CVE-2026-46022","CVE-2026-46098"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68330"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71199"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23176"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31464"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31598"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31607"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31618"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31622"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43202"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43226"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46022"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46098"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2607.3.0.0381.oe2003sp4"}]}],"ecosystem_specific":{"src":["kernel-4.19.90-2607.3.0.0381.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm"],"aarch64":["bpftool-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3155.json"}}],"schema_version":"1.7.5"}