kernel-4.18.0-553.94.1.el8_10
エラータID: AXSA:2026-086:04
リリース日:
2026/01/28 Wednesday - 09:57
題名:
kernel-4.18.0-553.94.1.el8_10
影響のあるチャネル:
Asianux Server 8 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- kernel の i915 ドライバには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2023-53552)
- kernel の SMB クライアントには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-38051)
- kernel の SMB クライアントには、メモリ領域の範囲外書き込みの
問題があるため、近隣のネットワーク上の攻撃者により、情報の漏洩、
データ破壊、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2025-39933)
- kernel の DRM スケジューラーには、メモリ領域の二重解放の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-40096)
- kernel の atlantic ドライバには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2025-68301)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2023-53552
In the Linux kernel, the following vulnerability has been resolved: drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)
In the Linux kernel, the following vulnerability has been resolved: drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)
CVE-2025-38051
In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------- ---truncated---
In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace:
CVE-2025-39933
In the Linux kernel, the following vulnerability has been resolved: smb: client: let recv_done verify data_offset, data_length and remaining_data_length This is inspired by the related server fixes.
In the Linux kernel, the following vulnerability has been resolved: smb: client: let recv_done verify data_offset, data_length and remaining_data_length This is inspired by the related server fixes.
CVE-2025-40096
In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.
In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.
CVE-2025-68301
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace:
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-4.18.0-553.94.1.el8_10.src.rpm
MD5: a3b134bbfa11171cc5924d908cb40049
SHA-256: a2a2715102f59953aa0e471d69e334247d7bc67c2d56cf09b0ce24967078b049
Size: 132.31 MB
Asianux Server 8 for x86_64
- bpftool-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 93f1e2c0a2bf102bd3cfaf49fdd53f05
SHA-256: 7e44406458bf4b55e8716aed81e9a6efec531f30faaa4fb71d2b01500ecf44a8
Size: 11.27 MB - kernel-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: a81e237353a571dd6b9a52df02c2e243
SHA-256: 7fcb2b375c1b999693539dfa071515201c822c499ad5ac480b3f30b078f67fce
Size: 10.54 MB - kernel-abi-stablelists-4.18.0-553.94.1.el8_10.noarch.rpm
MD5: 0a4f3ed525b17e541f957fde239ae8c7
SHA-256: b71742624bb926972ca78480d8a0a93e72cbb215c6de896a4169b1622939073c
Size: 10.56 MB - kernel-core-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 04fe30f247bd1eb7a5776e9aa06b8fea
SHA-256: 73f021331a19966b11ad1825f6a614afea53e6495e070447b69fa219b208a637
Size: 43.57 MB - kernel-cross-headers-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 67d6043ec6916fec04645e7edeb0d714
SHA-256: 03a9e19b400942349b67387caa063289dc602dd17a33a8a6dafcd173e104fb44
Size: 15.89 MB - kernel-debug-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: f27b1021598d2688fc17cbb6b81d6aa4
SHA-256: 94833156da0b3d2aee51f3fac1339e2edc61e6494307668c77cd474c06fb94e0
Size: 10.54 MB - kernel-debug-core-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: cb398087f0cfde7d14519ff0bd74acb2
SHA-256: b2ca049fde405f00c3cebc01fdf2e39f76fd21a63f9279d20eb15df788511e11
Size: 72.86 MB - kernel-debug-devel-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 9106bd0de2ebf09a6e66be2dd13a5ec4
SHA-256: dc6dab6c1044b6571e35a40fb15b18d4d4f25fd0b083d319a6c2c05c88f33bdf
Size: 24.38 MB - kernel-debug-modules-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 9bf329218cddc939a81276f4b8645569
SHA-256: 8d0a19d3fd33ca6055d7b38803af64ba0e0728e9cb5fabf113b59db9d883d557
Size: 65.99 MB - kernel-debug-modules-extra-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: f548a9e420f51e3e0f660a3293d654bd
SHA-256: 9235cfe9496424a9a91c2b482c9b67301a378bf0143d2e84b473a62ee7d907d6
Size: 11.92 MB - kernel-devel-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 0fbd0582ae7f8bfa6961a300381a5924
SHA-256: 5fa6f1226d1b78861dad84154252d56397cfd1c1593399b6b3bc0e139599aebf
Size: 24.18 MB - kernel-doc-4.18.0-553.94.1.el8_10.noarch.rpm
MD5: a66b65e6c6828b68a3fb35581b920f47
SHA-256: 6131dc245d1031f56ce990f50ea6ef17feef3ac50106736f77d82c9e5a4eaafb
Size: 28.41 MB - kernel-headers-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: ded1f695b754b65572cde236789042c2
SHA-256: 9669eb0040cab5d1c5ea7132e62a840d3f14d172d77b437848132fdf3380da9c
Size: 11.89 MB - kernel-modules-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 8402ca0e0b3164d7bef0a972d75b2fd8
SHA-256: a97b8f058c96a2ecb9e40bc0427845cf9e9371ec114c49067938b2626f31d31d
Size: 36.38 MB - kernel-modules-extra-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: a0e3b1a64a3923afb307a272e1fca5b3
SHA-256: 9b29bf0baf7b935778b599e482e45f70bc8743e1ff4d1a629ecfee250e0fe398
Size: 11.23 MB - kernel-tools-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: b771d7da8caea43621c631fc31089757
SHA-256: 0df902bf092044ca993ec0cce8bc9d84291ab8691671f8488a2cd5e844348e24
Size: 10.76 MB - kernel-tools-libs-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: b70410b4d51b6f1a11ce57b492b83f87
SHA-256: fb5dd1171ab72a44d81a0d47912b4183cf1d80edf45e896eb7931b106f12b9ac
Size: 10.55 MB - kernel-tools-libs-devel-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 27652fbce20812425d5f8a8160ed96ac
SHA-256: b7e90a625b93ec6cb64d4468de698ada9f588aa7f438e988f93b7d6eb5f6cc6a
Size: 10.54 MB - perf-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 65cb43e009059c7b086afc6f14a89905
SHA-256: 416607c9077e6fbc3b3ea2487aab35d917a46819e9bb31dd9a84a178db4667bb
Size: 12.86 MB - python3-perf-4.18.0-553.94.1.el8_10.x86_64.rpm
MD5: 7a99c1f7d41ee6e4683e7ca5e3c3e53b
SHA-256: 8ff12bffc023f6f3f4b8fa1d211a60b10c5a9d31202dd7ecbbe504092e3f73be
Size: 10.67 MB
English