kernel-4.18.0-553.156.1.el8_10
エラータID: AXSA:2026-1750:72
リリース日:
2026/09/03 Thursday - 17:03
題名:
kernel-4.18.0-553.156.1.el8_10
影響のあるチャネル:
Asianux Server 8 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- kernel の SLUB 機能には、不正なポインタへアクセスしてしまう
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃 (クラッシュの発生) を可能とする脆弱性が
存在します。(CVE-2025-39902)
- kernel の CAN ドライバには、ローカルの攻撃者により、
特権昇格を可能とする脆弱性が存在します。(CVE-2026-17523)
- kernel の DRM サブシステムには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、特権昇格を可能とする
脆弱性が存在します。(CVE-2026-43206)
- kernel の AMD CCP ドライバには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-53016)
- kernel の AMD ディスプレイドライバには、メモリ領域の範囲外
書き込みの問題があるため、ローカルの攻撃者により、任意のコード
の実行、およびサービス拒否攻撃 (システムのクラッシュ) を可能と
する脆弱性が存在します。(CVE-2026-53136)
- kernel の DRM サブシステムには、ヒープベースのバッファオーバー
フローの問題があるため、ローカルの攻撃者により、任意のコードの
実行、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-53329)
- kernel の AMD 社の GPU ドライバには、不正なポインタへアクセス
してしまう問題があるため、ローカルの攻撃者により、情報の漏洩、
および予期しないシステム動作の発生を可能とする脆弱性が存在します。
(CVE-2026-53374)
- kernel の DRM サブシステムには、不正なポインタへアクセスして
しまう問題があるため、ローカルの攻撃者により、情報の漏洩、データ
破壊、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-63879)
- kernel の Intel 社の i915 ドライバには、メモリ領域の解放後利用
の問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃 (システムのクラッシュ) を可能とする脆弱性
が存在します。(CVE-2026-63884)
- kernel の AMD ディスプレイドライバには、スタックベースのバッファ
オーバーフローの問題があるため、ローカルの攻撃者により、情報の漏洩、
データ破壊、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-64219)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2025-39902
In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.
In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.
CVE-2026-17523
A flaw was found in the Linux kernel in net/can/bcm.c in can: bcm, where an unprivileged local user can exploit this vulnerability to execute arbitrary code within the kernel, which leads to a local privilege escalation (LPE). This allows the attacker to gain root privileges and take full control of the affected system.
A flaw was found in the Linux kernel in net/can/bcm.c in can: bcm, where an unprivileged local user can exploit this vulnerability to execute arbitrary code within the kernel, which leads to a local privilege escalation (LPE). This allows the attacker to gain root privileges and take full control of the affected system.
CVE-2026-43206
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.
CVE-2026-53016
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.
CVE-2026-53136
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
CVE-2026-53329
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)
CVE-2026-53374
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
CVE-2026-63879
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_hmm_range_get_pages The notifier sequence must only be read once or otherwise we could work with invalid pages. While at it also fix the coding style, e.g. drop the pre-initialized return value and use the common define for 2G range. (cherry picked from commit c08972f555945cda57b0adb72272a37910153390)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_hmm_range_get_pages The notifier sequence must only be read once or otherwise we could work with invalid pages. While at it also fix the coding style, e.g. drop the pre-initialized return value and use the common define for 2G range. (cherry picked from commit c08972f555945cda57b0adb72272a37910153390)
CVE-2026-63884
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential UAF in TTM object purge TLDR: The bo->ttm object might be changed by calling ttm_bo_validate(), move casting it to an i915_tt object later to actually get the right pointer. A user reported hitting the following bug under heavy use on DG2: [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy) [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025 [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915] [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282 [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000 [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000 [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0 [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0 [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000 [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0 [26620.095612] PKRU: 55555554 [26620.095612] Call Trace: [26620.095615] <TASK> [26620.095615] i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ? preempt_count_add+0x64/0xa0 [26620.095673] ? _raw_spin_lock+0xe/0x30 [26620.095675] ? _raw_spin_unlock+0xd/0x30 [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ? init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ? alloc_debug_processing+0xd0/0x100 [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ? alloc_debug_processing+0xd0/0x100 [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ? __wake_up_sync_key+0x32/0x50 [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] Results from decode_stacktrace.sh pointed to dereference of a file pointer field of a i915 TTM page vector container associated with an object being purged on eviction. That path is taken when the object is marked as no longer needed. Code analysis revealed a possibility of the i915 TTM page vector container being replaced with a new instance inside a function that purges content of the object, should it be still busy. That function is called, indirectly via a more general function that changes the object's placement and caching policy, ---truncated---
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential UAF in TTM object purge TLDR: The bo->ttm object might be changed by calling ttm_bo_validate(), move casting it to an i915_tt object later to actually get the right pointer. A user reported hitting the following bug under heavy use on DG2: [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy) [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025 [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915] [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282 [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000 [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000 [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0 [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0 [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000 [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0 [26620.095612] PKRU: 55555554 [26620.095612] Call Trace: [26620.095615] <TASK> [26620.095615] i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ? preempt_count_add+0x64/0xa0 [26620.095673] ? _raw_spin_lock+0xe/0x30 [26620.095675] ? _raw_spin_unlock+0xd/0x30 [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ? init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ? alloc_debug_processing+0xd0/0x100 [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ? alloc_debug_processing+0xd0/0x100 [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ? __wake_up_sync_key+0x32/0x50 [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] Results from decode_stacktrace.sh pointed to dereference of a file pointer field of a i915 TTM page vector container associated with an object being purged on eviction. That path is taken when the object is marked as no longer needed. Code analysis revealed a possibility of the i915 TTM page vector container being replaced with a new instance inside a function that purges content of the object, should it be still busy. That function is called, indirectly via a more general function that changes the object's placement and caching policy, ---truncated---
CVE-2026-64219
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-4.18.0-553.156.1.el8_10.src.rpm
MD5: dea996de1ed06ae55e28978820282ff8
SHA-256: a1fe381ea15761129bb4a492953b26cd34927a1c8feceaf3c78f9e5ff90d46e1
Size: 132.44 MB
Asianux Server 8 for x86_64
- bpftool-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: b25a4189e0c1340fdcff944554e21fff
SHA-256: 1fb30beed9162ef7da663bcf81c43de8355989a3ec662d1bdecf0929b06b2ace
Size: 11.33 MB - kernel-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: b7cb7508a65b9b64c82265a8f1968dd2
SHA-256: 26b62f1f74e92b05ec4d6073a2eb5dd6391b9e45ceeee5fd7e8274c4be455230
Size: 10.61 MB - kernel-abi-stablelists-4.18.0-553.156.1.el8_10.noarch.rpm
MD5: 15ac36a69ca69308d7f95c86ba4f267e
SHA-256: 40dc1f60bbb6d2e32166e0f384533782114374bb69299aed3df289fdecdca384
Size: 10.62 MB - kernel-core-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: e11c6b103a015973c6fce20d399dc0c5
SHA-256: 6e6652de4a1dcc46ffdb1e3b86fb00cfc44bb9037b21c9c4d7ccb0b2706bd8f7
Size: 43.65 MB - kernel-cross-headers-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 9dde442b4c841fffe1b91e9978414c18
SHA-256: ff4e2b247fc753120abeed5e59343262400a57d9a8639d246ee739c89929e0f6
Size: 15.95 MB - kernel-debug-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: eb1ae9cdef4163ea66745d263f686550
SHA-256: a631be2faa65c1d2cbe190e8c026b2aa920b1d2517d10ef3229a9b3f8e03ab0e
Size: 10.61 MB - kernel-debug-core-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: fb9f55a9ca19ca2515c6535275434e6a
SHA-256: 75ef558405f204f8b6d9b9aa42190f557c6739b2172ffed6b83c2547e70a6964
Size: 72.96 MB - kernel-debug-devel-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 933a0ecd7f0fcff46b53d7ddb0c3f2c0
SHA-256: 991223ec3d625f4692c5866bf6d55912904eb574ccf0cefc3dae1bc0c00bcdc0
Size: 24.46 MB - kernel-debug-modules-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 6b295af0a8f80aa980e2a706d9f84d41
SHA-256: 7aef70bc76e2a365ca1e3f6e6b8002206c5862d914115610b1006d8756488a72
Size: 66.11 MB - kernel-debug-modules-extra-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: f4b661ccb19672061d34cc4160467b1b
SHA-256: e9c67caeca23da16af4abd9693e1c2d821a3d353acb6feeeb7c2c8741dc92a6d
Size: 11.99 MB - kernel-devel-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 1dd825e027bfd97904749c206c049d77
SHA-256: e1b4adb168c89341da0da2e7e0f3f08a05ee021b377af3931219d91b04878fc4
Size: 24.26 MB - kernel-doc-4.18.0-553.156.1.el8_10.noarch.rpm
MD5: 4a4fca0758d09510dab4a90520495910
SHA-256: 6948a0c8692dce968dcc2c38a32b6ba44d62aa5028f979d0a2f1f2c7c535091b
Size: 28.48 MB - kernel-headers-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: a43f7c80efc2200ced74195fb432b575
SHA-256: e9aa103d86ff8706482be6ead5bed23569c9eba4643b2efa42348233e5fbbe59
Size: 11.96 MB - kernel-modules-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: ee9c3895b1dae9f9a68467d98262c6cc
SHA-256: 8cf1bad460aa6b0dfba59dad2dd66b16cc5a998a66c505af144cb755c352b075
Size: 36.45 MB - kernel-modules-extra-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: de231f79193570737567177b239d03ca
SHA-256: e1c88127c747eb22f9a7243dc4f5c558ffc3cb17b7b83e3a808a32f303ee5f9f
Size: 11.30 MB - kernel-tools-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: d1d143a167d8b82bcbb7a2c2e6f5a7bd
SHA-256: 15a05f5575a7b19739511c36529c15c61a1b32b8ff60cc3c98a5f1fff4268983
Size: 10.83 MB - kernel-tools-libs-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 6c2e7ab4d2f3f6796bceede7dbd82da7
SHA-256: bd1ae2c3ccedaa8144063b6fe932726e1b8b00243049fd068174bf4b2c2e5c39
Size: 10.62 MB - kernel-tools-libs-devel-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: d3eb2f49af769344715426bf564b4672
SHA-256: 89e07f798e6a1c70c58ccd1228e72a33156d4d416c5ccd0a065af5e7394179cd
Size: 10.61 MB - perf-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: 47d4e3da102603a45b5f7bdd0b3bfe3e
SHA-256: 887577a6794a4f55cb455483d89e8ab7ac47b3690fe7aa6ef5095162103230e1
Size: 12.93 MB - python3-perf-4.18.0-553.156.1.el8_10.x86_64.rpm
MD5: d37a2bcbee1b5e80bd6bc91a23585dd1
SHA-256: 70db7e22dc921f71c2f6079152a2e74c184cb25bb9bb29ea19cdcdf4c26894f9
Size: 10.73 MB
English