{"schema_version":"1.7.2","id":"OESA-2025-1317","modified":"2025-03-21T13:18:34Z","published":"2025-03-21T13:18:34Z","upstream":["CVE-2021-47634","CVE-2021-47656","CVE-2022-49052","CVE-2022-49087","CVE-2022-49155","CVE-2022-49248","CVE-2022-49276","CVE-2022-49277","CVE-2022-49315","CVE-2022-49324","CVE-2022-49331","CVE-2022-49375","CVE-2022-49414","CVE-2022-49488","CVE-2022-49489","CVE-2022-49513","CVE-2022-49514","CVE-2022-49527","CVE-2022-49532","CVE-2022-49544","CVE-2022-49581","CVE-2022-49608","CVE-2022-49682","CVE-2022-49725","CVE-2022-49729","CVE-2024-58009","CVE-2025-21791"],"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\nubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl\n\nHulk Robot reported a KASAN report about use-after-free:\n ==================================================================\n BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160\n Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385\n [...]\n Call Trace:\n  klist_dec_and_del+0xa7/0x4a0\n  klist_put+0xc7/0x1a0\n  device_del+0x4d4/0xed0\n  cdev_device_del+0x1a/0x80\n  ubi_attach_mtd_dev+0x2951/0x34b0 [ubi]\n  ctrl_cdev_ioctl+0x286/0x2f0 [ubi]\n\n Allocated by task 1414:\n  device_add+0x60a/0x18b0\n  cdev_device_add+0x103/0x170\n  ubi_create_volume+0x1118/0x1a10 [ubi]\n  ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]\n\n Freed by task 1385:\n  cdev_device_del+0x1a/0x80\n  ubi_remove_volume+0x438/0x6c0 [ubi]\n  ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi]\n [...]\n ==================================================================\n\nThe lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held\nby ubi_cdev_ioctl is ubi-\u0026gt;device_mutex. Therefore, the two locks can be\nconcurrent.\n\nctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.\nubi_detach is bug-free because it uses reference counting to prevent\nconcurrency. However, uif_init and uif_close in ubi_attach may race with\nubi_cdev_ioctl.\n\nuif_init will race with ubi_cdev_ioctl as in the following stack.\n           cpu1                   cpu2                  cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n  uif_init\n                           ubi_cdev_ioctl\n                            ubi_create_volume\n                             cdev_device_add\n   ubi_add_volume\n   // sysfs exist\n   kill_volumes\n                                                    ubi_cdev_ioctl\n                                                     ubi_remove_volume\n                                                      cdev_device_del\n                                                       // first free\n    ubi_free_volume\n     cdev_del\n     // double free\n   cdev_device_del\n\nAnd uif_close will race with ubi_cdev_ioctl as in the following stack.\n           cpu1                   cpu2                  cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n  uif_init\n                           ubi_cdev_ioctl\n                            ubi_create_volume\n                             cdev_device_add\n  ubi_debugfs_init_dev\n  //error goto out_uif;\n  uif_close\n   kill_volumes\n                                                    ubi_cdev_ioctl\n                                                     ubi_remove_volume\n                                                      cdev_device_del\n                                                       // first free\n    ubi_free_volume\n    // double free\n\nThe cause of this problem is that commit 714fb87e8bc0 make device\n\u0026quot;available\u0026quot; before it becomes accessible via sysfs. Therefore, we\nroll back the modification. We will fix the race condition between\nubi device creation and udev by removing ubi_get_device in\nvol_attribute_show and dev_attribute_show.This avoids accessing\nuninitialized ubi_devices[ubi_num].\n\nubi_get_device is used to prevent devices from being deleted during\nsysfs execution. However, now kernfs ensures that devices will not\nbe deleted before all reference counting are released.\nThe key process is shown in the following stack.\n\ndevice_del\n  device_remove_attrs\n    device_remove_groups\n      sysfs_remove_groups\n        sysfs_remove_group\n          remove_files\n            kernfs_remove_by_name\n              kernfs_remove_by_name_ns\n                __kernfs_remove\n                  kernfs_drain(CVE-2021-47634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix use-after-free in jffs2_clear_xattr_subsystem\n\nWhen we mount a jffs2 image, assume that the first few blocks of\nthe image are normal and contain at least one xattr-related inode,\nbut the next block is abnormal. As a result, an error is returned\nin jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then\ncalled in jffs2_build_filesystem() and then again in\njffs2_do_fill_super().\n\nFinally we can observe the following report:\n ==================================================================\n BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac\n Read of size 8 at addr ffff8881243384e0 by task mount/719\n\n Call Trace:\n  dump_stack+0x115/0x16b\n  jffs2_clear_xattr_subsystem+0x95/0x6ac\n  jffs2_do_fill_super+0x84f/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n  mtd_get_sb+0x254/0x400\n  mtd_get_sb_by_nr+0x4f/0xd0\n  get_tree_mtd+0x498/0x840\n  jffs2_get_tree+0x25/0x30\n  vfs_get_tree+0x8d/0x2e0\n  path_mount+0x50f/0x1e50\n  do_mount+0x107/0x130\n  __se_sys_mount+0x1c5/0x2f0\n  __x64_sys_mount+0xc7/0x160\n  do_syscall_64+0x45/0x70\n  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\n Allocated by task 719:\n  kasan_save_stack+0x23/0x60\n  __kasan_kmalloc.constprop.0+0x10b/0x120\n  kasan_slab_alloc+0x12/0x20\n  kmem_cache_alloc+0x1c0/0x870\n  jffs2_alloc_xattr_ref+0x2f/0xa0\n  jffs2_scan_medium.cold+0x3713/0x4794\n  jffs2_do_mount_fs.cold+0xa7/0x2253\n  jffs2_do_fill_super+0x383/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n Freed by task 719:\n  kmem_cache_free+0xcc/0x7b0\n  jffs2_free_xattr_ref+0x78/0x98\n  jffs2_clear_xattr_subsystem+0xa1/0x6ac\n  jffs2_do_mount_fs.cold+0x5e6/0x2253\n  jffs2_do_fill_super+0x383/0xc30\n  jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n The buggy address belongs to the object at ffff8881243384b8\n  which belongs to the cache jffs2_xattr_ref of size 48\n The buggy address is located 40 bytes inside of\n  48-byte region [ffff8881243384b8, ffff8881243384e8)\n [...]\n ==================================================================\n\nThe triggering of the BUG is shown in the following stack:\n-----------------------------------------------------------\njffs2_fill_super\n  jffs2_do_fill_super\n    jffs2_do_mount_fs\n      jffs2_build_filesystem\n        jffs2_scan_medium\n          jffs2_scan_eraseblock        \u0026lt;--- ERROR\n        jffs2_clear_xattr_subsystem    \u0026lt;--- free\n    jffs2_clear_xattr_subsystem        \u0026lt;--- free again\n-----------------------------------------------------------\n\nAn error is returned in jffs2_do_mount_fs(). If the error is returned\nby jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to\nbe executed. If the error is returned by jffs2_build_filesystem(), the\njffs2_clear_xattr_subsystem() also does not need to be executed again.\nSo move jffs2_clear_xattr_subsystem() from \u0026apos;out_inohash\u0026apos; to \u0026apos;out_root\u0026apos;\nto fix this UAF problem.(CVE-2021-47656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix unexpected zeroed page mapping with zram swap\n\nTwo processes under CLONE_VM cloning, user process can be corrupted by\nseeing zeroed page unexpectedly.\n\n      CPU A                        CPU B\n\n  do_swap_page                do_swap_page\n  SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path\n  swap_readpage valid data\n    swap_slot_free_notify\n      delete zram entry\n                              swap_readpage zeroed(invalid) data\n                              pte_lock\n                              map the *zero data* to userspace\n                              pte_unlock\n  pte_lock\n  if (!pte_same)\n    goto out_nomap;\n  pte_unlock\n  return and next refault will\n  read zeroed data\n\nThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn\u0026apos;t\nincrease the refcount of swap slot at copy_mm so it couldn\u0026apos;t catch up\nwhether it\u0026apos;s safe or not to discard data from backing device.  In the\ncase, only the lock it could rely on to synchronize swap slot freeing is\npage table lock.  Thus, this patch gets rid of the swap_slot_free_notify\nfunction.  With this patch, CPU A will see correct data.\n\n      CPU A                        CPU B\n\n  do_swap_page                do_swap_page\n  SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path\n                              swap_readpage original data\n                              pte_lock\n                              map the original data\n                              swap_free\n                                swap_range_free\n                                  bd_disk-\u0026gt;fops-\u0026gt;swap_slot_free_notify\n  swap_readpage read zeroed data\n                              pte_unlock\n  pte_lock\n  if (!pte_same)\n    goto out_nomap;\n  pte_unlock\n  return\n  on next refault will see mapped data by CPU B\n\nThe concern of the patch would increase memory consumption since it\ncould keep wasted memory with compressed form in zram as well as\nuncompressed form in address space.  However, most of cases of zram uses\nno readahead and do_swap_page is followed by swap_free so it will free\nthe compressed form from in zram quickly.(CVE-2022-49052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: fix a race in rxrpc_exit_net()\n\nCurrent code can lead to the following race:\n\nCPU0                                                 CPU1\n\nrxrpc_exit_net()\n                                                     rxrpc_peer_keepalive_worker()\n                                                       if (rxnet-\u0026gt;live)\n\n  rxnet-\u0026gt;live = false;\n  del_timer_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer);\n\n                                                             timer_reduce(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer, jiffies + delay);\n\n  cancel_work_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_work);\n\nrxrpc_exit_net() exits while peer_keepalive_timer is still armed,\nleading to use-after-free.\n\nsyzbot report was:\n\nODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0\nWARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nModules linked in:\nCPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nCode: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 \u0026lt;0f\u0026gt; 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3\nRSP: 0018:ffffc9000353fb00 EFLAGS: 00010082\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000\nRDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0\nR13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000\nFS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]\n debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023\n kfree+0xd6/0x310 mm/slab.c:3809\n ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176\n ops_free_list net/core/net_namespace.c:174 [inline]\n cleanup_net+0x591/0xb00 net/core/net_namespace.c:598\n process_one_work+0x996/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e9/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298\n \u0026lt;/TASK\u0026gt;(CVE-2022-49087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()\n\n[   12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020\n[   12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[   12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G          I      --------- ---  5.14.0-29.el9.x86_64 #1\n[   12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018\n[   12.356356] Call Trace:\n[   12.358821]  dump_stack_lvl+0x34/0x44\n[   12.362514]  check_preemption_disabled+0xd9/0xe0\n[   12.367164]  qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[   12.372481]  qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]\n[   12.377617]  ? _raw_spin_lock_irqsave+0x19/0x40\n[   12.384284]  local_pci_probe+0x42/0x80\n[   12.390162]  ? pci_match_device+0xd7/0x110\n[   12.396366]  pci_device_probe+0xfd/0x1b0\n[   12.402372]  really_probe+0x1e7/0x3e0\n[   12.408114]  __driver_probe_device+0xfe/0x180\n[   12.414544]  driver_probe_device+0x1e/0x90\n[   12.420685]  __driver_attach+0xc0/0x1c0\n[   12.426536]  ? __device_attach_driver+0xe0/0xe0\n[   12.433061]  ? __device_attach_driver+0xe0/0xe0\n[   12.439538]  bus_for_each_dev+0x78/0xc0\n[   12.445294]  bus_add_driver+0x12b/0x1e0\n[   12.451021]  driver_register+0x8f/0xe0\n[   12.456631]  ? 0xffffffffc07bc000\n[   12.461773]  qla2x00_module_init+0x1be/0x229 [qla2xxx]\n[   12.468776]  do_one_initcall+0x44/0x200\n[   12.474401]  ? load_module+0xad3/0xba0\n[   12.479908]  ? kmem_cache_alloc_trace+0x45/0x410\n[   12.486268]  do_init_module+0x5c/0x280\n[   12.491730]  __do_sys_init_module+0x12e/0x1b0\n[   12.497785]  do_syscall_64+0x3b/0x90\n[   12.503029]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[   12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction\n\nAV/C deferred transaction was supported at a commit 00a7bb81c20f (\u0026quot;ALSA:\nfirewire-lib: Add support for deferred transaction\u0026quot;) while \u0026apos;deferrable\u0026apos;\nflag can be uninitialized for non-control/notify AV/C transactions.\nUBSAN reports it:\n\nkernel: ================================================================================\nkernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9\nkernel: load of value 158 is not a valid value for type \u0026apos;_Bool\u0026apos;\nkernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P           OE     5.15.0-18-generic #18-Ubuntu\nkernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019\nkernel: Call Trace:\nkernel:  \u0026lt;IRQ\u0026gt;\nkernel:  show_stack+0x52/0x58\nkernel:  dump_stack_lvl+0x4a/0x5f\nkernel:  dump_stack+0x10/0x12\nkernel:  ubsan_epilogue+0x9/0x45\nkernel:  __ubsan_handle_load_invalid_value.cold+0x44/0x49\nkernel:  fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]\nkernel:  fcp_response+0x28/0x30 [snd_firewire_lib]\nkernel:  fw_core_handle_request+0x230/0x3d0 [firewire_core]\nkernel:  handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel:  ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel:  ? transmit_complete_callback+0x9f/0x120 [firewire_core]\nkernel:  ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]\nkernel:  tasklet_action_common.constprop.0+0xea/0xf0\nkernel:  tasklet_action+0x22/0x30\nkernel:  __do_softirq+0xd9/0x2e3\nkernel:  ? irq_finalize_oneshot.part.0+0xf0/0xf0\nkernel:  do_softirq+0x75/0xa0\nkernel:  \u0026lt;/IRQ\u0026gt;\nkernel:  \u0026lt;TASK\u0026gt;\nkernel:  __local_bh_enable_ip+0x50/0x60\nkernel:  irq_forced_thread_fn+0x7e/0x90\nkernel:  irq_thread+0xba/0x190\nkernel:  ? irq_thread_fn+0x60/0x60\nkernel:  kthread+0x11e/0x140\nkernel:  ? irq_thread_check_affinity+0xf0/0xf0\nkernel:  ? set_kthread_struct+0x50/0x50\nkernel:  ret_from_fork+0x22/0x30\nkernel:  \u0026lt;/TASK\u0026gt;\nkernel: ================================================================================\n\nThis commit fixes the bug. The bug has no disadvantage for the non-\ncontrol/notify AV/C transactions since the flag has an effect for AV/C\nresponse with INTERIM (0x0f) status which is not used for the transactions\nin AV/C general specification.(CVE-2022-49248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_scan_medium\n\nIf an error is returned in jffs2_scan_eraseblock() and some memory\nhas been added to the jffs2_summary *s, we can observe the following\nkmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88812b889c40 (size 64):\n  comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n  hex dump (first 32 bytes):\n    40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00  @H........1...P.\n    00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08  ................\n  backtrace:\n    [\u0026lt;ffffffffae93a3a3\u0026gt;] __kmalloc+0x613/0x910\n    [\u0026lt;ffffffffaf423b9c\u0026gt;] jffs2_sum_add_dirent_mem+0x5c/0xa0\n    [\u0026lt;ffffffffb0f3afa8\u0026gt;] jffs2_scan_medium.cold+0x36e5/0x4794\n    [\u0026lt;ffffffffb0f3dbe1\u0026gt;] jffs2_do_mount_fs.cold+0xa7/0x2267\n    [\u0026lt;ffffffffaf40acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n    [\u0026lt;ffffffffaf40c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n    [\u0026lt;ffffffffb0315d64\u0026gt;] mtd_get_sb+0x254/0x400\n    [\u0026lt;ffffffffb0315f5f\u0026gt;] mtd_get_sb_by_nr+0x4f/0xd0\n    [\u0026lt;ffffffffb0316478\u0026gt;] get_tree_mtd+0x498/0x840\n    [\u0026lt;ffffffffaf40bd15\u0026gt;] jffs2_get_tree+0x25/0x30\n    [\u0026lt;ffffffffae9f358d\u0026gt;] vfs_get_tree+0x8d/0x2e0\n    [\u0026lt;ffffffffaea7a98f\u0026gt;] path_mount+0x50f/0x1e50\n    [\u0026lt;ffffffffaea7c3d7\u0026gt;] do_mount+0x107/0x130\n    [\u0026lt;ffffffffaea7c5c5\u0026gt;] __se_sys_mount+0x1c5/0x2f0\n    [\u0026lt;ffffffffaea7c917\u0026gt;] __x64_sys_mount+0xc7/0x160\n    [\u0026lt;ffffffffb10142f5\u0026gt;] do_syscall_64+0x45/0x70\nunreferenced object 0xffff888114b54840 (size 32):\n  comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n  hex dump (first 32 bytes):\n    c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00  .u..............\n    00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5  ......D...kkkkk.\n  backtrace:\n    [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n    [\u0026lt;ffffffffaf423b04\u0026gt;] jffs2_sum_add_inode_mem+0x54/0x90\n    [\u0026lt;ffffffffb0f3bd44\u0026gt;] jffs2_scan_medium.cold+0x4481/0x4794\n    [...]\nunreferenced object 0xffff888114b57280 (size 32):\n  comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838393 (age 34.357s)\n  hex dump (first 32 bytes):\n    10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00  ..l.............\n    00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5  ..8...(...kkkkk.\n  backtrace:\n    [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n    [\u0026lt;ffffffffaf423c34\u0026gt;] jffs2_sum_add_xattr_mem+0x54/0x90\n    [\u0026lt;ffffffffb0f3a24f\u0026gt;] jffs2_scan_medium.cold+0x298c/0x4794\n    [...]\nunreferenced object 0xffff8881116cd510 (size 16):\n  comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838395 (age 34.355s)\n  hex dump (first 16 bytes):\n    00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5  ..........`...k.\n  backtrace:\n    [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n    [\u0026lt;ffffffffaf423cc4\u0026gt;] jffs2_sum_add_xref_mem+0x54/0x90\n    [\u0026lt;ffffffffb0f3b2e3\u0026gt;] jffs2_scan_medium.cold+0x3a20/0x4794\n    [...]\n--------------------------------------------\n\nTherefore, we should call jffs2_sum_reset_collected(s) on exit to\nrelease the memory added in s. In addition, a new tag \u0026quot;out_buf\u0026quot; is\nadded to prevent the NULL pointer reference caused by s being NULL.\n(thanks to Zhang Yi for this analysis)(CVE-2022-49276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_do_mount_fs\n\nIf jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,\nwe can observe the following kmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88811b25a640 (size 64):\n  comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;ffffffffa493be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n    [\u0026lt;ffffffffa5423a06\u0026gt;] jffs2_sum_init+0x86/0x130\n    [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n    [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n    [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n    [...]\nunreferenced object 0xffff88812c760000 (size 65536):\n  comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\n  hex dump (first 32 bytes):\n    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................\n    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................\n  backtrace:\n    [\u0026lt;ffffffffa493a449\u0026gt;] __kmalloc+0x6b9/0x910\n    [\u0026lt;ffffffffa5423a57\u0026gt;] jffs2_sum_init+0xd7/0x130\n    [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n    [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n    [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n    [...]\n--------------------------------------------\n\nThis is because the resources allocated in jffs2_sum_init() are not\nreleased. Call jffs2_sum_exit() to release these resources to solve\nthe problem.(CVE-2022-49277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()\n\nThere is a deadlock in rtllib_beacons_stop(), which is shown\nbelow:\n\n   (Thread 1)              |      (Thread 2)\n                           | rtllib_send_beacon()\nrtllib_beacons_stop()      |  mod_timer()\n spin_lock_irqsave() //(1) |  (wait a time)\n ...                       | rtllib_send_beacon_cb()\n del_timer_sync()          |  spin_lock_irqsave() //(2)\n (wait timer to stop)      |  ...\n\nWe hold ieee-\u0026gt;beacon_lock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u0026gt;beacon_lock in position (2) of thread 2.\nAs a result, rtllib_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.(CVE-2022-49315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmips: cpc: Fix refcount leak in mips_cpc_default_phys_base\n\nAdd the missing of_node_put() to release the refcount incremented\nby of_find_compatible_node().(CVE-2022-49324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling\n\nError paths do not free previously allocated memory. Add devm_kfree() to\nthose failure paths.(CVE-2022-49331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: mt6397: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2022-49375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix race condition between ext4_write and ext4_convert_inline_data\n\nHulk Robot reported a BUG_ON:\n ==================================================================\n EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,\n block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters\n kernel BUG at fs/ext4/ext4_jbd2.c:53!\n invalid opcode: 0000 [#1] SMP KASAN PTI\n CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1\n RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]\n RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116\n [...]\n Call Trace:\n  ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795\n  generic_perform_write+0x279/0x3c0 mm/filemap.c:3344\n  ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270\n  ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520\n  do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732\n  do_iter_write+0x107/0x430 fs/read_write.c:861\n  vfs_writev fs/read_write.c:934 [inline]\n  do_pwritev+0x1e5/0x380 fs/read_write.c:1031\n [...]\n ==================================================================\n\nAbove issue may happen as follows:\n           cpu1                     cpu2\n__________________________|__________________________\ndo_pwritev\n vfs_writev\n  do_iter_write\n   ext4_file_write_iter\n    ext4_buffered_write_iter\n     generic_perform_write\n      ext4_da_write_begin\n                           vfs_fallocate\n                            ext4_fallocate\n                             ext4_convert_inline_data\n                              ext4_convert_inline_data_nolock\n                               ext4_destroy_inline_data_nolock\n                                clear EXT4_STATE_MAY_INLINE_DATA\n                               ext4_map_blocks\n                                ext4_ext_map_blocks\n                                 ext4_mb_new_blocks\n                                  ext4_mb_regular_allocator\n                                   ext4_mb_good_group_nolock\n                                    ext4_mb_init_group\n                                     ext4_mb_init_cache\n                                      ext4_mb_generate_buddy  --\u0026gt; error\n       ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n                                ext4_restore_inline_data\n                                 set EXT4_STATE_MAY_INLINE_DATA\n       ext4_block_write_begin\n      ext4_da_write_end\n       ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n       ext4_write_inline_data_end\n        handle=NULL\n        ext4_journal_stop(handle)\n         __ext4_journal_stop\n          ext4_put_nojournal(handle)\n           ref_cnt = (unsigned long)handle\n           BUG_ON(ref_cnt == 0)  ---\u0026gt; BUG_ON\n\nThe lock held by ext4_convert_inline_data is xattr_sem, but the lock\nheld by generic_perform_write is i_rwsem. Therefore, the two locks can\nbe concurrent.\n\nTo solve above issue, we add inode_lock() for ext4_convert_inline_data().\nAt the same time, move ext4_convert_inline_data() in front of\next4_punch_hole(), remove similar handling from ext4_punch_hole().(CVE-2022-49414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected\n\nThere is a possibility for mdp5_get_global_state to return\n-EDEADLK when acquiring the modeset lock, but currently global_state in\nmdp5_mixer_release doesn\u0026apos;t check for if an error is returned.\n\nTo avoid a NULL dereference error, let\u0026apos;s have mdp5_mixer_release\ncheck if an error is returned and propagate that error.\n\nPatchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume\n\nBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3\n\nCall trace:\n  dpu_vbif_init_memtypes+0x40/0xb8\n  dpu_runtime_resume+0xcc/0x1c0\n  pm_generic_runtime_resume+0x30/0x44\n  __genpd_runtime_resume+0x68/0x7c\n  genpd_runtime_resume+0x134/0x258\n  __rpm_callback+0x98/0x138\n  rpm_callback+0x30/0x88\n  rpm_resume+0x36c/0x49c\n  __pm_runtime_resume+0x80/0xb0\n  dpu_core_irq_uninstall+0x30/0xb0\n  dpu_irq_uninstall+0x18/0x24\n  msm_drm_uninit+0xd8/0x16c\n\nPatchwork: https://patchwork.freedesktop.org/patch/483255/\n[DB: fixed Fixes tag](CVE-2022-49489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n  WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n  Modules linked in:\n  CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n  Hardware name: Marvell OcteonTX CN96XX board (DT)\n  pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : debug_print_object+0xb8/0x100\n  lr : debug_print_object+0xb8/0x100\n  sp : ffff80001dfcf9a0\n  x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n  x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n  x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n  x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n  x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n  x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n  x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n  x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n  x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n  Call trace:\n   debug_print_object+0xb8/0x100\n   __debug_check_no_obj_freed+0x1d0/0x25c\n   debug_check_no_obj_freed+0x24/0xa0\n   kfree+0x11c/0x440\n   cpufreq_dbs_governor_exit+0xa8/0xac\n   cpufreq_exit_governor+0x44/0x90\n   cpufreq_set_policy+0x29c/0x570\n   store_scaling_governor+0x110/0x154\n   store+0xb0/0xe0\n   sysfs_kf_write+0x58/0x84\n   kernfs_fop_write_iter+0x12c/0x1c0\n   new_sync_write+0xf0/0x18c\n   vfs_write+0x1cc/0x220\n   ksys_write+0x74/0x100\n   __arm64_sys_write+0x28/0x3c\n   invoke_syscall.constprop.0+0x58/0xf0\n   do_el0_svc+0x70/0x170\n   el0_svc+0x54/0x190\n   el0t_64_sync_handler+0xa4/0x130\n   el0t_64_sync+0x1a0/0x1a4\n  irq event stamp: 189006\n  hardirqs last  enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n  hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n  softirqs last  enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n  softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n  cpufreq_dbs_governor_exit() now, it is also necessary to put the\n  invocation of the governor -\u0026gt;exit() callback into the new\n  cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe\n\nCall of_node_put(platform_node) to avoid refcount leak in\nthe error path.(CVE-2022-49514)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: avoid null dereference in deinit\n\nIf venus_probe fails at pm_runtime_put_sync the error handling first\ncalls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets\ncore-\u0026gt;ops to NULL, hfi_core_deinit cannot call the core_deinit function\nanymore.\n\nAvoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes\n\ndrm_cvt_mode may return NULL and we should check it.\n\nThis bug is found by syzkaller:\n\nFAULT_INJECTION stacktrace:\n[  168.567394] FAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 1\n[  168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[  168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[  168.567408] Call trace:\n[  168.567414]  dump_backtrace+0x0/0x310\n[  168.567418]  show_stack+0x28/0x38\n[  168.567423]  dump_stack+0xec/0x15c\n[  168.567427]  should_fail+0x3ac/0x3d0\n[  168.567437]  __should_failslab+0xb8/0x120\n[  168.567441]  should_failslab+0x28/0xc0\n[  168.567445]  kmem_cache_alloc_trace+0x50/0x640\n[  168.567454]  drm_mode_create+0x40/0x90\n[  168.567458]  drm_cvt_mode+0x48/0xc78\n[  168.567477]  virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]\n[  168.567485]  drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[  168.567492]  drm_mode_getconnector+0x2e0/0xa70\n[  168.567496]  drm_ioctl_kernel+0x11c/0x1d8\n[  168.567514]  drm_ioctl+0x558/0x6d0\n[  168.567522]  do_vfs_ioctl+0x160/0xf30\n[  168.567525]  ksys_ioctl+0x98/0xd8\n[  168.567530]  __arm64_sys_ioctl+0x50/0xc8\n[  168.567536]  el0_svc_common+0xc8/0x320\n[  168.567540]  el0_svc_handler+0xf8/0x160\n[  168.567544]  el0_svc+0x10/0x218\n\nKASAN stacktrace:\n[  168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[  168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425\n[  168.567566]\n[  168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[  168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[  168.567575] Call trace:\n[  168.567578]  dump_backtrace+0x0/0x310\n[  168.567582]  show_stack+0x28/0x38\n[  168.567586]  dump_stack+0xec/0x15c\n[  168.567591]  kasan_report+0x244/0x2f0\n[  168.567594]  __asan_load4+0x58/0xb0\n[  168.567607]  virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[  168.567612]  drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[  168.567617]  drm_mode_getconnector+0x2e0/0xa70\n[  168.567621]  drm_ioctl_kernel+0x11c/0x1d8\n[  168.567624]  drm_ioctl+0x558/0x6d0\n[  168.567628]  do_vfs_ioctl+0x160/0xf30\n[  168.567632]  ksys_ioctl+0x98/0xd8\n[  168.567636]  __arm64_sys_ioctl+0x50/0xc8\n[  168.567641]  el0_svc_common+0xc8/0x320\n[  168.567645]  el0_svc_handler+0xf8/0x160\n[  168.567649]  el0_svc+0x10/0x218(CVE-2022-49532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipw2x00: Fix potential NULL dereference in libipw_xmit()\n\ncrypt and crypt-\u0026gt;ops could be null, so we need to checking null\nbefore dereference(CVE-2022-49544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: Fix buffer overflow in be_get_module_eeprom\n\nbe_cmd_read_port_transceiver_data assumes that it is given a buffer that\nis at least PAGE_DATA_LEN long, or twice that if the module supports SFF\n8472. However, this is not always the case.\n\nFix this by passing the desired offset and length to\nbe_cmd_read_port_transceiver_data so that we only copy the bytes once.(CVE-2022-49581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: ralink: Check for null return of devm_kcalloc\n\nBecause of the possible failure of the allocation, data-\u0026gt;domains might\nbe NULL pointer and will cause the dereference of the NULL pointer\nlater.\nTherefore, it might be better to check it and directly return -ENOMEM\nwithout releasing data manually if fails, because the comment of the\ndevm_kmalloc() says \u0026quot;Memory allocated with this function is\nautomatically freed on driver detach.\u0026quot;.(CVE-2022-49608)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxtensa: Fix refcount leak bug in time.c\n\nIn calibrate_ccount(), of_find_compatible_node() will return a node\npointer with refcount incremented. We should use of_node_put() when\nit is not used anymore.(CVE-2022-49682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix call trace in setup_tx_descriptors\n\nAfter PF reset and ethtool -t there was call trace in dmesg\nsometimes leading to panic. When there was some time, around 5\nseconds, between reset and test there were no errors.\n\nProblem was that pf reset calls i40e_vsi_close in prep_for_reset\nand ethtool -t calls i40e_vsi_close in diag_test. If there was not\nenough time between those commands the second i40e_vsi_close starts\nbefore previous i40e_vsi_close was done which leads to crash.\n\nAdd check to diag_test if pf is in reset and don\u0026apos;t start offline\ntests if it is true.\nAdd netif_info(\u0026quot;testing failed\u0026quot;) into unhappy path of i40e_diag_test()(CVE-2022-49725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred\n\nSimilar to the handling of play_deferred in commit 19cfe912c37b\n(\u0026quot;Bluetooth: btusb: Fix memory leak in play_deferred\u0026quot;), we thought\na patch might be needed here as well.\n\nCurrently usb_submit_urb is called directly to submit deferred tx\nurbs after unanchor them.\n\nSo the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb\nand cause memory leak.\n\nPut those urbs in tx_anchor to avoid the leak, and also fix the error\nhandling.(CVE-2022-49729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc\n\nA NULL sock pointer is passed into l2cap_sock_alloc() when it is called\nfrom l2cap_sock_new_connection_cb() and the error handling paths should\nalso be aware of it.\n\nSeemingly a more elegant solution would be to swap bt_sock_alloc() and\nl2cap_chan_create() calls since they are not interdependent to that moment\nbut then l2cap_chan_create() adds the soon to be deallocated and still\ndummy-initialized channel to the global list accessible by many L2CAP\npaths. The channel would be removed from the list in short period of time\nbut be a bit more straight-forward here and just check for NULL instead of\nchanging the order of function calls.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.(CVE-2024-58009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n  ip_send_skb()\n   ip_local_out()\n    __ip_local_out()\n     l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)","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-2503.4.0.0320.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2503.4.0.0320.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47634"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47656"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49248"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49276"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49277"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49315"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49324"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49331"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49375"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49488"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49489"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49513"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49514"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49532"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49544"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49581"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49608"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49682"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49729"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21791"}],"database_specific":{"severity":"High"}}