kernel-4.18.0-553.136.1.el8_10
エラータID: AXSA:2026-1016:45
リリース日:
2026/06/29 Monday - 09:36
題名:
kernel-4.18.0-553.136.1.el8_10
影響のあるチャネル:
Asianux Server 8 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- kernel の bonding ドライバには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2026-31419)
- kernel の AMD 社のディスプレイコンポーネントの実装には、
ディスプレイストリーム圧縮の処理が不適切である問題があるため、
ローカルの攻撃者により、サービス拒否攻撃 (クラッシュの発生)、
および特権昇格を可能とする脆弱性が存在します。(CVE-2026-31488)
- kernel の Microsoft Azure Network Adapter ドライバには、メモリ
領域の解放後利用の問題があるため、ローカルの攻撃者により、サービス
拒否攻撃 (DoS)、および特権昇格を可能とする脆弱性が存在します。
(CVE-2026-43056)
- kernel の ALSA サブシステムには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-43279)
- kernel の ALSA aloop ドライバには、メモリ領域の解放後利用の問題
があるため、ローカルの攻撃者により、サービス拒否攻撃 (クラッシュの
発生)、および任意のコードの実行を可能とする脆弱性が存在します。
(CVE-2026-46090)
- kernel の NVMe over TCP の実装には、メモリ領域の二重解放の問題
があるため、ローカルの攻撃者により、メモリ破壊、およびサービス拒否
攻撃 (DoS) を可能とする脆弱性が存在します。(CVE-2026-46135)
- kernel の RDMA/mana コンポーネントには、メモリ領域の範囲外
書き込みの問題があるため、ローカルの攻撃者により、特権昇格、
およびサービス拒否攻撃 (DoS) を可能とする脆弱性が存在します。
(CVE-2026-46145)
- kernel の pedit サブシステムには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、特権昇格、およびサービス
拒否攻撃 (クラッシュの発生) を可能とする脆弱性が存在します。
(CVE-2026-46331)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2026-31419
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
CVE-2026-31488
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Do not skip unrelated mode changes in DSC validation Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Do not skip unrelated mode changes in DSC validation Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
CVE-2026-43056
In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in add_adev() error path If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls auxiliary_device_uninit(adev). The auxiliary device has its release callback set to adev_release(), which frees the containing struct mana_adev. Since adev is embedded in struct mana_adev, the subsequent fall-through to init_fail and access to adev->id may result in a use-after-free. Fix this by saving the allocated auxiliary device id in a local variable before calling auxiliary_device_add(), and use that saved id in the cleanup path after auxiliary_device_uninit().
In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in add_adev() error path If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls auxiliary_device_uninit(adev). The auxiliary device has its release callback set to adev_release(), which frees the containing struct mana_adev. Since adev is embedded in struct mana_adev, the subsequent fall-through to init_fail and access to adev->id may result in a use-after-free. Fix this by saving the allocated auxiliary device id in a local variable before calling auxiliary_device_add(), and use that saved id in the cleanup path after auxiliary_device_uninit().
CVE-2026-43279
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.
CVE-2026-46090
In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.
In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.
CVE-2026-46135
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.
CVE-2026-46145
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.
CVE-2026-46331
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-4.18.0-553.136.1.el8_10.src.rpm
MD5: 9114f6f616da39dd9eab95e385876333
SHA-256: 1612575ca208eb246ab50811e19a734bdc0641d4c046f4e2c5370c9ec1e1cadf
Size: 132.40 MB
Asianux Server 8 for x86_64
- bpftool-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: e69063d140a6ab70dc08c9f1e59a1f2b
SHA-256: a9d114f5ed0844c81c4f29eddd16f0704e5c0bfdc6a598648a1d1eba773cbd3e
Size: 11.32 MB - kernel-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 8ce5b813e714bcb5aced8d093a6485c5
SHA-256: e8214d1ee26837da78b941f7b39cc9ea8058d901753277eb6c7f3ab8ce68b69f
Size: 10.59 MB - kernel-abi-stablelists-4.18.0-553.136.1.el8_10.noarch.rpm
MD5: 927845429e65f5fd60c3b20637f97618
SHA-256: fd2e0c3127375ac19baac13117e65c75cca4d09d2a1e0d3915ffe9237aacfb91
Size: 10.61 MB - kernel-core-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: d7c3f45c21960c4c5014fe0aadbaddd8
SHA-256: 7ccbe2e1b8d49e438ff1a5c986c6cd26d90abbd10de72f8149dcd652bd19bab9
Size: 43.63 MB - kernel-cross-headers-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 27c7a1e400f0624193287c87625a1400
SHA-256: 06399573143ffd8a60820cb167239fc6f01a8002abcc00a25852323d13d19036
Size: 15.94 MB - kernel-debug-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 77513e2eb913a6def3386d154dbebfba
SHA-256: acdbe3c5a630832adfc1b696c655e7a65c14f7517eef39d30846514837a56668
Size: 10.59 MB - kernel-debug-core-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 3d31f16d2406f265050643bfe518104b
SHA-256: 9e65caec3a95e98d100d3cfed7bd0237384992f577b1d82ecbe29fbcbc30fcde
Size: 72.93 MB - kernel-debug-devel-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: ef4e74f5b67a7a839bf8118af8e46b26
SHA-256: 2d03767489a9a9b25280ca6760446d087e78489b70ae905531b250211dad7417
Size: 24.44 MB - kernel-debug-modules-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 65b60323b3a998823db621954988dea6
SHA-256: 2f135eb9d5dd354f273184c09fedaf56805a856fdb02d9bb0a5b9bc5b1f24224
Size: 66.07 MB - kernel-debug-modules-extra-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 446fde26ec992ad2c0a9ff7ec2e8bcec
SHA-256: 3f79116c7d60f0ebb7d54497a8d7ed0b652538ee43122f35cda2ca0cc0b543f0
Size: 11.97 MB - kernel-devel-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 0ef372076ed2b111da5af116300a2692
SHA-256: 3cfe6d30c46ba7f072eede388128d3df89a25682078e21b8ea9b6200cb477a8b
Size: 24.24 MB - kernel-doc-4.18.0-553.136.1.el8_10.noarch.rpm
MD5: b2c5160122ce731c815d48783c86cff7
SHA-256: 97e4d4cb1f9d9a7fedaf9f180492ec713cd184fadf301a1075b1d4a4d93cd2d2
Size: 28.46 MB - kernel-headers-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: c1c6fb719c1ce1ae7a09e747d72ab2df
SHA-256: 6d08e70d56d65ab683469ef5b869502496defc3f0d7c57275f83ec4af9db76ad
Size: 11.94 MB - kernel-modules-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 7b762df0524e7fda5c5446559b942195
SHA-256: 0afe801b9673fe8c8f822076dfc3efbbf8adf80808f32b16b9d421a965690aca
Size: 36.44 MB - kernel-modules-extra-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 0f5e0420e1811752a24cbe0a6c76ecae
SHA-256: 663794c7533387b0f791f25f66c89c6c1e39a989244c0af7ba706419fda2ed98
Size: 11.28 MB - kernel-tools-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: d0b1805ac7727e7eeaa7ac40e6d3afaa
SHA-256: 088f30f2f414d474148dbdea1b02b46580a5eb9dfcd7011a198d5d72897c531d
Size: 10.81 MB - kernel-tools-libs-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 6e6bfbc8c97acab8d2131d1fe0665f62
SHA-256: 369d3d8a4c0a81813a3713bb1b43f3ecd761eddfb0529214c27a8964c4dd255f
Size: 10.60 MB - kernel-tools-libs-devel-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 6316291366931dc0a5a37325d54e9528
SHA-256: cb5575346be238bf3f4919f1fe50b2676419b3e2ffd89d3c1462a90ac85b2a72
Size: 10.59 MB - perf-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 4958bcb968a27464aec21b57536dbf16
SHA-256: 296a525bfec14c3b85779cbe74f629bf0b25bb73d5580e6ace209419237dbb22
Size: 12.91 MB - python3-perf-4.18.0-553.136.1.el8_10.x86_64.rpm
MD5: 8d5dfb1c920b08379007354a6cfa6d14
SHA-256: c5acd3d8106b23dc8a3ff289fa7219eed6d8a68b9a5714d241d194a8825ec399
Size: 10.72 MB
English