{"schema_version":"1.7.2","id":"OESA-2024-2122","modified":"2024-09-14T11:09:06Z","published":"2024-09-14T11:09:06Z","upstream":["CVE-2022-48905","CVE-2022-48914","CVE-2022-48926","CVE-2023-52451","CVE-2023-52612","CVE-2023-52855","CVE-2023-52894","CVE-2023-52907","CVE-2024-42259","CVE-2024-42295","CVE-2024-42301","CVE-2024-43856","CVE-2024-43858","CVE-2024-43871","CVE-2024-43914"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nibmvnic: free reset-work-item when flushing\r\n\r\nFix a tiny memory leak when flushing the reset work queue.(CVE-2022-48905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxen/netfront: destroy queues before real_num_tx_queues is zeroed\r\n\r\nxennet_destroy_queues() relies on info-\u0026gt;netdev-\u0026gt;real_num_tx_queues to\ndelete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5\n(\u0026quot;net-sysfs: update the queue counts in the unregistration path\u0026quot;),\nunregister_netdev() indirectly sets real_num_tx_queues to 0. Those two\nfacts together means, that xennet_destroy_queues() called from\nxennet_remove() cannot do its job, because it\u0026apos;s called after\nunregister_netdev(). This results in kfree-ing queues that are still\nlinked in napi, which ultimately crashes:\r\n\r\n    BUG: kernel NULL pointer dereference, address: 0000000000000000\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP PTI\n    CPU: 1 PID: 52 Comm: xenwatch Tainted: G        W         5.16.10-1.32.fc32.qubes.x86_64+ #226\n    RIP: 0010:free_netdev+0xa3/0x1a0\n    Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff \u0026lt;48\u0026gt; 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00\n    RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286\n    RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000\n    RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff\n    RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000\n    R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050\n    R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680\n    FS:  0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0\n    Call Trace:\n     \u0026lt;TASK\u0026gt;\n     xennet_remove+0x13d/0x300 [xen_netfront]\n     xenbus_dev_remove+0x6d/0xf0\n     __device_release_driver+0x17a/0x240\n     device_release_driver+0x24/0x30\n     bus_remove_device+0xd8/0x140\n     device_del+0x18b/0x410\n     ? _raw_spin_unlock+0x16/0x30\n     ? klist_iter_exit+0x14/0x20\n     ? xenbus_dev_request_and_reply+0x80/0x80\n     device_unregister+0x13/0x60\n     xenbus_dev_changed+0x18e/0x1f0\n     xenwatch_thread+0xc0/0x1a0\n     ? do_wait_intr_irq+0xa0/0xa0\n     kthread+0x16b/0x190\n     ? set_kthread_struct+0x40/0x40\n     ret_from_fork+0x22/0x30\n     \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling xennet_destroy_queues() from xennet_uninit(),\nwhen real_num_tx_queues is still available. This ensures that queues are\ndestroyed when real_num_tx_queues is set to 0, regardless of how\nunregister_netdev() was called.\r\n\r\nOriginally reported at\nhttps://github.com/QubesOS/qubes-issues/issues/7257(CVE-2022-48914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: rndis: add spinlock for rndis response list\r\n\r\nThere\u0026apos;s no lock for rndis response list. It could cause list corruption\nif there\u0026apos;re two different list_add at the same time like below.\nIt\u0026apos;s better to add in rndis_add_response / rndis_free_response\n/ rndis_get_next_response to prevent any race condition on response list.\r\n\r\n[  361.894299] [1:   irq/191-dwc3:16979] list_add corruption.\nnext-\u0026gt;prev should be prev (ffffff80651764d0),\nbut was ffffff883dc36f80. (next=ffffff80651764d0).\r\n\r\n[  361.904380] [1:   irq/191-dwc3:16979] Call trace:\n[  361.904391] [1:   irq/191-dwc3:16979]  __list_add_valid+0x74/0x90\n[  361.904401] [1:   irq/191-dwc3:16979]  rndis_msg_parser+0x168/0x8c0\n[  361.904409] [1:   irq/191-dwc3:16979]  rndis_command_complete+0x24/0x84\n[  361.904417] [1:   irq/191-dwc3:16979]  usb_gadget_giveback_request+0x20/0xe4\n[  361.904426] [1:   irq/191-dwc3:16979]  dwc3_gadget_giveback+0x44/0x60\n[  361.904434] [1:   irq/191-dwc3:16979]  dwc3_ep0_complete_data+0x1e8/0x3a0\n[  361.904442] [1:   irq/191-dwc3:16979]  dwc3_ep0_interrupt+0x29c/0x3dc\n[  361.904450] [1:   irq/191-dwc3:16979]  dwc3_process_event_entry+0x78/0x6cc\n[  361.904457] [1:   irq/191-dwc3:16979]  dwc3_process_event_buf+0xa0/0x1ec\n[  361.904465] [1:   irq/191-dwc3:16979]  dwc3_thread_interrupt+0x34/0x5c(CVE-2022-48926)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries/memhp: Fix access beyond end of drmem array\r\n\r\ndlpar_memory_remove_by_index() may access beyond the bounds of the\ndrmem lmb array when the LMB lookup fails to match an entry with the\ngiven DRC index. When the search fails, the cursor is left pointing to\n\u0026amp;drmem_info-\u0026gt;lmbs[drmem_info-\u0026gt;n_lmbs], which is one element past the\nlast valid entry in the array. The debug message at the end of the\nfunction then dereferences this pointer:\r\n\r\n        pr_debug(\u0026quot;Failed to hot-remove memory at %llx\\n\u0026quot;,\n                 lmb-\u0026gt;base_addr);\r\n\r\nThis was found by inspection and confirmed with KASAN:\r\n\r\n  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658\n  Read of size 8 at addr c000000364e97fd0 by task bash/949\r\n\r\n  dump_stack_lvl+0xa4/0xfc (unreliable)\n  print_report+0x214/0x63c\n  kasan_report+0x140/0x2e0\n  __asan_load8+0xa8/0xe0\n  dlpar_memory+0x298/0x1658\n  handle_dlpar_errorlog+0x130/0x1d0\n  dlpar_store+0x18c/0x3e0\n  kobj_attr_store+0x68/0xa0\n  sysfs_kf_write+0xc4/0x110\n  kernfs_fop_write_iter+0x26c/0x390\n  vfs_write+0x2d4/0x4e0\n  ksys_write+0xac/0x1a0\n  system_call_exception+0x268/0x530\n  system_call_vectored_common+0x15c/0x2ec\r\n\r\n  Allocated by task 1:\n   kasan_save_stack+0x48/0x80\n   kasan_set_track+0x34/0x50\n   kasan_save_alloc_info+0x34/0x50\n   __kasan_kmalloc+0xd0/0x120\n   __kmalloc+0x8c/0x320\n   kmalloc_array.constprop.0+0x48/0x5c\n   drmem_init+0x2a0/0x41c\n   do_one_initcall+0xe0/0x5c0\n   kernel_init_freeable+0x4ec/0x5a0\n   kernel_init+0x30/0x1e0\n   ret_from_kernel_user_thread+0x14/0x1c\r\n\r\n  The buggy address belongs to the object at c000000364e80000\n   which belongs to the cache kmalloc-128k of size 131072\n  The buggy address is located 0 bytes to the right of\n   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)\r\n\r\n  ==================================================================\n  pseries-hotplug-mem: Failed to hot-remove memory at 0\r\n\r\nLog failed lookups with a separate message and dereference the\ncursor only when it points to a valid entry.(CVE-2023-52451)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: scomp - fix req-\u0026gt;dst buffer overflow\r\n\r\nThe req-\u0026gt;dst buffer size should be checked before copying from the\nscomp_scratch-\u0026gt;dst to avoid req-\u0026gt;dst buffer overflow problem.(CVE-2023-52612)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: fix possible NULL pointer dereference caused by driver concurrency\r\n\r\nIn _dwc2_hcd_urb_enqueue(), \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; is executed without\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. In _dwc2_hcd_urb_dequeue():\r\n\r\n    spin_lock_irqsave(\u0026amp;hsotg-\u0026gt;lock, flags);\n    ...\n\tif (!urb-\u0026gt;hcpriv) {\n\t\tdev_dbg(hsotg-\u0026gt;dev, \u0026quot;## urb-\u0026gt;hcpriv is NULL ##\\n\u0026quot;);\n\t\tgoto out;\n\t}\n    rc = dwc2_hcd_urb_dequeue(hsotg, urb-\u0026gt;hcpriv); // Use urb-\u0026gt;hcpriv\n    ...\nout:\n    spin_unlock_irqrestore(\u0026amp;hsotg-\u0026gt;lock, flags);\r\n\r\nWhen _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are\nconcurrently executed, the NULL check of \u0026quot;urb-\u0026gt;hcpriv\u0026quot; can be executed\nbefore \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot;. After urb-\u0026gt;hcpriv is NULL, it can be used\nin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL\npointer dereference.\r\n\r\nThis possible bug is found by an experimental static analysis tool\ndeveloped by myself. This tool analyzes the locking APIs to extract\nfunction pairs that can be concurrently executed, and then analyzes the\ninstructions in the paired functions to identify possible concurrency\nbugs including data races and atomicity violations. The above possible\nbug is reported, when my tool analyzes the source code of Linux 6.5.\r\n\r\nTo fix this possible bug, \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; should be executed with\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. After using this patch, my tool never\nreports the possible bug, with the kernelconfiguration allyesconfig for\nx86_64. Because I have no associated hardware, I cannot test the patch\nin runtime testing, and just verify it according to the code logic.(CVE-2023-52855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()\r\n\r\nIn Google internal bug 265639009 we\u0026apos;ve received an (as yet) unreproducible\ncrash report from an aarch64 GKI 5.10.149-android13 running device.\r\n\r\nAFAICT the source code is at:\n  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10\r\n\r\nThe call stack is:\n  ncm_close() -\u0026gt; ncm_notify() -\u0026gt; ncm_do_notify()\nwith the crash at:\n  ncm_do_notify+0x98/0x270\nCode: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)\r\n\r\nWhich I believe disassembles to (I don\u0026apos;t know ARM assembly, but it looks sane enough to me...):\r\n\r\n  // halfword (16-bit) store presumably to event-\u0026gt;wLength (at offset 6 of struct usb_cdc_notification)\n  0B 0D 00 79    strh w11, [x8, #6]\r\n\r\n  // word (32-bit) store presumably to req-\u0026gt;Length (at offset 8 of struct usb_request)\n  6C 0A 00 B9    str  w12, [x19, #8]\r\n\r\n  // x10 (NULL) was read here from offset 0 of valid pointer x9\n  // IMHO we\u0026apos;re reading \u0026apos;cdev-\u0026gt;gadget\u0026apos; and getting NULL\n  // gadget is indeed at offset 0 of struct usb_composite_dev\n  2A 01 40 F9    ldr  x10, [x9]\r\n\r\n  // loading req-\u0026gt;buf pointer, which is at offset 0 of struct usb_request\n  69 02 40 F9    ldr  x9, [x19]\r\n\r\n  // x10 is null, crash, appears to be attempt to read cdev-\u0026gt;gadget-\u0026gt;max_speed\n  4B 5D 40 B9    ldr  w11, [x10, #0x5c]\r\n\r\nwhich seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:\r\n\r\n  event-\u0026gt;wLength = cpu_to_le16(8);\n  req-\u0026gt;length = NCM_STATUS_BYTECOUNT;\r\n\r\n  /* SPEED_CHANGE data is up/down speeds in bits/sec */\n  data = req-\u0026gt;buf + sizeof *event;\n  data[0] = cpu_to_le32(ncm_bitrate(cdev-\u0026gt;gadget));\r\n\r\nMy analysis of registers and NULL ptr deref crash offset\n  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)\nheavily suggests that the crash is due to \u0026apos;cdev-\u0026gt;gadget\u0026apos; being NULL when executing:\n  data[0] = cpu_to_le32(ncm_bitrate(cdev-\u0026gt;gadget));\nwhich calls:\n  ncm_bitrate(NULL)\nwhich then calls:\n  gadget_is_superspeed(NULL)\nwhich reads\n  ((struct usb_gadget *)NULL)-\u0026gt;max_speed\nand hits a panic.\r\n\r\nAFAICT, if I\u0026apos;m counting right, the offset of max_speed is indeed 0x5C.\n(remember there\u0026apos;s a GKI KABI reservation of 16 bytes in struct work_struct)\r\n\r\nIt\u0026apos;s not at all clear to me how this is all supposed to work...\nbut returning 0 seems much better than panic-ing...(CVE-2023-52894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Wait for out_urb\u0026apos;s completion in pn533_usb_send_frame()\r\n\r\nFix a use-after-free that occurs in hcd when in_urb sent from\npn533_usb_send_frame() is completed earlier than out_urb. Its callback\nfrees the skb data in pn533_send_async_complete() that is used as a\ntransfer buffer of out_urb. Wait before sending in_urb until the\ncallback of out_urb is called. To modify the callback of out_urb alone,\nseparate the complete function of out_urb and ack_urb.\r\n\r\nFound by a modified version of syzkaller.\r\n\r\nBUG: KASAN: use-after-free in dummy_timer\nCall Trace:\n memcpy (mm/kasan/shadow.c:65)\n dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)\n transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)\n dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)\n arch_static_branch (arch/x86/include/asm/jump_label.h:27)\n static_key_false (include/linux/jump_label.h:207)\n timer_expire_exit (include/trace/events/timer.h:127)\n call_timer_fn (kernel/time/timer.c:1475)\n expire_timers (kernel/time/timer.c:1519)\n __run_timers (kernel/time/timer.c:1790)\n run_timer_softirq (kernel/time/timer.c:1803)(CVE-2023-52907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\r\n\r\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\r\n\r\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\r\n\r\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\r\n\r\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\u0026quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset\u0026quot;)\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: fix call order in dmam_free_coherent\r\n\r\ndmam_free_coherent() frees a DMA allocation, which makes the\nfreed vaddr available for reuse, then calls devres_destroy()\nto remove and free the data structure used to track the DMA\nallocation. Between the two calls, it is possible for a\nconcurrent task to make an allocation with the same vaddr\nand add it to the devres list.\r\n\r\nIf this happens, there will be two entries in the devres list\nwith the same vaddr and devres_destroy() can free the wrong\nentry, triggering the WARN_ON() in dmam_match.\r\n\r\nFix by destroying the devres entry before freeing the DMA\nallocation.\r\n\r\n  kokonut //net/encryption\n    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: avoid BUG_ON() while continue reshape after reassembling\r\n\r\nCurrently, mdadm support --revert-reshape to abort the reshape while\nreassembling, as the test 07revert-grow. However, following BUG_ON()\ncan be triggerred by the test:\r\n\r\nkernel BUG at drivers/md/raid5.c:6278!\ninvalid opcode: 0000 [#1] PREEMPT SMP PTI\nirq event stamp: 158985\nCPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94\nRIP: 0010:reshape_request+0x3f1/0xe60\nCall Trace:\n \u0026lt;TASK\u0026gt;\n raid5_sync_request+0x43d/0x550\n md_do_sync+0xb7a/0x2110\n md_thread+0x294/0x2b0\n kthread+0x147/0x1c0\n ret_from_fork+0x59/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nRoot cause is that --revert-reshape update the raid_disks from 5 to 4,\nwhile reshape position is still set, and after reassembling the array,\nreshape position will be read from super block, then during reshape the\nchecking of \u0026apos;writepos\u0026apos; that is caculated by old reshape position will\nfail.\r\n\r\nFix this panic the easy way first, by converting the BUG_ON() to\nWARN_ON(), and stop the reshape if checkings fail.\r\n\r\nNoted that mdadm must fix --revert-shape as well, and probably md/raid\nshould enhance metadata validation as well, however this means\nreassemble will fail and there must be user tools to fix the wrong\nmetadata.(CVE-2024-43914)","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-2409.3.0.0294.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2409.3.0.0294.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48905"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52451"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52612"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52907"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42259"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42295"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42301"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43856"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43858"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43871"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43914"}],"database_specific":{"severity":"High"}}