{"id":"OESA-2024-2536","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()  Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace:  ieee80211_do_stop()  ...  spin_lock_irqsave(&local->queue_stop_reason_lock, flags)  ...  ieee80211_free_txskb()   ieee80211_report_used_skb()    ieee80211_report_ack_skb()     cfg80211_mgmt_tx_status_ext()      nl80211_frame_tx_status()       genlmsg_multicast_netns()        genlmsg_multicast_netns_filtered()         nlmsg_multicast_filtered()   netlink_broadcast_filtered()    do_one_broadcast()     netlink_broadcast_deliver()      __netlink_sendskb()       netlink_deliver_tap()        __netlink_deliver_tap_skb()         dev_queue_xmit()          __dev_queue_xmit() ; with IRQS disabled  ...  spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)  issues the warning (as reported by syzbot reproducer):  WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120  Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)\n\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fix helper writes to read-only maps  Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments.  In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds.  The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway.  However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).  MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val.(CVE-2024-49861)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before try to access it  [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags  [WHAT & HOW] "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference.  This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)\n\nIn the Linux kernel, the following vulnerability has been resolved:  net: stmmac: Fix zero-division error when disabling tc cbs  The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "port_transmit_rate_kbps" to be set to a value of 0, which is then passed to the "div_s64" function when tc-cbs is disabled. This leads to a zero-division error.  When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)\n\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()  A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)\n\nIn the Linux kernel, the following vulnerability has been resolved:  net: sched: fix use-after-free in taprio_change()  In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.(CVE-2024-50127)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA  Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning:  [   13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [   13.320038] Call Trace: [   13.320173]  hgsmi_update_pointer_shape [vboxvideo] [   13.320184]  vbox_cursor_atomic_update [vboxvideo]  Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/radeon: Fix encoder->possible_clones  Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly.  This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ...  (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)\n\nIn the Linux kernel, the following vulnerability has been resolved:  posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()  If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource.  However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that.  [pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:  USB: serial: io_edgeport: fix use after free in debug printk  The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer.  Store the "dev" pointer at the start of the function to avoid this issue.(CVE-2024-50267)\n\nIn the Linux kernel, the following vulnerability has been resolved:  dm cache: fix potential out-of-bounds access on the first resume  Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue.  Reproduce steps:  1. prepare component devices:  dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct  2. load a cache table of 512 cache blocks, and deliberately expand the    fast device before resuming the cache, making the in-core data    structures inadequate.  dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache  3. suspend the cache to write out the in-core dirty bitset and hint    array, leading to out-of-bounds access to the dirty bitset at offset    0x40:  dmsetup suspend cache  KASAN reports:    BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80   Read of size 8 at addr ffffc90000085040 by task dmsetup/90    (...snip...)   The buggy address belongs to the virtual mapping at    [ffffc90000085000, ffffc90000087000) created by:    cache_ctr+0x176a/0x35f0    (...snip...)   Memory state around the buggy address:    ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8                                              ^    ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8  Fix by checking the size change on the first resume.(CVE-2024-50278)\n\nIn the Linux kernel, the following vulnerability has been resolved:  media: cx24116: prevent overflows on SNR calculus  as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers.  Prevent that.(CVE-2024-50290)\n\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove  In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [    4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [    4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [    5.096577] Call trace: [    5.099099]  dma_release_channel+0x24/0x100 [    5.103235]  stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [    5.109494]  stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]  To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)\n\nIn the Linux kernel, the following vulnerability has been resolved:  security/keys: fix slab-out-of-bounds in key_task_permission  KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362  CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:  __dump_stack lib/dump_stack.c:82 [inline]  dump_stack+0x107/0x167 lib/dump_stack.c:123  print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400  __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560  kasan_report+0x3a/0x50 mm/kasan/report.c:585  __kuid_val include/linux/uidgid.h:36 [inline]  uid_eq include/linux/uidgid.h:63 [inline]  key_task_permission+0x394/0x410 security/keys/permission.c:54  search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793  This issue was also reported by syzbot.  It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the    pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1.  The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the    slots in a node(below tag ascend_to_node), if the slot pointer is meta    and node->back_pointer != NULL(it means a root), it will proceed to    descend_to_node. However, there is an exception. If node is the root,    and one of the slots points to a shortcut, it will be treated as a    keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.    However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as    ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT    has keys with hashes that are not similar (e.g. slot 0) and it splits    NODE A without using a shortcut. When NODE A is filled with keys that    all hashes are xxe6, the keys are similar, NODE A will split with a    shortcut. Finally, it forms the tree as shown below, where slot 6 points    to a shortcut.                        NODE A               +------>+---+       ROOT    |       | 0 | xxe6       +---+   |       +---+  xxxx | 0 | shortcut  :   : xxe6       +---+   |       +---+  xxe6 :   :   |       |   | xxe6       +---+   |       +---+       | 6 |---+       :   : xxe6       +---+           +---+  xxe6 :   :           | f | xxe6       +---+           +---+  xxe6 | f |       +---+  4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,    it may be mistakenly transferred to a key*, leading to a read    out-of-bounds read.  To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.  [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/  [jarkko: tweaked the commit message a bit to have an appropriate closes  tag.](CVE-2024-50301)\n\nIn the Linux kernel, the following vulnerability has been resolved:  HID: core: zero-initialize the report buffer  Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)\n\nIn the Linux kernel, the following vulnerability has been resolved:  media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format  This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)\n\nIn the Linux kernel, the following vulnerability has been resolved:  vp_vdpa: fix id_table array not null terminated error  Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)\n\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: uncache inode which has failed entering the group  Syzbot has reported the following BUG:  kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace:  <TASK>  ? __die_body+0x5f/0xb0  ? die+0x9e/0xc0  ? do_trap+0x15a/0x3a0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? do_error_trap+0x1dc/0x2c0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? __pfx_do_error_trap+0x10/0x10  ? handle_invalid_op+0x34/0x40  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? exc_invalid_op+0x38/0x50  ? asm_exc_invalid_op+0x1a/0x20  ? ocfs2_set_new_buffer_uptodate+0x2e/0x160  ? ocfs2_set_new_buffer_uptodate+0x144/0x160  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ocfs2_group_add+0x39f/0x15a0  ? __pfx_ocfs2_group_add+0x10/0x10  ? __pfx_lock_acquire+0x10/0x10  ? mnt_get_write_access+0x68/0x2b0  ? __pfx_lock_release+0x10/0x10  ? rcu_read_lock_any_held+0xb7/0x160  ? __pfx_rcu_read_lock_any_held+0x10/0x10  ? smack_log+0x123/0x540  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x226/0x2b0  ocfs2_ioctl+0x65e/0x7d0  ? __pfx_ocfs2_ioctl+0x10/0x10  ? smack_file_ioctl+0x29e/0x3a0  ? __pfx_smack_file_ioctl+0x10/0x10  ? lockdep_hardirqs_on_prepare+0x43d/0x780  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10  ? __pfx_ocfs2_ioctl+0x10/0x10  __se_sys_ioctl+0xfb/0x170  do_syscall_64+0xf3/0x230  entry_SYSCALL_64_after_hwframe+0x77/0x7f ...  </TASK>  When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.(CVE-2024-53112)\n\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: sync_linked_regs() must preserve subreg_def  Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set:    0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns   1: r0 &= 0x7fffffff       after verifier   r0 &= 0x7fffffff   2: w1 = w0                rewrites         w1 = w0   3: if w0 < 10 goto +0     -------------->  r11 = 0x2f5674a6     (r)   4: r1 >>= 32                               r11 <<= 32           (r)   5: r0 = r1                                 r1 |= r11            (r)   6: exit;                                   if w0 < 0xa goto pc+0                                              r1 >>= 32                                              r0 = r1                                              exit  (or zero extension of w1 at (2) is missing for architectures that  require zero extension for upper register half).  The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2)   for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random   value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)\n\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint  When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled.  This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure.  In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions.  However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above.  Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.(CVE-2024-53130)","modified":"2026-08-18T01:31:52.992244065Z","published":"2024-12-13T11:08:01Z","upstream":["CVE-2024-47713","CVE-2024-49861","CVE-2024-49906","CVE-2024-49923","CVE-2024-49977","CVE-2024-50103","CVE-2024-50127","CVE-2024-50134","CVE-2024-50201","CVE-2024-50210","CVE-2024-50267","CVE-2024-50278","CVE-2024-50290","CVE-2024-50292","CVE-2024-50301","CVE-2024-50302","CVE-2024-53104","CVE-2024-53110","CVE-2024-53112","CVE-2024-53125","CVE-2024-53130"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2536"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47713"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49906"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49923"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50201"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50210"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50267"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50278"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50290"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50301"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53110"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53130"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-136.105.0.186.oe2203sp1"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-debugsource-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-devel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-headers-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-source-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-tools-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-tools-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","kernel-tools-devel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","perf-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","python3-perf-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm","python3-perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm"],"src":["kernel-5.10.0-136.105.0.186.oe2203sp1.src.rpm"],"x86_64":["kernel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-debugsource-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-devel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-headers-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-source-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-tools-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-tools-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","kernel-tools-devel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","perf-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","python3-perf-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm","python3-perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2024-2536.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}