{"schema_version":"1.7.2","id":"OESA-2025-1465","modified":"2025-05-09T12:41:59Z","published":"2025-05-09T12:41:59Z","upstream":["CVE-2020-36789","CVE-2021-47641","CVE-2021-47668","CVE-2021-47670","CVE-2022-49084","CVE-2022-49086","CVE-2022-49217","CVE-2022-49232","CVE-2022-49298","CVE-2022-49385","CVE-2022-49429","CVE-2022-49626","CVE-2022-49647","CVE-2023-52935","CVE-2023-53019","CVE-2023-53023","CVE-2023-53032","CVE-2024-58094","CVE-2025-21759","CVE-2025-21760","CVE-2025-21761","CVE-2025-21762","CVE-2025-21763","CVE-2025-21764","CVE-2025-21993","CVE-2025-22004","CVE-2025-22035","CVE-2025-22055","CVE-2025-22058","CVE-2025-22125","CVE-2025-37785"],"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\ncan: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context\n\nIf a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but\nnot always, the case), the \u0026apos;WARN_ON(in_irq)\u0026apos; in\nnet/core/skbuff.c#skb_release_head_state() might be triggered, under network\ncongestion circumstances, together with the potential risk of a NULL pointer\ndereference.\n\nThe root cause of this issue is the call to kfree_skb() instead of\ndev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().\n\nThis patch prevents the skb to be freed within the call to netif_rx() by\nincrementing its reference count with skb_get(). The skb is finally freed by\none of the in-irq-context safe functions: dev_consume_skb_any() or\ndev_kfree_skb_any(). The \u0026quot;any\u0026quot; version is used because some drivers might call\ncan_get_echo_skb() in a normal context.\n\nThe reason for this issue to occur is that initially, in the core network\nstack, loopback skb were not supposed to be received in hardware IRQ context.\nThe CAN stack is an exeption.\n\nThis bug was previously reported back in 2017 in [1] but the proposed patch\nnever got accepted.\n\nWhile [1] directly modifies net/core/dev.c, we try to propose here a\nsmoother modification local to CAN network stack (the assumption\nbehind is that only CAN devices are affected by this issue).\n\n[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com(CVE-2020-36789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvideo: fbdev: cirrusfb: check pixclock to avoid divide by zero\n\nDo a sanity check on pixclock value to avoid divide by zero.\n\nIf the pixclock value is zero, the cirrusfb driver will round up\npixclock to get the derived frequency as close to maxclock as\npossible.\n\nSyzkaller reported a divide error in cirrusfb_check_pixclock.\n\ndivide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2\nRIP: 0010:cirrusfb_check_var+0x6f1/0x1260\n\nCall Trace:\n fb_set_var+0x398/0xf90\n do_fb_ioctl+0x4b8/0x6f0\n fb_ioctl+0xeb/0x130\n __x64_sys_ioctl+0x19d/0x220\n do_syscall_64+0x3a/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_restart: fix use after free bug\n\nAfter calling netif_rx_ni(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is accessed\nafter the netif_rx_ni() in:\n      stats-\u0026gt;rx_bytes += cf-\u0026gt;len;\n\nReordering the lines solves the issue.(CVE-2021-47668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: peak_usb: fix use after free bugs\n\nAfter calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is accessed\nafter the peak_usb_netif_rx_ni().\n\nReordering the lines solves the issue.(CVE-2021-47670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: confirm skb is allocated before using\n\nqede_build_skb() assumes build_skb() always works and goes straight\nto skb_reserve(). However, build_skb() can fail under memory pressure.\nThis results in a kernel panic because the skb to reserve is NULL.\n\nAdd a check in case build_skb() failed to allocate and return NULL.\n\nThe NULL return is handled correctly in callers to qede_build_skb().(CVE-2022-49084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix leak of nested actions\n\nWhile parsing user-provided actions, openvswitch module may dynamically\nallocate memory and store pointers in the internal copy of the actions.\nSo this memory has to be freed while destroying the actions.\n\nCurrently there are only two such actions: ct() and set().  However,\nthere are many actions that can hold nested lists of actions and\novs_nla_free_flow_actions() just jumps over them leaking the memory.\n\nFor example, removal of the flow with the following actions will lead\nto a leak of the memory allocated by nf_ct_tmpl_alloc():\n\n  actions:clone(ct(commit),0)\n\nNon-freed set() action may also leak the \u0026apos;dst\u0026apos; structure for the\ntunnel info including device references.\n\nUnder certain conditions with a high rate of flow rotation that may\ncause significant memory leak problem (2MB per second in reporter\u0026apos;s\ncase).  The problem is also hard to mitigate, because the user doesn\u0026apos;t\nhave direct control over the datapath flows generated by OVS.\n\nFix that by iterating over all the nested actions and freeing\neverything that needs to be freed recursively.\n\nNew build time assertion should protect us from this problem if new\nactions will be added in the future.\n\nUnfortunately, openvswitch module doesn\u0026apos;t use NLA_F_NESTED, so all\nattributes has to be explicitly checked.  sample() and clone() actions\nare mixing extra attributes into the user-provided action list.  That\nprevents some code generalization too.(CVE-2022-49086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: pm8001: Fix abort all task initialization\n\nIn pm80xx_send_abort_all(), the n_elem field of the ccb used is not\ninitialized to 0. This missing initialization sometimes lead to the task\ncompletion path seeing the ccb with a non-zero n_elem resulting in the\nexecution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),\ncausing a crash such as:\n\n[  197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280\n[  197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012\n[  197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0\n[  197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0\n[  197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b\n[  197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000\n[  197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000\n[  197.741493] FS:  0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000\n[  197.749659] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0\n[  197.762656] Call Trace:\n[  197.765127]  \u0026lt;IRQ\u0026gt;\n[  197.767162]  pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]\n[  197.772364]  ? do_raw_spin_unlock+0x54/0x220\n[  197.776680]  pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]\n[  197.782406]  process_oq+0xe85/0x7890 [pm80xx]\n[  197.786817]  ? lock_acquire+0x194/0x490\n[  197.790697]  ? handle_irq_event+0x10e/0x1b0\n[  197.794920]  ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]\n[  197.800378]  ? __wake_up_bit+0x100/0x100\n[  197.804340]  ? lock_is_held_type+0x98/0x110\n[  197.808565]  pm80xx_chip_isr+0x94/0x130 [pm80xx]\n[  197.813243]  tasklet_action_common.constprop.0+0x24b/0x2f0\n[  197.818785]  __do_softirq+0x1b5/0x82d\n[  197.822485]  ? do_raw_spin_unlock+0x54/0x220\n[  197.826799]  __irq_exit_rcu+0x17e/0x1e0\n[  197.830678]  irq_exit_rcu+0xa/0x20\n[  197.834114]  common_interrupt+0x78/0x90\n[  197.840051]  \u0026lt;/IRQ\u0026gt;\n[  197.844236]  \u0026lt;TASK\u0026gt;\n[  197.848397]  asm_common_interrupt+0x1e/0x40\n\nAvoid this issue by always initializing the ccb n_elem field to 0 in\npm8001_send_abort_all(), pm8001_send_read_log() and\npm80xx_send_abort_all().(CVE-2022-49217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()\n\nIn amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()\nis assigned to mode and is passed to drm_mode_probed_add() directly after\nthat. drm_mode_probed_add() passes \u0026amp;mode-\u0026gt;head to list_add_tail(), and\nthere is a dereference of it in list_add_tail() without recoveries, which\ncould lead to NULL pointer dereference on failure of\namdgpu_dm_create_common_mode().\n\nFix this by adding a NULL check of mode.\n\nThis bug was found by a static analyzer.\n\nBuilds with \u0026apos;make allyesconfig\u0026apos; show no new warnings,\nand our static analyzer no longer warns about this code.(CVE-2022-49232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8712: fix uninit-value in r871xu_drv_init()\n\nWhen \u0026apos;tmpU1b\u0026apos; returns from r8712_read8(padapter, EE_9346CR) is 0,\n\u0026apos;mac[6]\u0026apos; will not be initialized.\n\nBUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541\n r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541\n usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396\n really_probe+0x653/0x14b0 drivers/base/dd.c:596\n __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752\n driver_probe_device drivers/base/dd.c:782 [inline]\n __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899\n bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427\n __device_attach+0x593/0x8e0 drivers/base/dd.c:970\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017\n bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487\n device_add+0x1fff/0x26e0 drivers/base/core.c:3405\n usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238\n usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293\n really_probe+0x653/0x14b0 drivers/base/dd.c:596\n __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752\n driver_probe_device drivers/base/dd.c:782 [inline]\n __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899\n bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427\n __device_attach+0x593/0x8e0 drivers/base/dd.c:970\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017\n bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487\n device_add+0x1fff/0x26e0 drivers/base/core.c:3405\n usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566\n hub_port_connect drivers/usb/core/hub.c:5358 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]\n port_event drivers/usb/core/hub.c:5660 [inline]\n hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742\n process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307\n worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454\n kthread+0x3c7/0x500 kernel/kthread.c:377\n ret_from_fork+0x1f/0x30\n\nLocal variable mac created at:\n r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394\n usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396\n\nKMSAN: uninit-value in r871xu_drv_init\nhttps://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8(CVE-2022-49298)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver: base: fix UAF when driver_attach failed\n\nWhen driver_attach(drv); failed, the driver_private will be freed.\nBut it has been added to the bus, which caused a UAF.\n\nTo fix it, we need to delete it from the bus when failed.(CVE-2022-49385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Prevent panic when SDMA is disabled\n\nIf the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to\nhfi1_write_iter() will dereference a NULL pointer and panic. A typical\nstack frame is:\n\n  sdma_select_user_engine [hfi1]\n  hfi1_user_sdma_process_request [hfi1]\n  hfi1_write_iter [hfi1]\n  do_iter_readv_writev\n  do_iter_write\n  vfs_writev\n  do_writev\n  do_syscall_64\n\nThe fix is to test for SDMA in hfi1_write_iter() and fail the I/O with\nEINVAL.(CVE-2022-49429)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix use after free when disabling sriov\n\nUse after free is detected by kfence when disabling sriov. What was read\nafter being freed was vf-\u0026gt;pci_dev: it was freed from pci_disable_sriov\nand later read in efx_ef10_sriov_free_vf_vports, called from\nefx_ef10_sriov_free_vf_vswitching.\n\nSet the pointer to NULL at release time to not trying to read it later.\n\nReproducer and dmesg log (note that kfence doesn\u0026apos;t detect it every time):\n$ echo 1 \u0026gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n$ echo 0 \u0026gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n\n BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n\n Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):\n  efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n  efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xfe/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k\n\n allocated by task 6771 on cpu 10 at 3137.860196s:\n  pci_alloc_dev+0x21/0x60\n  pci_iov_add_virtfn+0x2a2/0x320\n  sriov_enable+0x212/0x3e0\n  efx_ef10_sriov_configure+0x67/0x80 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xba/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n freed by task 6771 on cpu 12 at 3170.991309s:\n  device_release+0x34/0x90\n  kobject_cleanup+0x3a/0x130\n  pci_iov_remove_virtfn+0xd9/0x120\n  sriov_disable+0x30/0xe0\n  efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xfe/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2022-49626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Use separate src/dst nodes when preloading css_sets for migration\n\nEach cset (css_set) is pinned by its tasks. When we\u0026apos;re moving tasks around\nacross csets for a migration, we need to hold the source and destination\ncsets to ensure that they don\u0026apos;t go away while we\u0026apos;re moving tasks about. This\nis done by linking cset-\u0026gt;mg_preload_node on either the\nmgctx-\u0026gt;preloaded_src_csets or mgctx-\u0026gt;preloaded_dst_csets list. Using the\nsame cset-\u0026gt;mg_preload_node for both the src and dst lists was deemed okay as\na cset can\u0026apos;t be both the source and destination at the same time.\n\nUnfortunately, this overloading becomes problematic when multiple tasks are\ninvolved in a migration and some of them are identity noop migrations while\nothers are actually moving across cgroups. For example, this can happen with\nthe following sequence on cgroup1:\n\n #1\u0026gt; mkdir -p /sys/fs/cgroup/misc/a/b\n #2\u0026gt; echo $$ \u0026gt; /sys/fs/cgroup/misc/a/cgroup.procs\n #3\u0026gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS \u0026amp;\n #4\u0026gt; PID=$!\n #5\u0026gt; echo $PID \u0026gt; /sys/fs/cgroup/misc/a/b/tasks\n #6\u0026gt; echo $PID \u0026gt; /sys/fs/cgroup/misc/a/cgroup.procs\n\nthe process including the group leader back into a. In this final migration,\nnon-leader threads would be doing identity migration while the group leader\nis doing an actual one.\n\nAfter #3, let\u0026apos;s say the whole process was in cset A, and that after #4, the\nleader moves to cset B. Then, during #6, the following happens:\n\n 1. cgroup_migrate_add_src() is called on B for the leader.\n\n 2. cgroup_migrate_add_src() is called on A for the other threads.\n\n 3. cgroup_migrate_prepare_dst() is called. It scans the src list.\n\n 4. It notices that B wants to migrate to A, so it tries to A to the dst\n    list but realizes that its -\u0026gt;mg_preload_node is already busy.\n\n 5. and then it notices A wants to migrate to A as it\u0026apos;s an identity\n    migration, it culls it by list_del_init()\u0026apos;ing its -\u0026gt;mg_preload_node and\n    putting references accordingly.\n\n 6. The rest of migration takes place with B on the src list but nothing on\n    the dst list.\n\nThis means that A isn\u0026apos;t held while migration is in progress. If all tasks\nleave A before the migration finishes and the incoming task pins it, the\ncset will be destroyed leading to use-after-free.\n\nThis is caused by overloading cset-\u0026gt;mg_preload_node for both src and dst\npreload lists. We wanted to exclude the cset from the src list but ended up\ninadvertently excluding it from the dst list too.\n\nThis patch fixes the issue by separating out cset-\u0026gt;mg_preload_node into\n-\u0026gt;mg_src_preload_node and -\u0026gt;mg_dst_preload_node, so that the src and dst\npreloadings don\u0026apos;t interfere with each other.(CVE-2022-49647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/khugepaged: fix -\u0026gt;anon_vma race\n\nIf an -\u0026gt;anon_vma is attached to the VMA, collapse_and_free_pmd() requires\nit to be locked.\n\nPage table traversal is allowed under any one of the mmap lock, the\nanon_vma lock (if the VMA is associated with an anon_vma), and the\nmapping lock (if the VMA is associated with a mapping); and so to be\nable to remove page tables, we must hold all three of them. \nretract_page_tables() bails out if an -\u0026gt;anon_vma is attached, but does\nthis check before holding the mmap lock (as the comment above the check\nexplains).\n\nIf we racily merged an existing -\u0026gt;anon_vma (shared with a child\nprocess) from a neighboring VMA, subsequent rmap traversals on pages\nbelonging to the child will be able to see the page tables that we are\nconcurrently removing while assuming that nothing else can access them.\n\nRepeat the -\u0026gt;anon_vma check once we hold the mmap lock to ensure that\nthere really is no concurrent page table access.\n\nHitting this bug causes a lockdep warning in collapse_and_free_pmd(),\nin the line \u0026quot;lockdep_assert_held_write(\u0026amp;vma-\u0026gt;anon_vma-\u0026gt;root-\u0026gt;rwsem)\u0026quot;. \nIt can also lead to use-after-free access.(CVE-2023-52935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: validate parameter addr in mdiobus_get_phy()\n\nThe caller may pass any value as addr, what may result in an out-of-bounds\naccess to array mdio_map. One existing case is stmmac_init_phy() that\nmay pass -1 as addr. Therefore validate addr before using it.(CVE-2023-53019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: Fix use-after-free in local_cleanup()\n\nFix a use-after-free that occurs in kfree_skb() called from\nlocal_cleanup(). This could happen when killing nfc daemon (e.g. neard)\nafter detaching an nfc device.\nWhen detaching an nfc device, local_cleanup() called from\nnfc_llcp_unregister_device() frees local-\u0026gt;rx_pending and decreases\nlocal-\u0026gt;ref by kref_put() in nfc_llcp_local_put().\nIn the terminating process, nfc daemon releases all sockets and it leads\nto decreasing local-\u0026gt;ref. After the last release of local-\u0026gt;ref,\nlocal_cleanup() called from local_release() frees local-\u0026gt;rx_pending\nagain, which leads to the bug.\n\nSetting local-\u0026gt;rx_pending to NULL in local_cleanup() could prevent\nuse-after-free when local_cleanup() is called twice.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: use-after-free in kfree_skb()\n\nCall Trace:\ndump_stack_lvl (lib/dump_stack.c:106)\nprint_address_description.constprop.0.cold (mm/kasan/report.c:306)\nkasan_check_range (mm/kasan/generic.c:189)\nkfree_skb (net/core/skbuff.c:955)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)\nnfc_llcp_local_put (net/nfc/llcp_core.c:181)\nllcp_sock_destruct (net/nfc/llcp_sock.c:959)\n__sk_destruct (net/core/sock.c:2133)\nsk_destruct (net/core/sock.c:2181)\n__sk_free (net/core/sock.c:2192)\nsk_free (net/core/sock.c:2203)\nllcp_sock_release (net/nfc/llcp_sock.c:646)\n__sock_release (net/socket.c:650)\nsock_close (net/socket.c:1365)\n__fput (fs/file_table.c:306)\ntask_work_run (kernel/task_work.c:179)\nptrace_notify (kernel/signal.c:2354)\nsyscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)\nsyscall_exit_to_user_mode (kernel/entry/common.c:296)\ndo_syscall_64 (arch/x86/entry/common.c:86)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)\n\nAllocated by task 4719:\nkasan_save_stack (mm/kasan/common.c:45)\n__kasan_slab_alloc (mm/kasan/common.c:325)\nslab_post_alloc_hook (mm/slab.h:766)\nkmem_cache_alloc_node (mm/slub.c:3497)\n__alloc_skb (net/core/skbuff.c:552)\npn533_recv_response (drivers/nfc/pn533/usb.c:65)\n__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)\nusb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)\ntasklet_action_common.isra.0 (kernel/softirq.c:797)\n__do_softirq (kernel/softirq.c:571)\n\nFreed by task 1901:\nkasan_save_stack (mm/kasan/common.c:45)\nkasan_set_track (mm/kasan/common.c:52)\nkasan_save_free_info (mm/kasan/genericdd.c:518)\n__kasan_slab_free (mm/kasan/common.c:236)\nkmem_cache_free (mm/slub.c:3809)\nkfree_skbmem (net/core/skbuff.c:874)\nkfree_skb (net/core/skbuff.c:931)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)\nnfc_unregister_device (net/nfc/core.c:1179)\npn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)\npn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)\nusb_unbind_interface (drivers/usb/core/driver.c:458)\ndevice_release_driver_internal (drivers/base/dd.c:1279)\nbus_remove_device (drivers/base/bus.c:529)\ndevice_del (drivers/base/core.c:3665)\nusb_disable_device (drivers/usb/core/message.c:1420)\nusb_disconnect (drivers/usb/core.c:2261)\nhub_event (drivers/usb/core/hub.c:5833)\nprocess_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)\nworker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)\nkthread (kernel/kthread.c:319)\nret_from_fork (arch/x86/entry/entry_64.S:301)(CVE-2023-53023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.\n\nWhen first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of\nan arithmetic expression 2 \u0026lt;\u0026lt; (netmask - mask_bits - 1) is subject\nto overflow due to a failure casting operands to a larger data type\nbefore performing the arithmetic.\n\nNote that it\u0026apos;s harmless since the value will be checked at the next step.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2023-53032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before truncation in jfs_truncate_nolock()\n\nAdded a check for \u0026quot;read-only\u0026quot; mode in the `jfs_truncate_nolock`\nfunction to avoid errors related to writing to a read-only\nfilesystem.\n\nCall stack:\n\nblock_write_begin() {\n  jfs_write_failed() {\n    jfs_truncate() {\n      jfs_truncate_nolock() {\n        txEnd() {\n          ...\n          log = JFS_SBI(tblk-\u0026gt;sb)-\u0026gt;log;\n          // (log == NULL)\n\nIf the `isReadOnly(ip)` condition is triggered in\n`jfs_truncate_nolock`, the function execution will stop, and no\nfurther data modification will occur. Instead, the `xtTruncate`\nfunction will be called with the \u0026quot;COMMIT_WMAP\u0026quot; flag, preventing\nmodifications in \u0026quot;read-only\u0026quot; mode.(CVE-2024-58094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: extend RCU protection in igmp6_send()\n\nigmp6_send() can be called without RTNL or RCU being held.\n\nExtend RCU protection so that we can safely fetch the net pointer\nand avoid a potential UAF.\n\nNote that we no longer can use sock_alloc_send_skb() because\nipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.\n\nInstead use alloc_skb() and charge the net-\u0026gt;ipv6.igmp_sk\nsocket under RCU protection.(CVE-2025-21759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: extend RCU protection in ndisc_send_skb()\n\nndisc_send_skb() can be called without RTNL or RCU held.\n\nAcquire rcu_read_lock() earlier, so that we can use dev_net_rcu()\nand avoid a potential UAF.(CVE-2025-21760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: use RCU protection in ovs_vport_cmd_fill_info()\n\novs_vport_cmd_fill_info() can be called without RTNL or RCU.\n\nUse RCU protection and dev_net_rcu() to avoid potential UAF.(CVE-2025-21761)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narp: use RCU protection in arp_xmit()\n\narp_xmit() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nneighbour: use RCU protection in __neigh_notify()\n\n__neigh_notify() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21763)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: use RCU protection in ndisc_alloc_skb()\n\nndisc_alloc_skb() can be called without RTNL or RCU being held.\n\nAdd RCU protection to avoid possible UAF.(CVE-2025-21764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()\n\nWhen performing an iSCSI boot using IPv6, iscsistart still reads the\n/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix\nlength is 64, this causes the shift exponent to become negative,\ntriggering a UBSAN warning. As the concept of a subnet mask does not\napply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix use after free in lec_send()\n\nThe -\u0026gt;send() operation frees skb so save the length before calling\n-\u0026gt;send() to avoid a use after free.(CVE-2025-22004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix use-after-free in print_graph_function_flags during tracer switching\n\nKairui reported a UAF issue in print_graph_function_flags() during\nftrace stress testing [1]. This issue can be reproduced if puting a\n\u0026apos;mdelay(10)\u0026apos; after \u0026apos;mutex_unlock(\u0026amp;trace_types_lock)\u0026apos; in s_start(),\nand executing the following script:\n\n  $ echo function_graph \u0026gt; current_tracer\n  $ cat trace \u0026gt; /dev/null \u0026amp;\n  $ sleep 5  # Ensure the \u0026apos;cat\u0026apos; reaches the \u0026apos;mdelay(10)\u0026apos; point\n  $ echo timerlat \u0026gt; current_tracer\n\nThe root cause lies in the two calls to print_graph_function_flags\nwithin print_trace_line during each s_show():\n\n  * One through \u0026apos;iter-\u0026gt;trace-\u0026gt;print_line()\u0026apos;;\n  * Another through \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;, which is hidden in\n    print_trace_fmt() before print_trace_line returns.\n\nTracer switching only updates the former, while the latter continues\nto use the print_line function of the old tracer, which in the script\nabove is print_graph_function_flags.\n\nMoreover, when switching from the \u0026apos;function_graph\u0026apos; tracer to the\n\u0026apos;timerlat\u0026apos; tracer, s_start only calls graph_trace_close of the\n\u0026apos;function_graph\u0026apos; tracer to free \u0026apos;iter-\u0026gt;private\u0026apos;, but does not set\nit to NULL. This provides an opportunity for \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;\nto use an invalid \u0026apos;iter-\u0026gt;private\u0026apos;.\n\nTo fix this issue, set \u0026apos;iter-\u0026gt;private\u0026apos; to NULL immediately after\nfreeing it in graph_trace_close(), ensuring that an invalid pointer\nis not passed to other tracers. Additionally, clean up the unnecessary\n\u0026apos;iter-\u0026gt;private = NULL\u0026apos; during each \u0026apos;cat trace\u0026apos; when using wakeup and\nirqsoff tracers.\n\n [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix geneve_opt length integer overflow\n\nstruct geneve_opt uses 5 bit length for each single option, which\nmeans every vary size option should be smaller than 128 bytes.\n\nHowever, all current related Netlink policies cannot promise this\nlength condition and the attacker can exploit a exact 128-byte size\noption to *fake* a zero length option and confuse the parsing logic,\nfurther achieve heap out-of-bounds read.\n\nOne example crash log is like below:\n\n[    3.905425] ==================================================================\n[    3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0\n[    3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177\n[    3.906646]\n[    3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1\n[    3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[    3.907784] Call Trace:\n[    3.907925]  \u0026lt;TASK\u0026gt;\n[    3.908048]  dump_stack_lvl+0x44/0x5c\n[    3.908258]  print_report+0x184/0x4be\n[    3.909151]  kasan_report+0xc5/0x100\n[    3.909539]  kasan_check_range+0xf3/0x1a0\n[    3.909794]  memcpy+0x1f/0x60\n[    3.909968]  nla_put+0xa9/0xe0\n[    3.910147]  tunnel_key_dump+0x945/0xba0\n[    3.911536]  tcf_action_dump_1+0x1c1/0x340\n[    3.912436]  tcf_action_dump+0x101/0x180\n[    3.912689]  tcf_exts_dump+0x164/0x1e0\n[    3.912905]  fw_dump+0x18b/0x2d0\n[    3.913483]  tcf_fill_node+0x2ee/0x460\n[    3.914778]  tfilter_notify+0xf4/0x180\n[    3.915208]  tc_new_tfilter+0xd51/0x10d0\n[    3.918615]  rtnetlink_rcv_msg+0x4a2/0x560\n[    3.919118]  netlink_rcv_skb+0xcd/0x200\n[    3.919787]  netlink_unicast+0x395/0x530\n[    3.921032]  netlink_sendmsg+0x3d0/0x6d0\n[    3.921987]  __sock_sendmsg+0x99/0xa0\n[    3.922220]  __sys_sendto+0x1b7/0x240\n[    3.922682]  __x64_sys_sendto+0x72/0x90\n[    3.922906]  do_syscall_64+0x5e/0x90\n[    3.923814]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[    3.924122] RIP: 0033:0x7e83eab84407\n[    3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[    3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n[    3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407\n[    3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003\n[    3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c\n[    3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0\n[    3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8\n\nFix these issues by enforing correct length condition in related\npolicies.(CVE-2025-22055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero.  However, it occasionally spiked to 524,288 pages\nand never dropped.  Moreover, the value doubled when the application was\nterminated.  Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n  1. /proc/net/sockstat reports 0 pages\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 0\n\n  2. Run the script till the report reaches 524,288\n\n    # python3 test.py \u0026amp; sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 3 mem 524288  \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n  3. Kill the socket and confirm the number never drops\n\n    # pkill python3 \u0026amp;\u0026amp; sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 524288\n\n  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n    # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n  5. The number doubles\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue.  This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting.  However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n  1) Add size to sk-\u0026gt;sk_forward_alloc.\n  2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n      PAGE_SIZE and assign it to amount.\n  3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n  4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount.  3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct().  However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n    c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: don\u0026apos;t ignore IO flags\n\nIf blk-wbt is enabled by default, it\u0026apos;s found that raid write performance\nis quite bad because all IO are throttled by wbt of underlying disks,\ndue to flag REQ_IDLE is ignored. And turns out this behaviour exist since\nblk-wbt is introduced.\n\nOther than REQ_IDLE, other flags should not be ignored as well, for\nexample REQ_META can be set for filesystems, clearing it can cause priority\nreverse problems; And REQ_NOWAIT should not be cleared as well, because\nio will wait instead of failing directly in underlying disks.\n\nFix those problems by keep IO flags from master bio.\n\nFises: f51d46d0e7cb (\u0026quot;md: add support for REQ_NOWAIT\u0026quot;)(CVE-2025-22125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[   38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[   38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[   38.595158]\n[   38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[   38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[   38.595304] Call Trace:\n[   38.595308]  \u0026lt;TASK\u0026gt;\n[   38.595311]  dump_stack_lvl+0xa7/0xd0\n[   38.595325]  print_address_description.constprop.0+0x2c/0x3f0\n[   38.595339]  ? __ext4_check_dir_entry+0x67e/0x710\n[   38.595349]  print_report+0xaa/0x250\n[   38.595359]  ? __ext4_check_dir_entry+0x67e/0x710\n[   38.595368]  ? kasan_addr_to_slab+0x9/0x90\n[   38.595378]  kasan_report+0xab/0xe0\n[   38.595389]  ? __ext4_check_dir_entry+0x67e/0x710\n[   38.595400]  __ext4_check_dir_entry+0x67e/0x710\n[   38.595410]  ext4_empty_dir+0x465/0x990\n[   38.595421]  ? __pfx_ext4_empty_dir+0x10/0x10\n[   38.595432]  ext4_rmdir.part.0+0x29a/0xd10\n[   38.595441]  ? __dquot_initialize+0x2a7/0xbf0\n[   38.595455]  ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[   38.595464]  ? __pfx___dquot_initialize+0x10/0x10\n[   38.595478]  ? down_write+0xdb/0x140\n[   38.595487]  ? __pfx_down_write+0x10/0x10\n[   38.595497]  ext4_rmdir+0xee/0x140\n[   38.595506]  vfs_rmdir+0x209/0x670\n[   38.595517]  ? lookup_one_qstr_excl+0x3b/0x190\n[   38.595529]  do_rmdir+0x363/0x3c0\n[   38.595537]  ? __pfx_do_rmdir+0x10/0x10\n[   38.595544]  ? strncpy_from_user+0x1ff/0x2e0\n[   38.595561]  __x64_sys_unlinkat+0xf0/0x130\n[   38.595570]  do_syscall_64+0x5b/0x180\n[   38.595583]  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2505.1.0.0326.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2505.1.0.0326.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1465"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2020-36789"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47641"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47670"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49217"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49232"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49298"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49385"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49429"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49626"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49647"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52935"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53019"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21759"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21760"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21761"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21762"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21763"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21764"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22055"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37785"}],"database_specific":{"severity":"High"}}