kernel-5.14.0-427.26.1.el9_4
エラータID: AXSA:2024-8593:22
リリース日:
2024/07/24 Wednesday - 15:12
題名:
kernel-5.14.0-427.26.1.el9_4
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c の
hns_dsaf_ge_srst_by_port() 関数には、ポートの値のチェック
処理漏れに起因した配列オーバーフローの問題があるため、
ローカルの攻撃者により、サービス拒否攻撃を可能とする
脆弱性が存在します。(CVE-2021-47548)
- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
の hclgevf_send_mbx_msg() 関数には、インスタンスレジスタ
のチェック処理漏れに起因したメモリ領域の解放後利用の問題
があるため、ローカルの攻撃者により、サービス拒否攻撃を
可能とする脆弱性が存在します。(CVE-2021-47596)
- VT 仮想ターミナルの drivers/tty/vt/vt.c の delete_char()
関数には、長い行を削除した際のメモリ領域の重複コピーに
起因するメモリ破壊の問題があるため、ローカルの攻撃者
により、細工されたコンソール内のデータの削除を介して、
情報の漏洩を可能とする脆弱性が存在します。
(CVE-2022-48627)
- can: j1939 には、稀にデッドロックの発生に至る問題がある
ため、ローカルの攻撃者が、サービス拒否攻撃を可能とする
脆弱性が存在します。(CVE-2023-52638)
- mm/migrate.c の numamigrate_isolate_page() 関数には、
wakeup_kswapd() 関数を呼び出す前の内部変数のチェック
処理が欠落しているため、ローカルの攻撃者より、サービス
拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-26783)
- MLX5 ネットワークデバイスドライバーの
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c の
mlx5e_txwqe_complete() 関数には、NULL ポインタ
デリファレンスの問題があるため、ローカルの攻撃者により、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-26858)
- Netfilter サブシステムには、トランザクションのタイムアウト
発生時の処理の欠陥に起因したメモリ領域の解放後利用の問題
があるため、ローカルの攻撃者により、特権昇格、および
サービス拒否攻撃 (クラッシュの発生) を可能とする脆弱性が
存在します。(CVE-2024-27397)
- drivers/nvme/host/core.c には、NVMe over RDMA を利用
している環境下でタグを割り当てる際にデッドロック状態が
発生してしまう問題があるため、ローカルの攻撃者により、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-27435)
- drivers/net/ethernet/amazon/ena/ena_netdev.c には、VF
リセット処理時の送信キュー内のデスクリプタの解放処理に
問題があるため、ローカルの攻撃者により、サービス拒否
攻撃 (クラッシュの発生) を可能とする脆弱性が存在します。
(CVE-2024-35958)
- net/ipv4/netfilter/nf_tproxy_ipv4.c の nf_tproxy_laddr4() 関数
には、デバイス上で IP アドレスが無効化されている場合の
チェック処理の欠落に起因した NULL ポインタデリファレンス
の問題があるため、ローカルの攻撃者により、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-36270)
- tipc には、メモリの解放後利用の問題があるため、隣接の
攻撃者により、エラーパスを介して、サービス拒否攻撃を
可能とする脆弱性が存在します。(CVE-2024-36886)
- tcp には、メモリの解放後利用の問題があるため、ローカル
の攻撃者により、巧妙なソケット操作を介して、サービス
拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-36904)
- drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c の
rvu_dbg_qsize_write() 関数には、ユーザー空間上のメモリ
領域の範囲外読み取りの問題があるため、ローカルの攻撃者
により、情報の漏洩を可能とする脆弱性が存在します。
(CVE-2024-36957)
- lib/test_hmm.c の dmirror_device_evict_chunk() 関数には、
物理メモリが不足している場合における NULL ポインタ
デリファレンスの問題があるため、ローカルの攻撃者により、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-38543)
- drivers/net/ethernet/realtek/r8169_main.c の
rtl8169_start_xmit() 関数には、送信リングバッファへの無効な
エントリの挿入と、これに伴う NULL ポインタデリファレンス
の問題があるため、ローカルの攻撃者により、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-38586)
- drivers/net/phy/micrel.c の lan8841_suspend() 関数には、
ptp ワークキューの処理に問題があるため、ローカルの攻撃者
により、サービス拒否攻撃 (クラッシュの発生) を可能とする
脆弱性が存在します。(CVE-2024-38593)
- blk-cgroup には、リスト破壊の問題があるため、ローカルの
攻撃者により、IOステータスのリセットを介して、サービス
拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-38663)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2021-47548
In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
CVE-2021-47596
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free.
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free.
CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]
CVE-2024-26783
In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 >
In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: >
CVE-2024-26858
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map Just simply reordering the functions mlx5e_ptp_metadata_map_put and mlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the tracking list being populated before the metadata map.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map Just simply reordering the functions mlx5e_ptp_metadata_map_put and mlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the tracking list being populated before the metadata map.
CVE-2024-27397
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.
CVE-2024-27435
In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
CVE-2024-35958
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix incorrect descriptor free behavior ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue. This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix incorrect descriptor free behavior ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue. This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.
CVE-2024-36270
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this.
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this.
CVE-2024-36886
In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---
In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace:
CVE-2024-36904
In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0
In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace:
CVE-2024-36957
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: avoid off-by-one read from userspace We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: avoid off-by-one read from userspace We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.
CVE-2024-38543
In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations.
In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations.
CVE-2024-38586
In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
CVE-2024-38593
In the Linux kernel, the following vulnerability has been resolved: net: micrel: Fix receiving the timestamp in the frame for lan8841 The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work.
In the Linux kernel, the following vulnerability has been resolved: net: micrel: Fix receiving the timestamp in the frame for lan8841 The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work.
CVE-2024-38663
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part.
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-427.26.1.el9_4.src.rpm
MD5: 37c3e11f235d83dd15feaa2171efe3c6
SHA-256: 50d7b7e3fbfd306e7850e46e63dca757f7212841e320407d1d3cbdcc8e783428
Size: 138.48 MB
Asianux Server 9 for x86_64
- bpftool-7.3.0-427.26.1.el9_4.x86_64.rpm
MD5: e256d1affbb0273bbc26394ff5d03622
SHA-256: 6925a9d1bdb46029da5a4664fc81a775ee66aa59097a8bafc1ce9c46a4b60537
Size: 5.83 MB - kernel-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 631470022c9e10e40c95738e2bbb1532
SHA-256: 59745441febea175e950bcc922435aa219b2a3bad99369eec4043cd7ea29da79
Size: 5.07 MB - kernel-abi-stablelists-5.14.0-427.26.1.el9_4.noarch.rpm
MD5: 7a130644531f2842a98d0abc19c675e6
SHA-256: c3c1e9562273d5b965e4fb424d4f8040b96b96e98c8c4938883dff34cbc8466f
Size: 5.08 MB - kernel-core-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 99d0b24b72f5f6365bd8c5b142d02af6
SHA-256: 7bc4e7cf61247725dc658fc2d1aa3441165bb09d33e33b1b749b8e657a66fda2
Size: 19.93 MB - kernel-cross-headers-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 73f668e401fdcb9db210f95510b080a7
SHA-256: b74c4bb9be1e14a816fa890d70d808756d5ecfb8fb542b516e400b516c2312d6
Size: 11.67 MB - kernel-debug-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 6df5b1b5e63d71fc75ad947cd9fcb6d4
SHA-256: 902979f6544d97ba4073d720e3eefe89c9d90f7b28b56e3aa6cb4309a898823f
Size: 5.07 MB - kernel-debug-core-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: e6f972bbbe82b3fd8922d1c63046e945
SHA-256: 749dec79076d56639eb7129bfef0964a4c73591e54fc8181302d67f3f28d6362
Size: 32.60 MB - kernel-debug-devel-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 0c388a3bc66bff2a66a37d054306fa04
SHA-256: 6d1c7a45ffbf250847ebc8070b0b961807c7dc21ae56ce4de7a2ca754966c0d3
Size: 24.53 MB - kernel-debug-devel-matched-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: b768ca9f67e75624a7ef4a788ed69663
SHA-256: b44c820b7d2717e54ec6f59a618ec85cb4cbb93ba1b9d130d4b775363543af35
Size: 5.07 MB - kernel-debug-modules-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 93e50ff59f5dd9a2a0087ec039240145
SHA-256: 237111675ac2afbd0964c42b1c0ac5ed9cb740acf9d60c8fd7cc23de4d1c703f
Size: 64.03 MB - kernel-debug-modules-core-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 64798be0be10a851fa367b6b4048147f
SHA-256: d54bdbcb0250b07480533a1741231d4160df774453de10660fed46df39493320
Size: 50.20 MB - kernel-debug-modules-extra-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 566e25a792b7d253d3d401c965ada105
SHA-256: 29d2e6d170141ba3cc38e9944b1b5a52cb9975e1624df8abaadcdbb584ccc504
Size: 5.90 MB - kernel-debug-uki-virt-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 3dd2da728930db8b11899efff04edf3f
SHA-256: 7689dee4a7d65e786015bd73f7ba7fddc608ff417b962f926898c609b1050f1c
Size: 81.90 MB - kernel-devel-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 229e64cb51adb7ec443aa2f726f2dc92
SHA-256: f4845e9f5ccb6d118ecab19c61151c5143a73518f987692c08fbcf3d9d1cff2f
Size: 24.36 MB - kernel-devel-matched-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 8bdb0dfa8e1dc1438676f7baa55fd33a
SHA-256: dde0af2b5a585000015eb9e2f5178bd53153502288206516e4d5d18ee37790d2
Size: 5.07 MB - kernel-doc-5.14.0-427.26.1.el9_4.noarch.rpm
MD5: 605212159a2382e5a1b0ac8e96c06e1b
SHA-256: 3b30749296f47575ee34aad42630081444f9d23906a6d105f4b2ea712d50c577
Size: 38.50 MB - kernel-headers-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: a2db2df99bb1db0e1ef813a148892aff
SHA-256: ee9cce27f9f23a1ec1b2628202d419759f2cbc542c5cb67c5e1792097509229e
Size: 6.74 MB - kernel-modules-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: a4e0352e7a3fa73c2ce9e45188427159
SHA-256: 7e1d08059b8c3c597e360806661f0c809907c1766e057b6d62910e1402a36a46
Size: 38.68 MB - kernel-modules-core-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 6e5cdcdec67b9af3af1fbd397deb1b67
SHA-256: c9749451d35e22ea8334bc0ca79401210e62d6ef784289dd81189bb8e901c232
Size: 32.86 MB - kernel-modules-extra-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 05d1d76366ba4033d334d8235a302fba
SHA-256: 73cffdd54e93cdf4473001c5182a7161e2b35073447c4b09063a58aee8e5b4ff
Size: 5.52 MB - kernel-tools-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 364feddd19e031a1b4df6d84ac4b01b2
SHA-256: 9139665e22b9258429d8353adc77d0471ef2a3e502bee2d513df3e2e3de211c7
Size: 5.32 MB - kernel-tools-libs-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: e4b2bf08cf463ddaf5e3bae4b28faf8d
SHA-256: 29b0f1a37b348fbb4ccfb5fb3589c554168aabc52d7c367a50e60bf5ebfdae60
Size: 5.08 MB - kernel-tools-libs-devel-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 2b77b31b74a6c21f4dd135306d7a2c56
SHA-256: 92514ecd0525d23fb5da4d8d5ad82348c250ec1e9db5097617d5902567c1876d
Size: 5.07 MB - kernel-uki-virt-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 60c8bce5afa7bff2dd1832abe1f4358e
SHA-256: 4253f0f268db6bd9742bce9897942c865b8be615196b79d0adb23a354dd69e91
Size: 61.80 MB - libperf-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: d18ec7f465f3e5ff4c87b6906a39dae8
SHA-256: c9cce6e6a2dd138015eba6f7516bcfe9e078cf15d8a50ebcd38ae0f58ab4d38b
Size: 5.09 MB - perf-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 9adb9cc9377def0e87e23c096897b7a2
SHA-256: 1412aa27244f6353825d8401ca5f004be9a9ae330ffbd749dd52cbfc0faa9669
Size: 7.09 MB - python3-perf-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 53184893708ebd64cf6ba304b4492d75
SHA-256: 3978446be81c53b8dcac8d48ce7c39d2fde524437c5fa238e4041fcfd720ca50
Size: 5.16 MB - rtla-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: 3c0242bffd90ce5e87f19916d6595a73
SHA-256: 708f12fddad105ecd9a386c49c961992369a1502fe160b45b942d094465b3dc5
Size: 5.11 MB - rv-5.14.0-427.26.1.el9_4.x86_64.rpm
MD5: a60dbb7d5536e804b8cceb5b76031c44
SHA-256: 5eeb2486287d083e34841955946f626b1faea0a5dc10f542b9a66263c56b5728
Size: 5.08 MB
English