kernel-4.18.0-553.37.1.el8_10
エラータID: AXSA:2025-9659:11
リリース日:
2025/02/14 Friday - 10:35
題名:
kernel-4.18.0-553.37.1.el8_10
影響のあるチャネル:
Asianux Server 8 for x86_64
Severity:
Moderate
Description:
以下項目について対処しました。
[Security Fix]
- drivers/scsi/hosts.c の scsi_host_dev_release() 関数には、
hostdir_rm() 関数を重複して呼び出してしまうことに起因
して意図しない警告メッセージが出力されてしまう問題が
あるため、ローカルの攻撃者により、サービス拒否攻撃を
可能とする脆弱性が存在します。(CVE-2024-26935)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2024-26935
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.
CVE-2024-50275
In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-4.18.0-553.37.1.el8_10.src.rpm
MD5: 55c930d879c16cd06d7c7e9c0c4d5342
SHA-256: 63703179f1850804f68f7d3833f83b022f3b28c67e1297174fd212d0b0e9217f
Size: 132.19 MB
Asianux Server 8 for x86_64
- bpftool-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 9b896a4c0cbe6315e3ff02138cc9ef31
SHA-256: 8c0350a513593c5856fa982f6226aa65afe025bb2b10cf773abb43fe88a0c510
Size: 11.20 MB - kernel-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 50ea6bf5a125d14f15acb7cb8d70b1f6
SHA-256: ceefe5fb3f5222e98b1163ed836813cfa6676261ae608d7448df19f96305f635
Size: 10.47 MB - kernel-abi-stablelists-4.18.0-553.37.1.el8_10.noarch.rpm
MD5: 6a69a8f67c9347580889762e7de6f475
SHA-256: 7f832535e8a8e4afbbef7bba0a42e458d9e2e63e9afa3a2069c24ff892cab641
Size: 10.49 MB - kernel-core-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: e3dfdbb699eb9b07c23c7a2de6971a34
SHA-256: a7a8950dc0766014688f58c14d859a89695119fa172fc0dea94b8169f6522949
Size: 43.50 MB - kernel-cross-headers-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: ee4bcac9fdbf9291c3f29fd7eafb6c1a
SHA-256: 10a30ed546a42c009a1ac007794f8831f942d02a61cc052a97ffb84954079210
Size: 15.82 MB - kernel-debug-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 9c141cd8893b97c3ed93bdcb813c718c
SHA-256: 84d8ed76d68b87834b6baaaac4a5352fe84ee0b8b03294cb3ae2ed49096865a7
Size: 10.47 MB - kernel-debug-core-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 14319e0e3afed9beb5319cd8fd6ed20c
SHA-256: 2f26f517b8e72e48bf2ae1959f477d0473bf54b9771b86efcd5cc64a3efedae2
Size: 72.79 MB - kernel-debug-devel-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: efce948ec60b3f01a5e983ddb50dcca7
SHA-256: df209b92b2562a7021ae7fb23ef3c3c210ff03d4a37e7ff449e5d8bb3e8df8ae
Size: 24.30 MB - kernel-debug-modules-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 387cee4d60f1485f9a6bb76c4bb8c1d4
SHA-256: a5ec8300d8131c0e4335bc33911ab55b93e56a58ea8568f573f0137cd0f9d127
Size: 65.89 MB - kernel-debug-modules-extra-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 293ecc9949f6499862d199c4622c99ba
SHA-256: ebd508e9f51b3e2371692f28eac432683af9be17b4e609bf5bdeb522f3797fc4
Size: 11.85 MB - kernel-devel-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 906ea201a3394536ffb703cf0c12cf83
SHA-256: a857580fbd97bee26ba1c59f75fad6996c4ba152b1bc0ed463456f0522722b08
Size: 24.10 MB - kernel-doc-4.18.0-553.37.1.el8_10.noarch.rpm
MD5: c6c33856728917a5c5185b5b4dc08f87
SHA-256: 8aec78ecc7f088c99f17454e989398e47a5d5faf0495a6919d8178104058f3de
Size: 28.33 MB - kernel-headers-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: b567ea50f064c7d296be61f9c307d493
SHA-256: 7c5bde9c19da8e32c919e5c4a759da29a85dc5e3f668bc745a88b23f5c6b6cfb
Size: 11.83 MB - kernel-modules-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 944a51eab2228ed349dbe2a7ba98d015
SHA-256: 738d66237e2008119ea847856f0eb3cc1fe3d654b0b33e5db3febe528b2af248
Size: 36.29 MB - kernel-modules-extra-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 74d518e6efa386e955c66fe29b47eb69
SHA-256: fb5f8ac12c8fc0975ffa641d83fd1642e28b233ad4cbe5a7f15999b64af292ba
Size: 11.16 MB - kernel-tools-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: e8e1b4e4355ee6248c2ce46bb9d957aa
SHA-256: de6d921510a9116fedefa6c4d4c44fc66b26018875623cd00e73cae4a76ba95b
Size: 10.69 MB - kernel-tools-libs-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: f10f776e8febd776e7741039561b6f9b
SHA-256: d894fb2650e70b83d93deea8dcc1ae14bd16df349cc5c375b907a91cc3478eaf
Size: 10.48 MB - kernel-tools-libs-devel-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 42a7182ee4e614376f7db1f7b6e2b78e
SHA-256: fb1d63e43c7a2fc2d10bdcf5b8905e009429eb3bf494518026035d2cd3b66a3f
Size: 10.47 MB - perf-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: f753a61c9a9c9f6458856f8077ccb9e8
SHA-256: e5d57c1046752023807c44128f244326a81898b321258087990b98027879cf00
Size: 12.79 MB - python3-perf-4.18.0-553.37.1.el8_10.x86_64.rpm
MD5: 6eb2b5951ba5c0520e518352d6b8841c
SHA-256: 7bd140debb5191f39ba292d9b16103a6b1e9026500d2f44c9dbb8adaf73f0afb
Size: 10.60 MB