kernel-5.14.0-503.16.1.el9_5
エラータID: AXSA:2025-9539:03
リリース日:
2025/01/15 Wednesday - 12:04
題名:
kernel-5.14.0-503.16.1.el9_5
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
Moderate
Description:
以下項目について対処しました。
[Security Fix]
- net/smc/smc_diag.c の __smc_diag_dump() 関数には、
NULL ポインタデリファレンスの問題があるため、ローカル
の攻撃者により、SMC-D 接続のダンプの採取を介して、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-26615)
- block/bio-integrity.c の bio_integrity_prep()
関数には、整合性にチェックに用いるバッファー領域を
ゼロクリアせずに確保していることに起因して、カーネル
空間のメモリ領域の内容がメディアに書き出されてしまう
問題があるため、ローカルの攻撃者により、情報の漏洩を
可能とする脆弱性が存在します。(CVE-2024-43854)
- drivers/iommu/io-pgfault.c の
iommu_report_device_fault() 関数には、エラー発生時
の復帰処理が欠落しているため、ローカルの攻撃者により、
サービス拒否攻撃 (クラッシュの発生) を可能とする脆弱性
が存在します。(CVE-2024-44994)
- net/netfilter/nf_flow_table_offload.c の
nf_flow_offload_tuple() 関数には、extack データの
初期化処理が欠落しているため、ローカルの攻撃者により、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-45018)
- SELinux および smack の実装には、inode_setsecctx
フック処理において権限のチェックを迂回できてしまう問題
があるため、ローカルの攻撃者により、root squash が
有効化された NFS ファイルシステム上での不正な
セキュリティラベルの変更と、これに起因するデータの改竄
等を可能とする脆弱性が存在します。(CVE-2024-46695)
- net/core/dev.c の qdisc_pkt_len_init() 関数には、
ヘッダー長のチェック処理の欠落に起因したアンダーフロー
の問題があるため、ローカルの攻撃者より、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-49949)
- net/netfilter/nft_payload.c の
nft_payload_set_eval() 関数には、ソケットバッファの
サイズよりも算出したデータ長が大きい場合、意図しない
警告メッセージを出力してしまう問題があるため、ローカル
の攻撃者により、サービス拒否攻撃を可能とする脆弱性が
存在します。(CVE-2024-50251)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn->rmb_desc. So fix it by checking before dump.
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d
CVE-2024-43854
In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes.
In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes.
CVE-2024-44994
In the Linux kernel, the following vulnerability has been resolved: iommu: Restore lost return in iommu_report_device_fault() When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return. Instead the return was accidently deleted which results in trying to process the fault and an eventual crash. Deleting the return was a typo, put it back.
In the Linux kernel, the following vulnerability has been resolved: iommu: Restore lost return in iommu_report_device_fault() When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return. Instead the return was accidently deleted which results in trying to process the fault and an eventual crash. Deleting the return was a typo, put it back.
CVE-2024-45018
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload.
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload.
CVE-2024-46695
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.
CVE-2024-49949
In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---
In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---
CVE-2024-50251
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-503.16.1.el9_5.src.rpm
MD5: b1f5a53f63bf59ac5f2748827278f03f
SHA-256: d37877f1d03f3abf031f518c4c9757976a631bab2dd9971d0e18f82f512bf951
Size: 141.83 MB
Asianux Server 9 for x86_64
- bpftool-7.4.0-503.16.1.el9_5.x86_64.rpm
MD5: 67a97986eea2803904d164dcbbd9aac9
SHA-256: 498994e60db863fa1206e0c7ef999118743ceb42541ffb812407bdea272741cf
Size: 2.78 MB - kernel-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: c1fb06f48681790b7e472733118d8375
SHA-256: dba0e4144cf07412b6c48236f3bc1418d4827c81f19897fe3cbad23fa0f76403
Size: 2.01 MB - kernel-abi-stablelists-5.14.0-503.16.1.el9_5.noarch.rpm
MD5: 4e4e034c330006a487b7550a6cd357f6
SHA-256: 80df8d3cf20d72fc646df143effb5136871172aaae84b39ad63a0cc5f984d5d5
Size: 2.03 MB - kernel-core-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: d988579ee553e321da4e071b5d9e6f53
SHA-256: 237d2d916fe79e69f5e6295d6728fc70e87c771b86e50552df341ca7c0354bd5
Size: 17.63 MB - kernel-cross-headers-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 0f975bcefd85b4b05c18f99bdbe379c9
SHA-256: 3cc057589b2259f2b67e1aabee7a8617e2008471aa959a9d891b40a9773ff1c2
Size: 8.76 MB - kernel-debug-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 4efaad1d1665499e8676ad2b2cee38ab
SHA-256: dd0afdd934e2e0c27fe2a2278aef32ef2e67bb51625416158300df7a857dea23
Size: 2.01 MB - kernel-debug-core-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 7fcca9ea857cab6b3bb6cb52606cc4ad
SHA-256: 3d0cbbbb42054e7c76b77ec2592bee118bed1f04593f4c4324f2b7e6872d1794
Size: 30.69 MB - kernel-debug-devel-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 0f708e70643bbdeb2e21ce91df16ef62
SHA-256: da76a46ec6cd116b74457c01d250dcb9d5c3f3b81b3a25fc690a752f92a09323
Size: 21.74 MB - kernel-debug-devel-matched-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: de148c8abf9e54dd839da723ad080c6e
SHA-256: b02c936e198b65b44507369d7470964532e2a2ceddb3813f27b258defa32f1d1
Size: 2.01 MB - kernel-debug-modules-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 15383b13033232081413ea2df5b96754
SHA-256: 2c4df96042c975e0e376281b7c445016b2b1e7f449f61d46b6a365ce77a968bb
Size: 62.66 MB - kernel-debug-modules-core-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: f535ce111fcfb0b93229f29c50e685bb
SHA-256: 4219f2747b184b82d6e22a2c362a4696e54e2cb17d4eacf07ad2130e391dc8b3
Size: 47.96 MB - kernel-debug-modules-extra-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: f4b70124ccc982da6bcbf884d17c7aa8
SHA-256: 26500ec3ead6f655bda165d5d7e6ba7ed0ee55595345337dc58aa6ed190ec2cf
Size: 2.87 MB - kernel-debug-uki-virt-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: be168b9d7da2f90ecdd6edc38bb74f06
SHA-256: 52c863d26011885294d06bd6fd8d95248a901dcd9349d2827d6496889d363f2b
Size: 81.28 MB - kernel-devel-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 868f7b7a2d42a51b2fc23686babcbbfe
SHA-256: ecd7740bdbf33e56961936a23ab63ccc1742f8c03e311a953c6b60cc7057f92f
Size: 21.55 MB - kernel-devel-matched-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 7a9a691b7d5fece57d1b2cab967762dc
SHA-256: b3c64331a714ceffc993d0f872beb1e8def58730015305caa7c6bea167570eb6
Size: 2.01 MB - kernel-doc-5.14.0-503.16.1.el9_5.noarch.rpm
MD5: dc14bc221331fb13b87123893322bcd8
SHA-256: 2c867d01932edc4fc4360fd94591daeac2fb9538e2b1723f5a8c4d70f565bd00
Size: 37.41 MB - kernel-headers-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 1607f07af1a250f69753a7a822af3fb8
SHA-256: 2c9ae59e7c43dfbe52b98ddd2fd5f14684661da606d6d5a0472d5f2ec9b0ce31
Size: 3.72 MB - kernel-modules-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 29c26e639dc2a08699f58eebb6ace510
SHA-256: 7009dde1a78ffc6dd9c60d546691cc0ade70cd1c4564369def37856ef2df162a
Size: 36.55 MB - kernel-modules-core-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 5fe568c89502b713f46288e3921a5d03
SHA-256: 4d6260305ed3de1ce63eaf6450bcbb7226195da700d41bae69f983b58d7af533
Size: 30.42 MB - kernel-modules-extra-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 6ac2d2bceab9a7c0a56e952dca594777
SHA-256: 741d0a9bf738b033568f0160c6570c35a0b1bf975392472cf46fa0dad1336bd4
Size: 2.48 MB - kernel-tools-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 9595a66c1ddabe8efb1385c8e5bde5c8
SHA-256: 10133f17ce1002ea5a7bb24c6d1f1aac92d1a81bd89f3cd325fa4a1d73af2901
Size: 2.28 MB - kernel-tools-libs-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 8ad719582552455c0e1fdc5d42ad3108
SHA-256: 3ed3c715731cc00a96ed5f732671e6b6567a0559c68fb724beef50820a86273b
Size: 2.03 MB - kernel-tools-libs-devel-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 120c97e7868cdca921d321609aa792b9
SHA-256: ce39d0dae8120531970aeb91f0b60b0d5053da6fd3580f593ce03b3ca16131b6
Size: 2.02 MB - kernel-uki-virt-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 550970f95b28282142515352acbd18d4
SHA-256: a560dd12d54960f54ff647318e58c0a8cf6d1a6efe50de931cb7baedd0ffce57
Size: 60.46 MB - kernel-uki-virt-addons-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: b2111a80991b44fe4fe25ba06f12081a
SHA-256: c4fffc74b0107ec63a51e6c1f619d1f66ea5392186e0b6d2e30d2fe0e3b03a62
Size: 2.03 MB - libperf-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 62ac471b09ecd4938fb8642693aa4176
SHA-256: 75e2f1a14625074e6dcf8655325120871623e9d262b6273cff00f564f72e6651
Size: 2.03 MB - perf-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 4b9e8547819e6caeec517908dbd37d6f
SHA-256: 2fbbdfa96505f4b9db682f85b3424bbb1fb85492342715f8dc5a217b1c7bf261
Size: 4.19 MB - python3-perf-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 5f0e290b4b8f7efc37e2dcbb47731752
SHA-256: cd9d1e76de9711778c4e1aa361ba9ad6fdefd1804e870c505f5e5ff2e98034e2
Size: 2.12 MB - rtla-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 09e7343d1cb60d7398d62d396ecb3038
SHA-256: 14f053f42cf09ce3f02ddc889180a12c8fe092f6bcd69682b6cbfa94f75a31e8
Size: 2.06 MB - rv-5.14.0-503.16.1.el9_5.x86_64.rpm
MD5: 6ba0ec6862c681574d4080400249bea0
SHA-256: 7a2e1ee292517862c44dd00a85815013f18f9c6982567f88d86567d5a0faa2e7
Size: 2.03 MB
English