kernel-3.10.0-1160.119.1.0.8.el7.AXS7
エラータID: AXSA:2025-9625:10
リリース日:
2025/02/05 Wednesday - 18:02
題名:
kernel-3.10.0-1160.119.1.0.8.el7.AXS7
影響のあるチャネル:
Asianux Server 7 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- btrfs ファイルシステムの dev-replace 機能の
fs/btrfs/dev-replace.c には、デバイス名の検証処理の
不備に起因したメモリ領域の範囲外読み取りの問題がある
ため、ローカルの攻撃者により、サービス拒否攻撃を可能
とする脆弱性が存在します。(CVE-2024-26791)
- drivers/media/dvb-core/dvbdev.c の
dvb_register_device() 関数には、メモリ領域の解放後
利用の問題があるため、ローカルの攻撃者により、
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-27043)
- arch/x86/kvm/svm/nested.c の
nested_svm_get_tdp_pdptr() 関数には、メモリの境域外
読み取りを引き起こす問題があるため、ローカルの攻撃者
により、ネストされた VM を介して、サービス拒否攻撃を
可能とする脆弱性が存在します。(CVE-2024-50115)
- net/sched/sch_api.c の qdisc_tree_reduce_backlog()
関数には、判定条件の誤りに起因したメモリ領域の解放後
利用の問題があるため、ローカルの攻撃者により、情報の
漏洩、およびサービス拒否攻撃を可能とする脆弱性が存在
します。(CVE-2024-53057)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2024-26791
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
CVE-2024-27043
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.
CVE-2024-50115
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.
CVE-2024-53057
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
追加情報:
N/A
ダウンロード:
Asianux Server 7 for x86_64
- bpftool-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 8293d4d5c1544bf7367db09f028964db
SHA-256: 0ac97e642a250c1d936ad8561faa19029e202140f34811d9c9ec722d46b2e205
Size: 8.54 MB - kernel-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 401f3dc301dd39fe67f0a3a8e8f7e4fc
SHA-256: 03cc590cd2d6a11089d6c9f5b8ff1b8a164218a73cf0de2cc094ad2c311a0088
Size: 51.75 MB - kernel-abi-whitelists-3.10.0-1160.119.1.0.8.el7.AXS7.noarch.rpm
MD5: 3dba0be0a34ab3e02c4047342af1cf99
SHA-256: 1023c4e92c04bb78de2f9901730fe3665000445aa4228463d3d919b0150f3bab
Size: 8.11 MB - kernel-debug-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 8eeae78d036e5b0c86b917089634c542
SHA-256: 27aa8aeadd53cb8e22e5eb58961e90ef5a48d4c54e180f8dadccb15f5d4cc3c8
Size: 54.05 MB - kernel-debug-devel-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: df22ba1a9f3a9bc3c894462207548810
SHA-256: 13f40e8ed3322800cfb1207cb0fdebfaa6e0c9b44d4a2dbe40cf6678077c0de0
Size: 18.14 MB - kernel-devel-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 6c36d512745af34eaf125297e537b9c9
SHA-256: 862a3c47be29a8294bdd63526c49a1d570c5d2e6049a550da77ae1ffd625f7ad
Size: 18.07 MB - kernel-doc-3.10.0-1160.119.1.0.8.el7.AXS7.noarch.rpm
MD5: c9681827dbaa5c796c100cab6e63c2d7
SHA-256: 80ae28d06ce3832edf9069e63df2f07c8b29717ad03268568715399167c30ef1
Size: 19.58 MB - kernel-headers-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 1eba3442c056ccc71ee9391bc0741d59
SHA-256: 14a3ec23c507ace7021adf4b83a60faced19e4b1dd03e3bb73a3b545ae381965
Size: 9.10 MB - kernel-tools-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 7089ce4a98ebffc56613dd6417b364ce
SHA-256: 37f6d98b017900126f8472fb20afe05644aa567717d0a14884611450588c15e0
Size: 8.21 MB - kernel-tools-libs-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: f30d30b251f38e910031e71a8d3a45f6
SHA-256: af77dc1085d6b2c472f5399babc4f66441cfa004094c2cb80d9df32e6ba1e4c9
Size: 8.10 MB - perf-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 08ffc471c8d2e8515d4adf7ebdd0f255
SHA-256: 8670c2039969bd6cae5902ae4df7be572de8337d9a21d228beaff93ba01a3119
Size: 9.75 MB - python-perf-3.10.0-1160.119.1.0.8.el7.AXS7.x86_64.rpm
MD5: 8bfea15bea3e0b802375dd5b86a61f8d
SHA-256: fdbcb5bf5bed33eba825c2b369c6bac8a6810b942595ee7a6cb1d79b7839be8a
Size: 8.20 MB